The Constraint Nobody Mentions in the Demo
A prototype gets to invent its own data model. A production integration doesn't. Whatever you build has to read from the schema that's already there, respect the permissions that are already there, and run inside a release cadence that was already set before anyone mentioned AI. That constraint is the actual project. The model call is the easy part.
Most integration failures trace back to skipping this step — building the capability first and discovering the data access problem in week six, when the team is already committed to a demo date.
Start From the Exception, Not the Happy Path
Every existing product already handles its happy path. The reason to add AI is usually the cases the current system handles badly — the ambiguous support ticket, the document that doesn't match a template, the query nobody wrote a rule for. Design for that case first, because it defines what "correct" means before a single prompt gets written.
If you can't describe the failure mode you're fixing in one sentence, the scope isn't ready yet.
Ship Behind a Flag, Measure Against the Old Path
New intelligence goes in behind a flag, next to whatever the product already does, not instead of it. That gives you a live comparison — same input, two outputs, real usage — instead of a subjective judgement about whether the new version "feels" better.
Keep both paths running until the evaluation set says otherwise. Removing the fallback before you have data is the single most common cause of an AI feature getting quietly reverted three weeks after launch.
The Boring Infrastructure Is the Differentiator
Logging, permission checks, a way to see what the model actually retrieved, a path back to a human — none of it demos well. All of it is the difference between a feature your team can support at 2am and one nobody wants to own. Build it in the first version, not the second.