Scrappy Is No Longer Faster. It's Just Worse, on a Delay

The startup playbook has one rule above the rest. Move fast in the early days. Ship scrappy. Fix it later. AI did not change that advice. What AI changed is that scrappy is no longer the price of fast.

You can now ship the codebase a senior systems architect would be proud of in roughly the time it used to take to ship the duct-taped MVP. The catch is the part nobody puts on the landing page: AI does not give you the discipline to do it. It only removes the excuse not to. You still have to know what great looks like, and you have to refuse to skip the parts you cannot see yet.

I spent four months testing that claim on myself. olllo was a solo build: one app, one author, no reviewer down the hall, from December through March. The product did not survive contact with the market. People articulated the pain cleanly and would not show up to do the work.

But the way I built it is the part I would defend in front of any hiring committee, because it is the part that scales from a team of one to a team of a hundred without changing shape.

I built the guardrails a team of ten would need, for a team of one. That turned out to be the highest-traction decision I made the whole time.

Solo shipping breaks in predictable ways, and AI-assisted coding multiplies every one of them.

Past decisions go undocumented, so future-me cannot tell why the code is the way it is. Features drift: a spec starts as one thing and becomes another with no trace of the handoff. Every fix risks breaking something the original author already decided, and the original author is also me, three weeks ago, with no memory of the reasoning. The AI assistant cheerfully rewrites a module in a style that contradicts three others it just touched, and without rules of the road, the assistant is correct that the rules do not exist.

Underneath all of it is the empty-review problem. Code review is where most engineering cultures enforce taste. It is the gate where a second person says “why did you do it this way,” and the answer either holds up or it does not. Solo, there is no second person. The taste gate is gone, and most solo projects never notice it is gone until the debt is already poured into the foundation.

The team-of-ten answer to all of this is process: specs, decision records, code standards, test gates, documentation requirements, PR templates. The conventional wisdom is that this stuff is overhead a solo dev cannot afford. I made the opposite bet. Those artifacts are worth more to a solo dev than to a team, because a solo dev is the one who most needs to trust their own past self.

The workflow runs on Speckit, an open-source templating layer for AI-assisted feature specification. Speckit gives you six stages and the templates. The discipline is running every feature through every stage, every time, with no exceptions for the small ones.

The six stages, in order: specify turns a plain-English description into a spec file. clarify surfaces three to five targeted questions about the ambiguous parts and writes the answers back into the spec. plan produces the technical design. tasks produces a dependency-ordered implementation list with acceptance criteria. analyze runs a consistency sweep across spec, plan, and tasks to catch contradictions before any code exists. implement generates the code task by task, with tests passing locally at each step.

The implement stage does the visible work, the part that looks like productivity in a screen recording. But on every feature in olllo, my own time lived in the earlier stages: reading research, refining the spec, choosing the harder long-term path over the easy short-term one. The clarify and plan stages exist to make those judgment calls visible. The implement stage exists to make sure the visible decisions survive into the code. AI did most of the typing. None of the deciding.

A concrete example. One feature replaced three onboarding steps with a single conversational flow. The spec has a literal Clarifications section with five question-and-answer pairs from the clarify stage. One of them asked whether the flow should capture reporting structure. The answer (yes, with manager titles but not names, names encrypted and routed to a contacts model) triggered an encryption decision, a new integration, and a new user-facing string. Without the clarify step, at least one of those three would have shipped as a silent assumption decided mid-implementation, which is to say decided badly.

By the time implementation starts, the ambiguity budget is already spent. Implementation becomes execution instead of exploration. That is the whole trick, and it is invisible if you only watch the typing.

The center of the system is a single file, versioned like code. It declares seven non-negotiable principles, and every one of them exists because something went wrong first.

• Principle 2, no hardcoded user-facing strings, exists because a toast message got smuggled in as a literal during a hotfix.

• Principle 5, database migration safety, exists because a migration once ran against the wrong environment.

• Principle 6, every new user-data model updates the export and deletion services, exists because GDPR Article 17 exists and I almost shipped without honoring it.

• Principle 7, changelog maintenance, exists because three features shipped with no entry and no one to flag it.

