Most AI products should not be entirely custom-built.
They should also not be assembled blindly from vendors until the team no longer controls its own product.
The useful decision is not simply build or buy. It is deciding which capabilities create strategic value, which are commodity infrastructure, and where a thin custom layer can connect proven services into a differentiated workflow.
Three available strategies
Build
You own a custom implementation designed around your users and operating model.
Build when: the workflow is genuinely differentiating, commercial products cannot support an important constraint, or ownership of the behaviour and data creates strategic advantage.
Watch for: a larger initial investment, ongoing maintenance and the temptation to recreate commodity capabilities poorly.
Buy
You adopt a commercial product that already solves most of the requirement.
Buy when: the capability is common, the vendor’s workflow is acceptable, integration is straightforward and the subscription costs less than owning the complete lifecycle.
Watch for: pricing that scales badly, restrictive data access, weak export options, roadmap dependence and a user experience shaped around the vendor rather than your product.
Wrap
You combine third-party models, platforms or products behind a custom experience and set of business rules.
Wrap when: proven services cover the technical primitives but your workflow, data, orchestration or customer experience is the differentiator.
Watch for: thin differentiation, vendor lock-in and the false belief that connecting APIs removes operational responsibility.
Start with the customer outcome
Teams often begin the decision with a preferred technology: “Should we build our own model?” or “Can we do this with platform X?”
Begin one level higher. What must change for the customer, and which part of that change must your business uniquely control?
If the value lies in deciding which dealership conversations need action and connecting them to service operations, owning a foundation model is probably irrelevant. The valuable asset may be the workflow, the domain rules, the integration layer and the feedback data.
Use six decision tests
1. Differentiation
Would a competitor using the same vendor produce essentially the same customer experience? If yes, buying may be fine for a supporting capability but weak as the centre of the product.
2. Time to evidence
Which option gets the riskiest product assumption in front of real users soonest? A bought component may accelerate validation even if it is replaced later.
3. Total cost of ownership
Compare implementation, subscription, usage, integration, support, security, migration and exit costs. A low monthly fee can become expensive at scale; a custom build can become expensive when routine maintenance is ignored.
4. Control and reversibility
Can you export the data, change the provider and reproduce important behaviour? Prefer decisions that preserve options while the product is still learning.
5. Risk and compliance
Determine where data is processed, how access is controlled, what is retained and whether the vendor’s assurances meet the actual consequence of failure.
6. Team fit
A technically elegant architecture is a poor choice if nobody can operate it. Consider the capability you have, can hire, or want a partner to provide.
The strongest answer is usually a portfolio
A credible product architecture deliberately mixes the three strategies:
- buy identity, payments and commodity communications where mature services fit;
- wrap model providers behind a boundary that allows evaluation and replacement;
- build the workflows, policies, data products and customer experience that make the business distinct; and
- keep operational evidence around every dependency.
This is not less ambitious than building everything. It is a more disciplined use of custom engineering.
Avoid irreversible shortcuts
Early products need speed, but not every shortcut is equal. A manual back-office step is often reversible. Storing core customer data in a system with no reliable export is not. A single model provider behind a clean interface is reversible. Encoding its behaviour throughout the application is not.
Make fast decisions at the edges and careful decisions around identity, data, core workflow and ownership.
What to record in the PRD
For each major capability, record:
- the customer outcome it supports;
- whether it differentiates the business;
- candidate build, buy and wrap options;
- the evidence needed to choose;
- the exit path if the assumption changes; and
- who will operate the selected option.
This turns an architecture debate into a commercial decision framework.
Unsure which parts of the product should be custom?
The AlanOps Build Readiness Sprint tests the workflow, integrations, architecture and commercial options before delivery is quoted. You receive a clear recommendation, including where not to write custom software.