Every software vendor now sells an AI add-on, and every board asks why you would build what you can subscribe to. Sometimes the board is right. What follows is the framework we use to answer, including the cases where the answer costs us the project.
Buy the commodity
Meeting summaries, email drafting, generic coding assistance, transcription, document search across common file types: buy these. They are horizontal, the vendors have scale advantages no single enterprise will match, and there is no competitive advantage available in doing them yourself.
The test is simple. If a competitor could buy the identical capability tomorrow and be equally well served by it, building it spends capital to arrive where the market already is.
Build at the differentiator
Where AI touches the process that wins you customers — underwriting, pricing, service recovery, claims triage — building wins on three axes:
- Fit. The workflow matches how you actually operate, including the exceptions, which is usually where the margin lives.
- Boundary. The data stays inside your control. For regulated Indian sectors this is often a condition rather than a preference — RBI outsourcing directions and the DPDP Act both constrain where processing may happen and who may see what.
- Compounding. The capability accumulates as yours. The alternative is that your process knowledge trains something that appears in a competitor's subscription next quarter.
The question that settles most cases
Is the process a differentiator, or an accident of history? Organisations routinely defend an unusual process on the grounds that it is theirs, when it is the residue of a decision made in 2011. Building around an accident encodes it for another decade. That question belongs in discovery, before either option is priced.
Do the lock-in math
Per-seat AI add-ons price the way SaaS always has: modestly at pilot, painfully at scale. The comparison worth running is not this year's subscription against this year's build.
| Question | Why it changes the answer |
|---|---|
| What is the add-on price multiplied by your five-year headcount plan? | Per-seat costs compound with growth; a built system's marginal cost per user is close to zero. |
| What happens to the price when the pilot becomes the standard? | Pilot pricing is an acquisition cost. Ask for renewal terms before, not after. |
| Can you export what the system learned? | If accumulated configuration, labels and feedback cannot leave, the switching cost rises every month you use it. |
| What does the vendor do with your data? | Decides whether this is permissible in your sector at all, and whether your process knowledge is being pooled. |
| How fast have the underlying model costs fallen? | Build economics improve with the API market; subscription economics rarely do. |
The third option nobody prices
Build and buy are not the only answers. The one that most often wins is buy the platform, build the thin layer where you differ — take the vendor's model, infrastructure and tooling, and own only the retrieval, the domain logic and the evaluation set. That is a fraction of a full build and keeps the part that compounds.
It fails in one specific way worth knowing: it works only where the platform exposes real extension points. Many do not, and the marketing rarely distinguishes an extension point from a settings page.
The hybrid most enterprises land on
Buy horizontal productivity. Build the two or three vertical systems where AI touches your edge. Put an abstraction layer under both, so no vendor — including whoever builds it for you — holds the exit.
That last clause is a criterion worth applying to any supplier: ask what leaving looks like, in the first meeting, and see whether the answer is specific. Source from the first commit, documentation, the evaluation set, the prompts and the reasoning behind them should be yours by default. A supplier who makes leaving difficult has stopped competing on the work.
A decision checklist
- Is this process a differentiator, or an accident? If an accident, fix the process before buying software for it.
- Could a competitor buy the identical capability tomorrow? If yes, buy it too.
- Does the data have to stay inside a boundary you control? If yes, that narrows the field before cost does.
- What is the five-year cost at your growth plan, not this year's?
- Can you leave — with data, configuration and learned behaviour intact?
- Is there a platform that lets you build only the thin differentiating layer?
Answer those six honestly and the decision usually makes itself. Where it does not, the split is close enough that either choice can be made to work — which is itself the answer, and an argument for the cheaper one.