How we scope: fixed quotes without the fiction

Why hourly billing points the wrong way

Hourly billing pays an agency more the longer something takes. That is not an accusation of dishonesty against anyone who bills that way. It is a description of an incentive that points backwards from what a client actually wants. Efficient work reduces revenue under an hourly model. Slow work increases it. A client has no real way to audit whether forty logged hours were forty hours of value, only whether they were forty hours. The model does not require bad faith to produce a bad outcome. It only requires time.

None of this is solved by simply trusting the agency more. It is solved by changing what they are actually paid for. A model where the price is fixed to a defined outcome, not to time spent, removes the incentive mismatch at its root, because how many hours it actually takes becomes the agency's problem to manage well, rather than the client's problem to police.

Most fixed quotes are fiction too

The usual alternative, a single fixed number attached to a vague scope like 'build us a website,' is not actually fixed. It is a starting figure both sides quietly understand will grow once real requirements surface, through change orders that feel like scope creep to the client and feel like simple discovery to the agency. A price is only as fixed as the scope underneath it is specific. A one-paragraph proposal with a confident number on it is a guess dressed as a commitment, and the disagreement it causes months in is rarely about the number itself. It is about the fact that nobody wrote down what the number was for. The tell is usually not the number. It is how quickly the conversation moves from 'what will this cost' to a figure, with nothing specific written down in between. By the time the argument surfaces, the relationship has usually already started to sour, which is a strange way to begin something meant to last months.

What we actually do: a call, a written scope, then weekly slices

The process starts with a free discovery call, and the honest version of that call sometimes ends with us saying a client does not need custom software at all, and explaining why. The call itself is doing real work, not just being polite before a sales pitch. It is where we find out whether the request as described is actually the right thing to build, whether a simpler version would get the client to the same outcome sooner, and whether the timeline being hoped for is realistic given what is actually being asked for. Some of the most useful calls end with a smaller project than the one the client walked in wanting, which is a strange thing to optimise for if the incentive were to maximise the invoice instead.

When there is a real project, the call is followed by a written scope document: what we will build, what it costs, and when it ships. Only after that is agreed does building start, and it happens in weekly slices, working software on a staging link every week, not one large reveal at the end.

Weekly delivery is not just a nicer experience for the client. It is what makes the scoping process honest in practice, not just on paper. A wrong assumption shows up in week two, while there is still budget and goodwill left to correct it cheaply, instead of in month four, when correcting it means renegotiating a relationship that has already soured. It also means the working relationship itself gets tested early, before either side has too much sunk into it to walk away cleanly if the fit turns out to be wrong.

What actually belongs in a scope document

A scope document that is doing its job reads less like marketing and more like a specification someone who was not in the room could check against later. That specificity is not bureaucracy for its own sake. It is what turns 'the project didn't turn out how I expected' from a recurring problem into a rare one. None of this needs to be long. A ten-page document full of vague language protects nobody; a two-page one with specific, checkable lines protects both sides. Length is not the goal. Being checkable is.

Suppose the project is a staff-permissions feature for an internal tool. A scope line that is actually usable does not say 'user management.' It says something closer to this:

Included: staff accounts with three roles, owner, manager, packer. A manager can edit products and view orders, but cannot see revenue totals. Not included: a customer-facing loyalty or rewards programme.

That level of specificity is what a real scope document contains throughout, not just in one example line:

• A feature list specific enough that 'done' is checkable by someone who was not in the room, not a paragraph of adjectives.
• Explicit exclusions, stated as plainly as what is included. The unstated boundary is where almost every dispute actually lives.
• The assumptions the price depends on, such as which integrations the client is responsible for providing credentials for, and by when.
• A payment schedule tied to milestones actually delivered, not simply to time elapsed.
• A named point of contact on each side, so 'we told someone' is never a real answer to a missed decision.

None of this is meant to be adversarial paperwork. The best use of a scope document is as a working reference both sides actually reopen mid-project, not a contract that only gets read again once something has gone wrong.

Change requests without the drama

New information always surfaces mid-build. That is not a failure of scoping. It is what building something real looks like. A change request gets priced and time-boxed as an addendum, agreed before the extra work starts, and either folded into the current milestone or queued for later. The point is that it is a conversation with a number attached to it, not silence followed by a surprise invoice, and not the opposite failure, where an agency absorbs unlimited unpaid scope creep until the relationship quietly sours instead. Handled this way, a change request is boring in the best sense: an email, a number, a decision, and the project continues. It only becomes dramatic when one side has been quietly absorbing cost it never agreed to, and eventually stops.

Red flags worth checking, including in our own proposals

A short list worth applying to any quote received, ours included:

• A number with no feature list specific enough to check against later.
• No mention anywhere of what happens when a requirement changes partway through.
• Payment that is entirely upfront, leaving nothing to motivate delivery, or entirely on completion, leaving nothing committed from the agency's side.
• No working software until the very end, so the first time anything real is visible is the final reveal.
• A timeline that never moves no matter what gets added or changed, often a sign scope will quietly shrink to fit the date, not that the original estimate was unusually accurate.
• A proposal nobody would want to show to another engineer for a second opinion.
• Reluctance to put anything discussed on the call in writing afterwards.

Checking a proposal against a list like this takes perhaps ten minutes. It is a reasonable trade for a decision that will occupy months of a working relationship either way. We would rather a client run this exact list against a NexusHand proposal than take 'honest scope, honest timelines' as a claim to trust on its own. A scope document that cannot survive being checked is not really fixed. It is just a number, waiting for reality to catch up with it.