Written by
Afreedi Z
AI/ML Lead
Two failure modes, equally expensive, and we see both in roughly equal measure.
The first is building something a subscription would have delivered on Tuesday. A team spends two quarters and a substantial budget constructing a meeting-summarization tool, and finishes with something slightly worse than a product that costs a few hundred a month.
The second is buying a tool for the process that is the business. It works adequately, in the same way it works adequately for every competitor who bought it, and the thing that made the company distinctive quietly becomes a configuration screen.
The framework below exists to keep you out of both.
Start With One Question
Before cost, before feasibility, before anyone opens a vendor site, ask this:
If three competitors used the exact same system for this, would we lose anything that matters?
If the honest answer is no, buy it. Meeting notes, transcription, document search, standard reporting, generic content drafting - none of these are where advantage lives, and building them is a hobby with an invoice attached.
If the honest answer is yes, the conversation becomes serious. Something in that process encodes how you actually operate, and handing it to a product that averages everyone's approach will average yours too.
What Buying Actually Gets You
Speed, obviously. Days rather than quarters, and value while the business case is still warm.
But also: someone else's maintenance burden. This is chronically underrated. Models change, providers deprecate endpoints, prices move, security patches land. A product absorbs all of that. A custom build makes it yours, permanently, and the ongoing engineering cost of keeping an AI system current is the line item most build business cases omit entirely.
You also get the vendor's improvement curve. A serious product improves without you paying for each increment - though this cuts both ways, since it improves in the direction their broader market wants, which may not be yours.
What you give up is control. Their roadmap, their model choices, their data handling, their pricing. And you accept switching costs that grow quietly as the tool embeds itself into how people work.
What Building Actually Gets You
Fit. A system designed around your workflow rather than around the average of everyone's, integrated with the systems where your business actually lives.
Control of the data path, which matters enormously in regulated contexts. You decide where data goes, which models see it, what is logged, and what your compliance boundary looks like.
Model independence, if you architect for it. Building behind an abstraction layer means switching providers on quality, cost, or residency grounds without rewriting the application. Model lock-in is technical debt you choose on day one.
And economics that can invert at volume. Per-seat pricing is excellent early and can become the most expensive line on the page at scale. We have seen custom builds pay for themselves in under a year purely on license displacement - and we have seen the same calculation done optimistically enough to justify a build that never paid back.
What you take on is everything else: evaluation, monitoring, security, iteration, and the permanent obligation to keep it working.
The Framework
Score your use case on five axes. Buy leans one way, build the other, and the pattern usually resolves quickly.
- Differentiation. Does this process encode something competitors cannot easily copy? High differentiation pushes toward build.
- Data specificity. Does it depend on proprietary data, or on your particular terminology and edge cases? Generic tools trained on general patterns handle specialist domains poorly.
- Integration depth. How many of your systems must it touch, and how unusual are they? Deep integration with uncommon systems pushes toward build; products rarely have the connectors.
- Volume economics. Model the three-year cost both ways, honestly, including maintenance on the build side and price rises on the buy side.
- Capability to own it. Do you have - or will you genuinely hire - the engineering capacity to run this in three years? A custom system nobody can maintain is worse than a product you dislike.
That last one stops more builds than any other, and it should.
Buy the common problem. Build the one that is actually yours. Most organizations need both, and the mistake is treating it as a single decision rather than one per use case.
The Hybrid Answer Nobody Pitches
The framing is a false binary, and the strongest AI estates we work with are deliberately mixed.
Buy the commodity layer - transcription, generic drafting, standard analytics, routine automation. Build the thin differentiated layer that sits on top of it, where your logic and your data live. Use products to establish value quickly and to learn what people actually need, then build where the product's limits genuinely constrain you.
That sequence has a quiet advantage: it makes the build specification dramatically better. A team that has used a product for six months knows exactly which twelve things it cannot do, which is a far better brief than a requirements workshop.
Questions We Get Asked
Not always, and the crossover is usually volume. Per-seat products are cheaper at small scale and can become substantially more expensive at large scale. Model three years both ways, including the maintenance cost of a build and the likelihood of price increases on the subscription.
A well-scoped first system typically reaches production in eight to sixteen weeks. Timelines stretch when data readiness gaps surface mid-build, which is why testing data early matters more than any other scheduling decision.
Yes, and it is often the smartest sequence - provided you keep your data portable and avoid designing your processes so tightly around one vendor that leaving becomes a re-organization.
Assume they will. Check contractual protections, keep your data exportable, and be honest about switching cost before you embed the tool into daily work. That cost is the vendor's real pricing power.
