How you pay for software work quietly determines how the work goes. Pick the wrong model and you spend the engagement fighting the contract instead of building the product. Here’s how we think about it.
Fixed scope works when the problem is known
If we can define the deliverable precisely — a specific integration, a well-understood app, a migration with a clear endpoint — a fixed price is the honest choice. You get a number and a date before you commit, and the risk of estimating sits with us, not you.
The catch: fixed scope only stays fair if the scope actually holds. That’s why we invest heavily in discovery up front and write down exactly what’s in and out.
Time-and-materials works when discovery is the work
For open-ended R&D — “we think AI can help here but we’re not sure how” — a fixed price forces everyone to pretend they know things they don’t. Time-and-materials, with a tight feedback loop and a not-to-exceed cap, keeps you in control while leaving room to learn.
Our default: a fixed-price discovery, then decide
More often than not we start with a short, fixed-price discovery phase. It’s cheap, it de-risks the big decision, and it ends with a costed plan. From there, a known build goes fixed-scope and a fuzzy one goes capped T&M.
The real point: aligned incentives
Whatever the model, the goal is the same — neither side should profit from things going wrong. Transparent scope, weekly demos, and an honest conversation the moment something changes matter far more than the label on the contract.
If you’re weighing a project and not sure which model fits, that’s exactly the kind of thing a discovery call is for.