Start with one workflow that costs the most manual time. Prove value there before expanding.
Who owns what gets built
| Topic | Must have | Nice to have |
|---|---|---|
| IP ownership of custom code | ✓ | – |
| Data processing agreement | ✓ | – |
| SLA for bug fixes | ✓ | – |
| Model change notification | ~ | ✓ |
| Exit / data export clause | ✓ | – |
Get explicit about ownership of the code, the underlying data, and any custom models trained on your information. Some development contracts assume the vendor retains rights to reusable components, which is reasonable for genuinely generic infrastructure but not for anything built specifically around your business or trained specifically on your data.
This matters most if you ever want to change vendors, hire an internal team, or extend the system yourself. Ownership disputes over code and data are some of the hardest and most expensive to resolve after the fact, precisely because they usually surface only once the relationship has already turned difficult, at exactly the moment when a clean, well-documented handover matters most.
vagueness to show up again at the actual delivery date, usually at the worst possible moment for a disagreement to surface.
What done actually means
A proposal that says the system will be delivered in eight weeks means very little without a definition of what delivered covers: does it include testing against real data, training your team, a support period, or just the initial deployment? Get this written down in specific, checkable terms, not general language.
Ask the vendor to describe, in plain terms, exactly what you will be able to see and check on the day they call the project done. If they cannot answer that clearly before the contract is signed, expect the same vagueness to show up again at the actual delivery date, usually at the worst possible moment for a disagreement to surface.
Working on something similar?
Let's talk →What happens when something breaks after launch
Working on something similar?
Let's talk →Ask directly what happens in the first month after launch if the system behaves unexpectedly on real data, which is common and not necessarily a sign of poor work. Is fixing it included, or does it get billed as new scope? This single clause causes more disputes than almost anything else in these contracts.
A reasonable middle ground most good vendors will agree to is a defined post-launch support window, often thirty to ninety days, where fixes for issues present at launch are covered, while genuinely new requests are scoped and priced separately. Get the length and scope of that window written into the contract itself, not promised verbally during the sales conversation.
How pricing changes as scope changes
Complex AI projects almost always uncover new requirements once real data and real edge cases enter the picture. That is normal. What is not reasonable is an open-ended arrangement where every discovery becomes billable without a clear process for you to approve it first. Ask how change requests are handled before you need to find out the hard way.
A well-written change process typically requires the vendor to describe the new requirement, estimate the added cost and time, and get your written approval before doing the work. Without this, you can end up disputing an invoice for work you never explicitly agreed to, which is one of the more common and avoidable sources of tension in development relationships.
What you’re not asking that you should be
Ask what happens if you want to switch vendors later: can another team pick up the system, or does it lock you into this one indefinitely because of undocumented decisions. A vendor confident in their own work will document it well enough that this is not a threatening question to answer.
Also ask what training or documentation your own team receives once the system is live. A system nobody on your side understands is a system you are permanently dependent on the vendor to explain, which quietly removes a lot of your own negotiating position going forward, and it is a cost that rarely shows up anywhere on the original proposal.
None of these questions are adversarial, and a good vendor will not treat them that way. Asking them clearly, before signing, is one of the simplest ways to protect the relationship rather than strain it later, and it sets the tone for how you will work together once the project actually starts.
