Finding: who runs an AI platform after launch should be a deliberate decision, revisited as usage becomes clear. Moving a system in-house on a fixed date can leave an organization running a system nobody on staff understands, at a cost it cannot predict. A staged handoff, triggered by readiness rather than the calendar, works better.
Summary
- Many AI build contracts assume the client takes the system in-house on a fixed date. That date is usually set before anyone knows how the system will be used.
- In one of our production engagements, the client chose to keep a voice AI platform vendor-run past the planned handoff date, then moved it in-house in stages once usage patterns were clearer.
- Five factors decide the right operating model: how predictable usage is, how fast the system still needs to change, internal engineering capacity, identity and security requirements, and how complete the documentation is.
- A good handoff is a sequence of steps, not a single event: environments, identity, data services, vendor accounts, then day-to-day operation.
Where this comes from
ALLTIPLY built and runs a voice AI roleplay and certification platform for an enterprise software company's sales organization. The original plan was to move it in-house in mid-2026. The client deliberately kept it vendor-run while usage grew. Later in 2026 it agreed to move the platform in-house cautiously, in stages. This paper generalizes that decision.
Why the fixed-date handoff is risky
A handoff date in a contract usually reflects budget cycles and ownership preferences. It rarely reflects the state of the system. By that date, AI platforms in particular are often still:
- Changing quickly. In the platform's heaviest refinement period, more than 150 updates shipped in a single week. An internal team taking over at that point would inherit a moving target.
- Unpredictable in usage. Voice minutes spike during certification windows and drop between them. Fixed-capacity infrastructure bought on the handoff date is either oversized or undersized.
- Dependent on outside services. Speech, language model, and hosting accounts all have to change hands without interrupting users.
Five factors that decide the operating model
- Usage predictability. If you cannot forecast usage within a reasonable range, keep usage-based pricing and vendor operation until you can.
- How fast the system still needs to change. If the system still ships changes weekly based on user feedback, the team that built it will change it faster and more safely.
- Internal capacity. Does a named internal team have time, on-call coverage, and knowledge of the stack? Taking a system in-house without that means nobody is responsible for it.
- Identity and security. Corporate sign-on, role-based access, and data residency rules often push toward in-house hosting. That can be done in stages without moving everything at once.
- Documentation completeness. Architecture, design decisions, runbooks, and usage reports have to exist before the handoff, not be written during it.
A staged handoff
This is the sequence the client in our engagement agreed on, generalized:
- Stand up internal QA and production environments alongside the vendor-run system.
- Move identity to the corporate provider for sign-on and role-based access. This can be phased by user group.
- Move managed data services to standard infrastructure the internal team already operates, such as moving from a hosted backend service to a PostgreSQL database.
- Transfer third-party accounts on low-cost or pay-as-you-go tiers while usage is still uncertain, instead of committing to fixed capacity.
- Refactor for handoff and deliver the paperwork: code cleanup, usage reports, and design artifacts, so the internal team inherits an explained system.
- Hand over day-to-day operation once the internal team has run the QA environment on its own.
When to keep it vendor-run
- The system is still changing weekly.
- Usage is spiky or still growing fast.
- No internal team has on-call time for it.
- The vendor is also running related programs on the same platform, and splitting them would duplicate effort.
When to bring it in-house
- Change has slowed to planned releases.
- Usage can be forecast.
- Security or identity requirements call for corporate infrastructure.
- A named team has run the QA environment without vendor help.
What this means for contracts
Put handoff criteria in the contract instead of a fixed date: the internal team named, environments standing, identity migrated, documentation accepted. Price vendor operation separately from the build so the client can extend it without renegotiating everything. On the platform in this paper, billing was a flat platform fee plus usage-based voice minutes, which made extending vendor operation a simple decision.
Method and limitations
This paper is based on one production platform and the operating decisions made around it in 2026, plus ALLTIPLY's general delivery practice. Treat it as a decision guide, not a benchmark. The right answer depends on your team, security requirements, and how much the system is still changing.
About ALLTIPLY Labs
ALLTIPLY Labs publishes what we learn from building and running AI systems. If you are planning a handoff, or deciding whether you need one, talk to us.
