What Changed When I Stopped Selling Hours

For the first stretch of my career I sold hours. It felt honest. You work, you log time, you invoice. It took me longer than I would like to admit to see the flaw sitting in plain sight: hourly billing pays you more for being slower, and the better I got, the less I earned for the same result.

The Incentive Problem Nobody Names

Consider two engineers delivering the same authentication system. One writes it in forty hours because they have built it a dozen times and know exactly which edge cases matter. The other takes a hundred hours because they are learning as they go. On an hourly contract, the second engineer earns more than twice as much for a worse outcome, because their inexperience is billed as effort.

That is not a hypothetical. I watched it happen on projects I was not running, and I eventually noticed the same distortion creeping into my own work. When I found a shortcut that saved two days, some quiet part of my brain registered it as lost revenue. That is a terrible thing to feel about your own competence.

The deeper issue is that hours are an input. Clients do not want inputs. No founder has ever woken up wanting four hundred hours of engineering. They want a product that works, on a date they can plan around, at a number they can budget for. Selling hours means selling the thing nobody actually wants and hoping the thing they do want falls out the other end.

What Scoped Work Actually Requires

Moving to fixed scope sounds like a pricing change. It is not. It is an operational change that touches everything upstream of the invoice.

The first thing it demands is that you get genuinely good at scoping. When you bill hourly, a vague requirement is someone else's problem: you will discover the complexity later and bill for it. When you commit to an outcome, a vague requirement is your problem. Every ambiguity you fail to surface before signing becomes work you absorb.

So the front of the engagement got heavier. A scoping call is no longer a friendly chat about what the client wants. It is a structured interrogation of the parts most likely to explode:

• Integrations. Every third party system is a source of unknown latency, undocumented behaviour, and rate limits nobody mentions until you hit them. I now ask for API docs and a sandbox credential before quoting anything that touches an external service.
• Auth and permissions. "Users can log in" is a one week feature. "Users can log in, org admins can invite, roles gate eleven different screens, and there is an audit trail" is a one month feature. These sound similar in a kickoff call and are not remotely similar to build.
• Data migration. If there is an existing system, the migration is usually larger than the feature that replaces it. Legacy data is never as clean as the person describing it believes.
• Who signs off. A project with one decision maker ships. A project with a committee ships eventually. That difference belongs in the estimate.

The second requirement is a written scope that a stranger could read. Not a feature list. A document that says what is included, what is explicitly excluded, what assumptions the estimate rests on, and what happens when an assumption turns out to be wrong. The exclusions section is the one that saves engagements. Writing down "this does not include a native mobile app" feels almost rude at signing time and feels like foresight three weeks later.

Change Requests Stop Being Awkward

The thing I did not anticipate is how much better the client relationship got.

Under hourly billing, every scope change is a slightly uncomfortable conversation about money that neither party wants to have. The client wonders if they are being upsold. You wonder if pushing back makes you difficult. Both of you resolve the tension by not talking about it, and the project drifts.

With a written scope, a change request is a boring administrative event. The client asks for something outside the document. You say yes, here is what it costs and what it does to the timeline. They decide. Nobody feels ambushed, because the boundary was agreed in advance and neither of you is improvising it under pressure.

I have had clients decline change requests, ship the original scope, and come back for a second engagement three months later with the extra work properly funded. That is a healthier outcome than quietly absorbing it and resenting the project.

The Estimates That Went Wrong

I want to be honest about the failures, because the version of this advice where everything works is not useful.

I have underestimated. More than once. The pattern is almost always the same: I scoped the happy path carefully and waved at the operational surface around it. Deployment, environments, seed data, admin tooling, the internal screens the client's own team needs to run the thing. None of that appears in a feature list because it is not a feature. All of it is real work.

The fix was not better intuition. It was a checklist. Every estimate now walks the same list of categories whether or not the client mentioned them, and anything genuinely out of scope gets written into the exclusions rather than silently omitted. Intuition is what you use when you have no process. A checklist is what you use when you have been wrong before and would prefer not to repeat it.

The other failure mode is scope that is technically fixed but emotionally elastic. The client keeps asking for small things. Each one is genuinely small. Twenty of them are a month. I now track small requests explicitly and raise it at the point where the pattern is visible rather than at the point where it has already cost me. Naming it early is a normal conversation. Naming it late sounds like an accusation.

Which Clients This Filters Out

A fixed scope requires a client who knows roughly what they want. Some do not, and that is legitimate. A founder exploring a new market genuinely cannot tell you the feature list, because discovering the feature list is the work.

For those engagements I use a retainer instead, and I am explicit that we are buying capacity rather than an outcome. What I no longer do is pretend a discovery project is a delivery project. Quoting a fixed price for work nobody can specify is how you end up in a relationship where both parties feel cheated.

The clients this filters out entirely are the ones who want fixed price, unfixed scope, and no written boundary. That combination is not a client. It is an unfunded liability wearing a client costume, and every engineer who has been in this business more than a few years has taken one and learned the lesson the expensive way.

What I Would Tell Myself Earlier

Price the outcome, not the effort. Write the scope down, including the parts that feel too obvious to write. Put the exclusions in bold. Do the hard thinking before the contract rather than during the build, because thinking is cheap in a document and expensive in a codebase.

And get comfortable with the specific discomfort of quoting a number in a call and holding it. That pause after you say the price is not hostility. It is somebody doing arithmetic. Let them finish.