What this covers
- Building in-house means owning the maintenance of something that changes every time your rules or systems do.
- A platform license sells you capability and leaves the configuration, and the configuration is the project.
- The third option starts from a workflow that already exists and adapts it, which shifts who carries the adaptation cost.
- Compare on year three, not on year one. All three look similar at signature.
A CFO asked to approve an AI automation project will ask what it costs. The harder and more useful question is what the organization is taking on, because the three common answers differ on that far more than they differ on price.
The three options, plainly
| Build in-house | License a platform | Adapt what exists | |
|---|---|---|---|
| What you get | Development capacity aimed at your problem | A license to a tool with the capability in it | A working workflow adapted to your systems |
| Where it starts | A blank page | An empty configuration | An agent already built for the workflow |
| Who does the adapting | Your team, or a project team you manage | Your team | The vendor, to your data and rules |
| Where it runs | Wherever you build it | Usually the vendor's cloud | Inside your infrastructure |
| First value | Months, and dependent on hiring | After configuration, which is the project | Weeks, scoped to one workflow |
| The year-three question | Who maintains it now | How much of the configuration is institutional memory | What the second workflow costs |
Building it yourself
There is a real case for building. If the workflow is genuinely unique to your business and is itself a competitive advantage, owning it is correct, and a capable team can get a first version working faster than most people expect.
The cost that is consistently underestimated is not the build. It is that the thing you built is now a system that has to be maintained by people who have other jobs, and it changes whenever any of the following do: a pricing rule, a tolerance, a catalog structure, an ERP upgrade, a model version, a new customer sending a format nobody anticipated.
A useful test: if the two engineers who built it left, would anyone else be able to change the tolerance rules? In many organizations the honest answer is no, and that answer arrives about eighteen months in.
Licensing a platform
A platform sells capability. It can read documents, apply rules, route approvals and connect to systems. What it does not include is the knowledge of your catalog, your pricing logic, your tolerances and the exceptions your operation actually generates, because that knowledge is specific to you.
The license is not the project. The configuration is the project, and the license is usually the smaller number.
This is why platform evaluations so often go well and platform deployments so often stall. The evaluation tests capability, which is genuinely there. The deployment tests whether your team has the time, the mandate and the tolerance for a twelve-month configuration exercise on top of their existing work.
Two further costs appear later. The configuration itself becomes institutional memory held by whoever did it. And the platform generally runs in the vendor's environment, which is a separate conversation with security and a separate set of data terms.
Adapting something already built
The third option starts from a different place: an agent already built for quoting, or order entry, or invoice processing, with the workflow logic, the validation patterns, the approval routing and the exception handling already in it. What a deployment adds is your data, your rules, your systems and your thresholds, and the vendor does that adaptation rather than handing you a configuration screen.
This is what we do, so read the next paragraph with that in mind. The honest limitation is that it only applies where a workflow of that shape already exists. For something genuinely unique to your business, this option collapses into one of the other two, and the right answer is to say so rather than to stretch the product.
How it works sets out the split between what is built before a project starts and what is configured against your systems.
The questions that separate them
Six questions, asked of any option including an internal proposal, tend to expose the real shape of the commitment.
- 01Who changes a tolerance rule in eighteen months, and do they need a developer?
- 02What happens when we upgrade the ERP?
- 03Where does the agent run, and where does model inference happen?
- 04What does the second workflow cost, and what do we pay for again?
- 05If we stopped, what would we keep: a running system, a configuration, or nothing?
- 06Show me a case it got wrong and what happened next.
Question four is the one that separates a point purchase from a platform decision, and it is cheap to ask now. What an AI operating system means covers why it matters.
A reasonable default
For a workflow that looks like other companies' versions of the same workflow (quoting, order entry, purchasing, invoice processing, customer requests), adapting something already built is usually the right call, because paying to rediscover a solved problem is a poor use of a team that has other things to do.
For a workflow that is genuinely yours and genuinely differentiating, build it, and build it on a foundation you can extend rather than as a standalone system. The mistake to avoid in both directions is treating a solved problem as unique, or a unique problem as solved.