June 2026 | Issue 002 | Volume I
Essay Build Discipline 5 min read

"A scraper" was a platform - in disguise

I asked for a weekend bookmark tool. One clarifying question turned it into a daily command center.

By Ryan Gonzales
Co-author Bishop
Filed under B
Date May 26, 2026
"A scraper" was a platform in disguise

I asked for a small thing. Build me an interesting-stuff scraper, I said.

Something that goes out, finds articles and videos worth looking at, and collects them in one place. A weekend tool. A glorified bookmark list with a fetch loop.

Bishop asked one clarifying question before writing any code, and that question turned the weekend tool into a platform.

i.The question that came apart in my hands

The substance was: what is this actually for, and where does the output go. Not “what should the scraper scrape.” A scope question. And once I started answering it honestly, the small thing came apart, because the answer wasn’t “I want a list of links.”

The answer was that I wanted a single place I could look at every morning that told me the state of my world. The interesting articles, yes. But also my email triaged down to what mattered, my calendar for the day, what I’d spent, the loops I had open. A command center. And then, separately, a thin slice of that could be made public, so the things I found could be promoted to the website and the feed wasn’t only for me.

ii.Why you can’t grow one into the other

That is not a scraper. That is a private daily dashboard with a public surface bolted to one corner of it. The scraper is one input out of five. If I had started coding the thing I asked for, I would have built a clean little fetch-and-store tool, and a week later I’d be bolting email onto it, then calendar, then expenses, each one fighting a structure that was never designed to hold them. The scraper’s architecture and the dashboard’s architecture are not the same shape. You cannot grow one into the other by accretion. You get a tool with a platform stapled to its side.

"A scraper" was a platform in disguise
On scope The name of the thingis notthe spec for the thing.

iii.The cheapest moment to find out

The clarifying question caught that before a single line existed. That is the entire value of brainstorming before building. Not ceremony, not a process tax. It’s the cheapest possible moment to discover that the thing you asked for and the thing you actually want are different sizes. Before there’s code, the cost of that discovery is one conversation. After there’s code, the cost is a rewrite, and rewrites are where good projects go to stall.

iv.The partner has to be willing to not start

The reason this works is that the partner is willing to not start. The default instinct, human or AI, is to be helpful, and helpful looks like immediately doing the thing that was asked. A scraper was asked for; a scraper could be produced; everyone feels productive. The more useful move is to spend one question making sure the named thing is the right thing, and to be willing to hear that it isn’t.

Ask what it's forbefore you askhow to build it.

v.One sentence, before the first function

The word “scraper” was hiding a platform. One question the size of a sentence was enough to surface it, and it cost less than the first function I would have written. That’s the trade brainstorming makes: a minute of scope talk against a week of fighting the wrong architecture.

Drafted with Bishop, my AI partner.
Words picked, edited, and approved by me.