A founder once asked us to quote a fixed price for “adding AI chat to our app.” That’s a completely reasonable-sounding request. It’s also the exact kind of request we won’t put a single number on. Not because we’re trying to pad the invoice with hourly billing, but because a fixed price on AI work usually means someone is quietly deciding, in advance, not to test it properly once it’s built.

Here’s the thing prospective clients don’t always know going in: traditional software features are deterministic. You write the logic, it does the same thing every time, and a fixed-price quote makes sense because the scope is genuinely knowable up front. AI features are not like that. They are probabilistic, they depend on a model you don’t control, and they touch your users’ data in ways that create real liability. Treating them like a CRUD form is where AI projects go sideways.

The three unknowns fixed-price bids paper over

When someone quotes you a flat fee for “AI integration,” ask them how they’re accounting for these three things. If the answer is vague, that’s your red flag, not the price itself.

  • Model drift. The model you build against in month one is not guaranteed to behave identically in month six. Providers update weights, deprecate versions, and change default behaviors, sometimes without much warning. A fixed-price contract has no natural mechanism for revisiting a feature after the underlying model shifts under it — the agency has already been paid and moved on to the next client.
  • Prompt fragility. A prompt that works cleanly on your test cases can break on real user input you didn’t anticipate: a longer message, a different language, a sarcastic tone, an attempt to jailbreak the system prompt. Hardening a prompt against the actual distribution of what users type is iterative work. You don’t know how many rounds of iteration you’ll need until you’re in it, which is precisely why a single upfront number is a guess dressed up as a commitment.
  • Data exposure risk. AI features often mean sending user data to a third-party API, logging prompts and completions somewhere, or storing embeddings of sensitive content. Getting this wrong isn’t a cosmetic bug — it’s a compliance and trust problem. Deciding what gets sent where, what gets redacted, and what gets retained takes deliberate design, not a line item in a scope document written before anyone has seen your data model.

A fixed-price quote on AI work is, in effect, a promise that none of these three things will require real engineering attention after the contract is signed. That promise is usually false. The more honest version is: the vendor priced it flat, so they have a financial incentive to ship the first working version and stop looking for edge cases.

What we do instead

We scope AI features in two phases, and we say this to clients directly before any work starts.

The first phase is a short, bounded discovery engagement — we look at your actual data, your actual users, and the actual task you want the model to do, and we build a small working prototype against real (or realistic) inputs. This is where prompt fragility and data-handling questions surface. It’s cheap and fast precisely because it’s meant to expose problems early, not hide them behind a polished demo.

The second phase, building the production version, is scoped and priced based on what we learned in discovery — usually as a not-to-exceed range with milestone checkpoints, not a single flat number. That range accounts for the iteration prompts typically need and includes a plan for what happens if the underlying model changes after launch: who monitors it, who’s responsible for re-testing, and under what terms we revisit the prompt or logic if output quality degrades.

We also tell clients plainly what we haven’t built yet. If a feature needs guardrails we haven’t tested against your specific data, we say so before you pay for it, not after something goes wrong in production. That’s the same standard we hold ourselves to on the rest of our work, from full-stack Flutter builds to backend and admin console work — the code we ship has been through the same paths a real user will hit, not just a demo path.

What this means for you as a buyer

If you’re evaluating vendors for an AI feature, the fixed-price quote itself isn’t disqualifying — plenty of well-scoped, narrow AI tasks (a classification step, a simple retrieval lookup) can be priced flat once discovery has actually happened. What should worry you is a flat price offered before anyone has looked at your data or tested against messy real-world input. Ask the vendor directly: what happens if the model provider changes something in three months? What happens if a user finds a prompt injection that leaks another user’s data? If those answers are hand-waved, you’re not buying certainty — you’re buying a number that made the sales conversation shorter.

We’ve built AI features into production apps where getting the data handling and prompt behavior right mattered as much as the feature working at all — the same security-first instinct we bring to code audits when we’re untangling someone else’s stalled build. If you’re weighing whether an AI feature is scoped realistically, or trying to figure out why one someone else built keeps misbehaving, that’s a conversation worth having before any contract gets signed.