The Gap Between What We Built and What We Meant

• product design
• system modeling
• ai

A note on how products take shape

I believe the line between the person defining a product and the person building it is collapsing.

With a computer science background and years of building systems in Airtable, this feels like a superpower. It compresses a lot of the work that used to take time and lets me focus more on shaping the system.

But I am also seeing where it goes sideways.

I have watched people get something working on the first try - a single prompt produces something that looks great. It has screens, interactions, maybe even data flowing through it. But then progress stalls.

They do not know how to take what they have and extend it. They are unsure how it would operate in a real environment. They do not know what assumptions are embedded in it. So instead of building forward, they start circling around what already exists, trying to understand it.

I have also seen what happens when someone starts with a broad prompt - something like, “build me an investment portfolio app.”

The result often looks impressive. You get a dashboard with holdings and performance, market data, accounts and transactions, maybe even rebalancing or alerts. But under the surface, a lot has already been decided.

The system might assume a single user with a single portfolio. Long-only positions with no shorting or derivatives. Trades that settle instantly, with no notion of timing or state transitions. Prices that update on demand rather than from a consistent source. Cash that behaves independently of transactions. Performance calculated in a simplified way that does not hold up over time. No clear boundary between historical data, current positions, and projections.

I have asked: “How did you decide you wanted that?"

"I did not.”

And once those decisions are there, they are not neutral. They shape everything that comes next. When the person tries to evolve the app - add multiple accounts, introduce real market data, handle transactions properly, track performance over time - they are not building forward. They are working against a structure they did not define.

A lot of the effort shifts into figuring out what is actually there, untangling assumptions, rewriting pieces that do not fit, and trying to get back to the original intent.

The product is still being defined. It is just happening implicitly, inside the output, instead of being worked through directly.

I have found myself in the same situation. It is easy to move quickly and let the tool make decisions along the way. But you eventually hit the same wall - you are working with something that already has structure and behavior baked into it, without being clear on how it got there.

Seeing this in others, and running into it myself, I have started working toward a different approach.

The goal is to make those decisions visible before they get baked into the product - to introduce a deliberate step between the initial concept and whatever gets generated.

Instead of going directly from an idea to something that runs, you spend a small amount of time shaping what actually matters. That way, when something gets built, it is not filling in those gaps on its own - it is working from a clearer definition of the product, one that can carry from early design through to something that actually operates.

I wanted to build something that lets you do this directly - co-designing a product with a model using a set of defined tools and skills, rather than relying on a single prompt and whatever it decides to fill in.

The goal is to get something working without committing too early to a specific model, stack, or way of building - to see the product take shape first, and make those decisions with more context.

I have been spending time in this space because the gap shows up quickly once something needs to operate, not just exist.