The shape that feels safe and almost never wins
The first instinct when a business decides to "do AI" is to commission a build. Scope the work. Get a fixed price. Hand over the artifact. Walk away with a system. That is the shape every business is used to: it is how you buy software, how you hire a contractor, how you buy a website.
It is also the shape that loses to a recurring AI engagement almost every time, for three reasons.
One-time builds are snapshots
A one-time build is delivered at a moment in time. The model, the data sources, the workflow, the team that uses it, the integrations it depends on. None of those are static. The business changes. The tools change. The model changes. A snapshot, by definition, stops reflecting reality the moment it is delivered.
We see this in the engagements we take over from prior vendors: a build that worked in 2024 is now half-broken in 2026 because three of the integrations it depends on changed their APIs, the data shape shifted, and the model it was tuned for has been deprecated. The business paid once and now has a system that needs another build to keep working.
Recurring engagements compound
A recurring AI engagement is a different shape. We build, we run, we watch, and we tune every week. The system gets better the longer it runs because we are actively learning the business. The model is kept current. The integrations are kept current. The workflow is updated as the business changes.
After twelve months, a recurring engagement has compounded into a system that the business could not have bought as a one-time build. The first month is roughly equivalent to a one-time build. The twelfth month is a different category.
Predictable cost is the other half
A one-time build looks cheaper in the proposal because the number is single. A recurring engagement is a monthly number, which feels like a commitment. But over a year, the recurring engagement is usually cheaper because the build needs to be redone every twelve to eighteen months. The recurring engagement does not.
There is also a planning argument. With a recurring engagement, the monthly cost is known. With a build, the next build is an unknown event that the business will have to scope, fund, and execute. Predictable cost is an underrated feature of the recurring shape.
When a one-time build is the right call
There are still cases where a one-time build wins. A defined product launch, a migration, a one-off internal tool that has a clear end state. If the work has a real "done," and the artifact will not need to change, a fixed-price project is the right shape. The mistake is treating a workflow as a one-time build when it is actually an ongoing system.
The decision framework
Ask three questions:
- Is there a real "done"? If yes, build. If the work has to keep running and keep improving, the recurring shape is correct.
- Will the inputs and integrations change in the next 12 months? If yes, you want someone watching and updating.
- Does the work depend on a model that will be deprecated? If yes, the recurring shape pays for itself by keeping the system current.
For most businesses evaluating AI for the first time, the answer to all three is "we don't know yet". Which is the strongest argument for starting with a recurring engagement and graduating to a build later if a build becomes the right shape.