When fast development goes against founders

Building got cheap. That is the whole story, and most of us only notice the good half.

In 2016 I ran four startups at once at Abako. We were good at building, so building four things felt like leverage. All four ran out of cash. The lesson I took was that speed, focus, and energy are per-project costs. Four bets meant a quarter of each, and a quarter of a startup is not a startup. Serial works. Simultaneous mostly does not.

For years I filed that under companies. Then AI made building so cheap that the same trap came back one level down, inside a single product, as features. I catch myself doing it now. Instead of solving the problem, I build. Instead of showing something rough and finding out I am wrong, I build the whole thing, get it right, and then show it. It feels responsible. Building feels like work, so it never registers as avoidance. Now that building is fast, the avoidance is fast too.

But I do not want to just repeat the old warning, because the old warning is only half right now. Sometimes you genuinely learn faster by building faster. That part is new, and it matters.

Here is the concrete version. A year ago, if I wanted feedback, my options were a Figma prototype that looked real and did nothing, or weeks of engineering to build something that actually worked. Today I can put a functional prototype in front of someone in an afternoon. People react to a thing that works in a way they never react to a mockup. So building faster can buy better feedback, not just more output. The speed is real, and dismissing it to sound disciplined is its own kind of lie.

So the question is not fast or slow. Speed is not the axis that decides anything. The axis that decides is whether the building produces progress, by which I mean learning something you did not already know, or moving closer to a validated product. Put those two together and you get four situations:

Cheap building does not move you up this grid. It only moves you right. Whether you also move up depends on what you point the speed at. That is the whole discipline.

Which turns into a question I now ask before I build anything: is this something I need to learn, or something I already know.

They are opposite instructions. If I need to learn it, the goal is not to build, it is to learn, so I should build the smallest thing that forces real feedback and no more. If I already know it works, I should stop deliberating and just build it, fast, because there the speed is pure gift. Most of the waste I have caused came from mixing these up: building elaborately to avoid learning, or agonizing over things I already knew.

All of this changes after product-market fit. Before it, you are hunting for a true hypothesis, and building is mostly a way to learn. After it, you have the hypothesis, and building becomes a way to execute. Speed stops being dangerous and starts being plainly good, and it stops being only about features. A friend of mine grew his company from three people to sixty and never built the internal muscle to match. When something breaks, support is a scramble, because there is no system underneath. For him the highest-progress thing to build is not a feature at all, it is the internal tooling that makes the business survivable. That is fast building pointed at real progress, just on a different problem.

So I have ended up with less of a rule and more of a frame. Building got cheap. Feedback and judgment did not. The founders who win with these tools will not be the ones who build the most. They will be the ones who always know which of the two things they are doing.