Vertical AI vs Horizontal Platforms: A Buyer's Whitepaper

Every enterprise AI programme eventually reaches the same decision, repeatedly and per use case: buy the product built for this industry, build on a general-purpose platform, or configure something in a system you already own. The decision is usually made badly, on demo quality and vendor relationship rather than on a structured comparison, and the consequences are expensive in both directions: capability rented that should have been owned, and capability built that could have been bought for a fraction. This whitepaper sets out how to make the comparison. It draws on FISTA Solutions' AI enablement work with enterprises making these choices and complements build vs buy ai and the AI procurement for CIOs whitepaper.

What is the actual choice?

Three options rather than two, and the third is frequently overlooked.

Vertical AI product. Software built for a specific industry function, with the domain model, workflow, and often regulatory content embedded. Fast to value where it fits; constrained where it does not.

Horizontal platform build. Capability built on general-purpose AI infrastructure, shaped to the organisation's own processes and integrated with its systems. Slower initially; owned thereafter.

Existing system's AI features. The CRM, ERP, service desk, or collaboration suite already in place, adding AI capability. Cheapest where adequate; least evaluable and least portable.

Most decisions should consider all three, and the third is often the right answer for generic capability that is not worth anyone's engineering time.

Where do vertical products genuinely win?

Condition	Why it favours vertical
Workflow standard across the industry	Nothing to differentiate; product embodies accumulated practice
Vendor holds data you cannot get	Benchmarks, reference content, regulatory libraries
Regulatory content maintained by vendor	Tracking rule changes is their business, not yours
Speed is the binding constraint	Weeks rather than quarters
Capability is a cost of doing business	No competitive return on owning it
Internal engineering capacity is scarce	Opportunity cost of building is high

The strongest case combines several: a standard workflow, maintained regulatory content, and no differentiation available. Tax calculation, sanctions screening list management, and clinical coding reference content are examples where building is rarely rational.

Where do horizontal platforms win?

Condition	Why it favours building
Process reflects how you compete	Standardising it removes the advantage
Deep integration with proprietary systems	Product customisation approaches build cost
Requirements span several products' scope	Buying three creates an integration problem
Control over behaviour and evaluation matters	Products rarely expose evaluation or logs
Data cannot leave your environment	Many products cannot deploy in-boundary
Capability will be reused across functions	Platform amortises; products do not

The last row is the one that shifts over time. An organisation's third and fourth use cases on a platform cost a fraction of the first, while the third and fourth vertical products cost full price each and integrate with neither.

How should total cost be compared?

Honestly, which means including what the licence excludes. A fair comparison covers:

For the product: licence and usage fees over a realistic horizon; integration with your systems; data preparation and the ongoing quality work the product depends on; configuration and any customisation; change management for the workflow the product imposes; internal support and administration; and the cost of the processes you will change to fit it.

For the build: engineering to first production, including the platform components reused afterwards; data and content preparation; evaluation and governance; ongoing maintenance and model changes; support; and the opportunity cost of the engineering capacity.

Two asymmetries are routinely missed. Product comparisons understate integration and data work, which are frequently the majority of the real cost. Build comparisons understate ongoing maintenance and overstate reuse, because the second use case only costs less if shared components were actually extracted.

Compare over three to five years, not on first-year cost, and include an exit scenario in both. See the AI total cost of ownership model whitepaper.

How does lock-in differ?

In kind rather than degree. Vertical products lock the workflow and the data model: the organisation's process comes to match the product, and leaving means re-implementing that process as well as migrating data. That lock deepens with configuration and with every adjacent process that grows around it.

Horizontal platforms lock architecture and skills. The organisation owns its prompts, evaluation sets, and data, which are portable, but it has taken on the obligation to maintain capability. The risk is not being unable to leave but being unable to sustain.

Neither is inherently worse. The question is which dependency the organisation would rather hold, and that depends on whether the capability is central to how it competes.

How should options be evaluated?

Against your own data, with your own reference set, never on a demo. The method that produces a defensible decision:

