AI projects are genuinely harder to scope at a fixed price than most software projects, because the honest answer to "will this work well enough?" often isn't fully knowable until real data and real edge cases are in front of the system. That's not a reason to avoid fixed-price engagements, but it does mean the scoping process has to look different from a typical software fixed-bid.
Why AI scoping is genuinely harder than typical software scoping
A traditional software feature's scope is mostly a question of build complexity: how much code, how many integrations, how many edge cases in the business logic. An AI feature adds a second, less predictable dimension: whether the approach will perform well enough on your specific data and use case. That isn't always answerable with full confidence before building something and testing it.
How we actually structure a fixed-price AI engagement
A short, separately-scoped discovery phase before the fixed-price build
Before committing to a fixed price for the full build, a focused discovery phase tests the core approach against real (or realistically representative) data. It tells us whether the underlying idea is viable at the quality bar you need. This is what makes the subsequent fixed-price commitment honest rather than a guess dressed up as a number.
A defined, specific quality bar agreed before the build starts
"The AI feature works well" isn't a specific enough target to scope or deliver against. A defined bar (accuracy against a real evaluation set, a specific latency target, a specific escalation rate to human review) is what makes a fixed-price AI engagement deliverable and verifiable at the end, rather than a subjective judgment call.
Explicit scope boundaries around what's proven versus what's unknown
A fixed-price scope should distinguish clearly between work that's well understood (the integration, the interface, the deployment pipeline) and work where the discovery phase established real confidence in the approach. Anything genuinely still uncertain after discovery gets called out explicitly, not folded into the fixed price as an assumed risk.
When we won't do fixed price
If a project's core technical approach is genuinely unproven (no clear precedent, no discovery phase completed, and no way to get real confidence without significant exploratory work), we'll say so rather than quote a fixed price against real uncertainty. In that situation, a time-and-materials or capped-discovery arrangement is the honest structure. A fixed price becomes realistic once discovery has de-risked the core approach.
We'd rather tell you upfront that a project needs a discovery phase than quote a number that's really a guess. A fixed price that doesn't reflect real confidence just moves the risk onto whoever gets surprised by it later, and that's usually the client, in the form of scope disputes or a rushed, lower-quality outcome.
How we approach this
We scope fixed-price engagements around a short discovery phase and a clearly defined quality bar, We're upfront when a project's core uncertainty means a fixed price isn't yet the honest structure, because getting that distinction right is what makes the eventual fixed-price commitment deliverable.