I locked the scope and started the build. The best part is how boring it is.

A few weeks ago I locked the scope for the first version and started writing the production code for the app I've spent eight posts describing. The discovery is done. The specs are written. The screens are validated with the person who's going to use them every day. So I'm finally in the part everyone pictures as the real work: the build.

Here is what I keep noticing now that I'm in it. The build is boring.

Not easy. Boring. There is almost nothing left to decide. I sit down, I look at what the next screen is supposed to do, and what it does, what it looks like, and how it behaves were all settled weeks ago. My job is to make the code match a thing that already exists, on paper and in a prototype a real person already used. That is the whole job.

That sounds like a complaint. It is the opposite. Boring is exactly what all that upstream work was supposed to buy, and three weeks in, it is buying it.

What "locked" actually means

When I say the scope is locked, I mean something specific. During the definition phase I wrote thirty-five user stories. Then I cut them. Twenty-three are in the first version. Nine are explicitly "later." Two are "maybe, probably not." One is a flat "no." I wrote down which bucket each story landed in, and why, before any production code existed to tilt the decision.

So when I sit down to build, I am not asking "should this be in the first version?" I asked that already, on purpose, weeks ago, when I had room to think about it clearly instead of in the middle of an implementation. The build only touches the twenty-three. Everything else is off the table by a decision I already made, not by a judgment call I make each day while tired.

This is the part that is easy to underrate until you have felt the difference. A scope decision made mid-build is made under pressure, with code already leaning one way and the sunk cost of what you have already written pulling on you. The same decision made upstream, in a document, costs nothing to change and has nothing pulling on it. I moved all of those decisions to the cheap place on purpose.

The build is execution, not exploration

A couple of posts ago I wrote about building a throwaway version of the whole app in an afternoon, letting the user click through it, and then deleting it. The point of that exercise was to answer the questions only a real, clickable flow can answer. Does the path between screens hold together? When a payment confirmation comes in, how many steps does it take to mark it paid? Where does the flow snag?

By the time I started the production build, those questions were already answered. The screens she reacted to are sitting there as the reference. I am not designing the home screen during the build. I am implementing a home screen that was designed, argued over, polished across several rounds, and validated by the actual user, weeks earlier.

That is the entire difference between a fast build and a slow one. A slow build is one where you are still figuring out what you are building while you build it. Every screen is a small research project: you write some code, realize the interaction is wrong, tear it out, try again. A fast build is one where the figuring-out already happened somewhere cheaper, and the build is just the act of typing it into existence.

This is also where an AI agent earns the most. An agent is very good at "make the code match this decision" and genuinely bad at "decide the right thing." Point it at a settled, validated design and it moves fast and stays on the rails. Point it at an open question and it will confidently build you the wrong thing. Upstream, I did the deciding. The build is the matching, and the matching is what the agent is for.

The dividend, in receipts

Three weeks in, here is what is actually running. First the foundation: the repository, the login, the data layer, the shared kit of components. Then patient records: creating a patient, searching for one. Then the part that matters most, the core the whole app exists to replace: registering a session, recording the payment against it, attaching the invoice, and confirming payments as they land.

That last piece is the heart of the thing. It is the work the spreadsheet does today, the work she does several times a day. It came together in a handful of days, as a series of small changes that each landed green on the test suite. Building just that payment core by hand a few years ago, in my evenings, would have been weeks of work, and I would have been inventing the design as I went.

I will be honest about the pace, because it cuts both ways. This project runs heavy on the upstream end. It has five years of historical data behind it and no commercial deadline, so I gave it two months of discovery and six weeks of validation. For a normal startup MVP I would compress all of that hard, to maybe two weeks. But the compression does not change the shape. Two weeks or two months, the move is the same: spend on the upstream decisions so the build does not have to make them.

Why I am telling you this now

Everything in this series so far has been me catching up. The interviews, the spreadsheet, the specs, the scope cut, the validation sessions, the throwaway prototype. All of it already happened before I started writing about it. This post is where the story catches up to itself. From here, it is live.

So the next stretch comes from inside the build as it happens. The way I am running AI agents to do the actual production work, which is its own thing and not what most people picture when they hear "AI wrote the code." The decisions that show up in the commit log in real time. The data migration later, when five years of color-coded spreadsheet history has to land in a real database without losing a thing. You will see those as they happen, not in retrospect.

What I keep running into

The thread under this whole series has been one quiet observation. The highest-leverage work on this project was never the code. It was the deciding that happened above the code. I kept running into it in different shapes: in discovery, in the specs, in the scope cut, in the validation, in where I set the quality bar.

The build is the test of that claim. If the upstream work was real, the build should be boring, because everything worth deciding got decided before it started. If the upstream work was theater, the build is where it falls apart, where all the postponed decisions come due at once and the "fast" part turns into a mess.

I am not calling the bet won. I am three weeks into a build that has more ahead of it than behind it, and the hardest part, moving five years of live data, is still out there. But the early sign is the one I was hoping for. There is nothing to discover in here. There are just things to build. For now, that is exactly as boring as I wanted it to be.

#BuildInPublic #ClaudeCode #AIEngineering #AIAgenticEngineer