Most of the trouble I have seen in client work does not come from the building; it comes from a mismatch between the kind of work being done and the commercial shape it was sold in. Improvising the structure deal by deal wastes time, produces inconsistency, and quietly erodes the relationship when the structure turns out to fight the work. This note is about the reasoning behind picking a structure, deliberately free of any specific rates. It flows directly from whether you are in product mode or consulting mode, which is the upstream decision that makes the rest of this coherent.

Match the structure to the work#

The core move is simple to say and easy to forget: the commercial model should fit the shape of the work, not the other way around. A few defaults that hold up well:

• Discovery is a fixed, paid deliverable. The scope of a discovery sprint is the scope, so a fixed fee fits cleanly. Critically, discovery is always paid and never given away. Free discovery sets the expectation that your thinking is worthless, which is exactly backwards.
• A greenfield build is time-and-materials with a not-to-exceed cap. The scope of a new build is going to shift as you learn, so a fixed fee on it puts all the risk on you. You either pad the number, and the client feels overcharged, or you cut corners to protect the margin, and the client gets a worse product. T&M-with-cap gives the client a ceiling and gives you room to flex.
• An audit is a fixed, standalone deliverable. Its boundaries are knowable in advance, so fixed fee fits, and keeping it standalone lets a cautious client see the quality of your work before committing to anything larger.
• A modernization is T&M-with-cap, or fixed fee per phase. A big-bang fixed fee on modernization is dangerous, because the real scope is discovered while doing the work. If you fix the fee, do it one phase at a time with gates between phases, never the whole thing at once.
• Ongoing scale work is a retainer with committed capacity. When the relationship is about a named team continuing to deliver, a monthly retainer with committed capacity matches it better than trying to scope discrete deliverables.
• Maintenance is a smaller retainer with a response-time SLA. Keeping something healthy is a different commitment than building, smaller capacity, but a promise about how fast you respond. Only promise an SLA you have the on-call structure to actually honor.

Why T&M-with-cap beats fixed fee on shifting scope#

It is worth being precise about when fixed fee is fine and when it is a trap, because the instinct to fix the price is strong on both sides. Fixed fee is genuinely good on a defined deliverable, an audit, a discovery sprint, a focused spike. The scope is the scope, and a fixed number is the cleanest way to transact.

Fixed fee becomes a trap the moment the scope is going to move. On a build, scope always moves. Fixing the fee forces a bad choice between padding (the client feels burned) and corner-cutting (the client gets less). T&M-with-cap dissolves that choice: the client gets a budget ceiling they can plan around, and you get to absorb scope shifts without renegotiating every week.

The thing that makes T&M sustainable is not the contract language; it is the weekly demo. A regular demo is the trust mechanism. When a client sees working software every week, the open-ended nature of T&M stops being scary, because they are watching their money turn into progress in real time. Without that visibility, T&M feels like a blank check and the relationship sours. The cadence of showing real work is what earns the flexibility.

Bundling and unbundling#

Whether to bundle engagements together or sell them separately is a question of who you are working with, not a fixed policy:

• Bundle when the client has clear runway and confidence, for example pairing discovery with the build that follows it, or pairing a build with a short post-launch period to keep the team in place during the fragile early days. Bundling lowers friction for a buyer who already trusts you.
• Unbundle for a first-time client still evaluating you, for a skeptical buyer who needs to see deliverable quality before committing to a long engagement, or simply when the budget owner cannot approve the whole thing in a single decision. Let them buy a small, low-risk commitment first and earn the larger one.

Default inclusions and exclusions#

Ambiguity about what is in scope is its own source of friction, so set defaults and state them plainly. What I treat as included by default:

• Discovery, design, build, and deployment of the agreed work
• Baseline security and metrics instrumentation appropriate to the work
• A short post-launch stabilization window on any new build
• Knowledge-transfer documentation so the client is not stranded

And what I treat as explicitly not included by default, so nobody is surprised later:

• Ongoing hosting and cloud costs after launch
• Third-party software and tooling costs
• Support beyond the stabilization window, which is a separate retainer
• External audit fees, you implement the controls, the auditor is engaged separately
• Major scope changes added mid-engagement, which re-baseline the agreement rather than quietly absorbing into it

The common thread across all of this is the same as the opening point: pick the structure that fits the shape of the work, make the boundaries explicit, and let a steady rhythm of visible progress carry the trust. Get those right and the commercial side stops being a source of friction and starts being something both sides can plan around.