What Building Three Apps Solo Taught Me About Scope

For most of my career I designed things and somebody else built them. In the last couple of years I have shipped several products where I did both, on my own, with AI doing a large part of the typing.

I expected to learn about code. What I actually learned was about scope, and it has changed how I design even when I am not the one building.

Every idea is cheap until you hold both ends

When you only design, cost is abstract. You know a feature is "a lot of work" the way you know a country is far away. You have a number, not a feeling.

When you build it yourself, the cost arrives in your own evening. And what you discover is that the expensive parts are almost never the parts that looked expensive.

The screen with the fancy animation takes an afternoon. The innocuous line in the spec that says "users can invite a teammate" takes a week, because it means permissions, and states for pending and accepted and revoked, and an email, and what happens when someone is invited twice, and what the invited person sees before they have an account.

Nothing about that line looked heavy on the design side. It is a button.

The hidden work lives between features, not inside them

This is the thing I would go back and tell myself.

Features in isolation are usually fine. What costs time is the interaction between them, and the number of interactions grows much faster than the number of features. Ten features is not ten problems. It is closer to fifty, because each one has to behave sensibly in the presence of the others.

That is the real argument for a small product, and it is a much better argument than "focus", because it is arithmetic rather than a value.

AI changed the cost of building, not the cost of deciding

I want to be precise about this because there is a lot of noise.

Writing code is dramatically faster than it was. Things that would have been a two week job are now an afternoon, and that is not an exaggeration. Whole categories of work that I would previously have scoped out of a project because they were not worth the time are now trivially available.

But knowing what to build did not get faster. Deciding what the product is, what it does not do, what happens in the strange cases, how it should feel: all of that is exactly as slow as it was, and it is now a much larger share of the total.

Which means the bottleneck moved. It used to be implementation. Now it is judgement, and judgement does not come from a model.

What I do differently now

I design the smallest thing that could be real. Not a prototype. Something a stranger could use once, end to end. It is always smaller than my first instinct and it is always more informative than a bigger plan.

I write the edge cases before the screens. What happens with no network, no data, a duplicate, a very long name, a user who leaves halfway. If I do not write them down, I will design a happy path and pay for it later at three times the price.

I ship before I am comfortable. Every product I have shipped taught me more in its first week with real users than in the month of work before it. That is not a new idea. It is just much easier to act on when you can build the next version the same evening.

The part that surprised me

Being able to build made me want to design less, not more.

When there is no negotiation between you and the shipped thing, there is nothing to pad. You stop designing screens to argue for a direction, because you can just make the direction and look at it. The work gets smaller, more concrete, and considerably more honest.