1. Build a reference set from real cases with known correct outcomes, before engaging vendors.
2. Require each vendor to run against it, on your data, in a proof of value with defined acceptance criteria.
3. Build a minimal version of the alternative on your platform, timeboxed, run against the same set.
4. Compare quality, integration effort discovered during the exercise, and total cost.
5. Test the exit path in both cases: what you own, what you can export, what it costs to leave.

The step organisations skip is the third, which makes the comparison one-sided. A timeboxed build attempt, even an incomplete one, reveals the integration and data realities that a vendor demo conceals in both directions.

What does the hybrid architecture look like?

The normal outcome, and governable if designed rather than accumulated. The pattern that works has vertical products for standard non-differentiating workflows, platform-built capability where the organisation competes or where integration is deep, and a shared layer underneath both: identity, data governance, evaluation standards, and observability.

The critical design decisions are at the boundaries. Which system owns which data. How a product's outputs enter your systems of record. Whether the product's AI decisions are logged where your governance can see them. And how a user moves between a product's interface and your own without the experience fracturing.

Organisations that let each function buy independently end up with overlapping products, duplicated data, inconsistent governance, and no ability to answer basic questions about what AI is doing across the estate.

What should be asked of vertical vendors?

Beyond the functional demo: which models are used and whether they can be changed; whether your data trains anything; where processing occurs and whether it can be constrained to a region; what evaluation evidence exists and whether you can run your own; whether logs are exportable; what the exit terms are and what you would get back; how model changes are communicated and controlled; and what happens to your configuration if you leave.

Vendors that answer these crisply are usually the better partners regardless of feature comparison, because the answers indicate an engineering discipline that shows up elsewhere. See the AI vendor due diligence whitepaper.

How does the decision change over time?

Toward building for anything reused, and toward buying anything commoditising. As an organisation's platform matures, the marginal cost of building falls, which shifts the boundary. Simultaneously, capabilities that were differentiating become table stakes, which shifts it the other way.

The practical implication is that these decisions should be revisited, not made once. A capability built three years ago because nothing existed may now be available as a product at a fraction of its maintenance cost, and a product bought because the platform was immature may now be the thing constraining the process.

What goes wrong?

Decisions made on demos. Total cost compared on licence versus engineering, omitting integration and data. Products bought per function with no shared governance. Building generic capability that three vendors sell. Renting differentiating capability and discovering the process cannot change. Exit terms unexamined until renewal. And the decision treated as permanent rather than reviewed.

How does organisation size change the answer?

Smaller organisations should buy more than they think and build less, because the platform investment that makes building economical requires a volume of use cases they do not have. A mid-market company with three candidate use cases will not amortise a platform across them, and a partner who builds one system well and transfers it is usually the better route than either a product that does not fit or a platform nobody will maintain.

Large enterprises face the opposite bias. They tend to buy repeatedly for similar problems across business units, ending with six products doing variations of the same thing, none integrated, each with its own governance gap. At that scale the platform amortises easily and the discipline required is resisting the next departmental purchase rather than justifying the build.

Regulated organisations sit apart again, because deployment location, data residency, and explainability requirements eliminate many products outright regardless of fit. For them the question is frequently not which is better but which is permissible, and that should be established before evaluation rather than discovered during procurement.

What decision record should be kept?

A short one, per decision, stating the options considered, the reference set results, the total cost comparison with its assumptions, the exit analysis, and the reason for the choice. Two pages, signed by the accountable owner.

This matters more than it sounds. These decisions are revisited every few years, usually by different people, and the absence of a record means the reasoning is reconstructed from memory and vendor relationships. A decision record also makes the review honest: an organisation that wrote down why it bought can assess whether those reasons still hold, while one that did not will defend the incumbent by default.

How FISTA Solutions delivers this

FISTA Solutions helps enterprises run the comparison properly, building the reference sets that make vendor evaluation evidence-based, timeboxing the build alternative so the comparison is two-sided, and delivering the platform layer that makes hybrid estates governable, through AI enablement, AI agents, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To decide build or buy on evidence rather than demos, message FISTA on WhatsApp, or read build vs buy ai.