The file is amendment-tracked with semantic versioning, and read top to bottom, the version history is a curriculum. Every lesson I would want to teach the next engineer on day one, in the exact order I learned it the hard way. That is the thing a constitution-as-code gives you that a wiki page does not: the history is the teaching, and it is impossible to lose because it is in the repo.

I want to be honest about the limit, because the honest version is more useful than the brochure version. The principles are nothing without enforcement, and for a while the enforcement was still just me. On one feature I added new user-data models and did not update the deletion services, eighteen days after I had written the principle that said I must. I caught it in self-review later and patched it with a direct push. The principle existed. The gate was a human, and the human missed it.

That near-miss is the entire argument for the rest of the system. A rule that depends on the author remembering to follow it is not a gate. It is a wish. The fix was to move enforcement off of me and into CI: tests against every package on every PR with no “I ran it locally” exception, secret scanning so a hardcoded key cannot land even if I miss it, model-output evals so a prompt change is gated on measured behavior instead of vibes, and a living context file the assistant reads every session so its suggestions stay aligned with current conventions instead of drifting back toward training-data defaults.

The principle that lives only in your head is the one you will violate the week you are tired. The principle that lives in CI is the one you cannot violate by accident.

Strip away the solo framing and this is a story about a thing every design and engineering organization is deciding right now, mostly without naming it.

When AI is doing most of the typing, what is your team’s culture made of?

It used to be made of the things that were expensive: the senior person’s time in review, the tacit standards that lived in a few people’s heads, the slow accretion of “the way we do it here.” Those were durable precisely because they were costly to maintain. AI makes the typing cheap, which means the expensive parts are no longer load-bearing by default. If you do not encode the standard, the assistant will fill the vacuum with the average of its training data, and the average is not your taste.

I have watched this at scale from the other side. Every company I have been inside hits the same wall around year two: things start breaking because the early observability was thin, the early tests were inadequate, the early decisions were unwritten. Retrofitting those things at scale costs more than building them in month one would have. The startup trade used to be that you bought speed with debt, and you paid the debt later at a premium. AI breaks that trade. You can now ship the well-tested, well-documented, well-gated version in the same time as the scrappy one. The scrappy version is no longer faster. It is just worse, on a delay.

Which means the differentiator for an organization in the next decade is not whether it adopts AI tools. Everyone will. The differentiator is whether it has the discipline to encode what good looks like before the tools fill the gap with something generic. Specs as a required step. Decisions written down where they can be found. Non-negotiables enforced in the pipeline, not in convention. A living definition of the standard that the tools are made to read.

Not all of my solo system would survive a team unchanged. The nine-artifact spec directory would collapse to three. Every feature got the same nine slots, full or one-sentence, and that identical shape is what made a two-month-old feature readable in minutes instead of hours. The local-test crutch would become CI’s job. And the real gap, the one I would close first if I took this to a team, is that the tooling was built for one author talking to future-self. It has no collaborative layer: no way for a designer to weigh in on a clarification before it resolves, no way to fork a plan into alternatives and choose between them. The shape ports. The collaboration has to be built.

But the core bet ports cleanly, and it is the bet I would make on day one of leading any team: encode the culture, enforce it in the pipeline, and treat every postmortem as a candidate amendment to the rules rather than a Slack message that scrolls away.

The muscle worth building is not faster prompting. It is the judgment to spend your time in the clarify and plan stages, where the deciding happens, and to let the tool own the typing, where it does not. The people who developed that judgment before AI made execution cheap have a structural advantage right now, and the way to keep it is to make your standards explicit instead of tacit.

If you are a leader: the question is not which AI tools to buy. It is what your team’s culture looks like when the assistant is doing most of the work, and whether that culture lives somewhere a tool can read it and a pipeline can enforce it, or whether it lives in a few senior people’s heads where it will quietly erode the first quarter everyone is busy.

AI does not give you the discipline to do it. It only removes the excuse not to.

The teams that understand the difference are the ones I would bet on for the next ten years.

Read the full case study, with the constitution, the workflow, and the near-miss in detail, on hypoth.ai.