Ship Code, Not Roadmaps

Every constraint I put on how I work looks, from the outside, like a limitation. Milestone pricing instead of open-ended billing. A staging environment before there’s anything impressive to look at. A hard cap on hours per client. Clients occasionally ask if these are negotiable, assuming they’re guardrails I’d relax for the right project.

I don’t treat them as guardrails. They’re the deliverable.

Pricing that forces scoping

Milestone-based pricing means the architecture, the milestones, and the deliverables get defined before a line of code ships. The cost is known before work begins. That sounds like a sales pitch, but the bigger value is what defining milestones up front does to the project itself.

You cannot write a milestone for work you haven’t thought through. Time-and-materials billing lets you skip that step: start typing, figure out the architecture as you go, bill for the hours either way. Milestone pricing doesn’t allow it. If I can’t describe what “done” looks like for a phase of work, I haven’t scoped it. I’ve guessed at it, and a client is paying me not to guess.

This is why the process starts with a discovery call and a scope-and-proposal phase before any building happens. That scoping is the hardest part of the real work, and doing it honestly is what makes fixed milestones possible at all.

The same logic runs through the fractional engineering arrangement, just applied to time instead of features. A retainer without a scope becomes a general-purpose staffing line: useful to the client in the moment, useless as a forcing function on either side. Milestones and defined monthly hours are the same idea wearing two hats: commit to a shape before you start, and the shape keeps the work honest.

Staging from day one

A staging environment goes up before there’s anything worth showing. Early code rarely looks good, but the alternative is worse: weeks of silence followed by a demo, at which point every misunderstanding about scope has had time to compound and every architectural mistake has had time to get load-bearing.

Weekly check-ins plus async updates and full codebase access work the same way. The point is surfacing problems while they’re still cheap to fix. A wrong assumption caught in week one is a five-minute conversation. The same assumption caught at delivery is a rebuild. Continuous visibility is how the expensive mistakes get caught early, before they compound into a delivery-day disaster.

Thirty days of post-launch support (bug fixes, performance tuning, deployment assistance) closes the loop the same way. Launch is where software meets real traffic, real data, and real edge cases for the first time, and pretending an engagement ends the moment code goes live is how “one small bug” turns into an unanswered email. Thirty days is enough time for the things that only show up under production load to show up, while I’m still the person who wrote the code and still on the hook for it.

Why the hours are capped

Fractional retainers run 10 to 20 hours a week, month to month, with no long-term lock-in and no full-time contracts or embedded roles. This is the constraint clients push on most, and it’s the one I’ll defend most directly, because the cap is what makes the work good.

Spread across a 40-hour seat and split between four clients, an engineer is context-switching four times a day, carrying four mental models, and doing shallow work on all of them because deep work doesn’t survive that many interruptions. Cap the hours and the math changes: fewer clients, each getting focused attention instead of the leftover bandwidth from a bigger roster.

The lack of long-term lock-in is the other half of the same argument. A retainer that scales up or down month to month only works if both sides can walk away without a contract fight. That flexibility is uncomfortable for anyone used to headcount planning in fixed units, but it’s what keeps a fractional engagement honest: you keep paying for it because it’s still working, and an annual contract isn’t what’s keeping you.

None of this is about doing less work. I won’t dilute the work past the point where it’s worth paying for. A milestone with no definition, a demo with no staging history, a support window that quietly doesn’t exist, and an engineer split five ways are all the same failure: scope that was never pinned down. The constraints exist so that doesn’t happen.