Build vs buy for regulated industries: a decision framework

The wrong way to make this call

Build vs buy gets framed as a technical decision. It is not. It is a commercial-leverage decision dressed in technical clothes, and most teams that get it wrong got it wrong because they ran the wrong evaluation.

The usual flow looks like this. A team has a need. Vendor X has a product that covers 70 percent of the need on day one. The remaining 30 percent is "in the roadmap." The team buys. Eighteen months later that 30 percent is still in the roadmap, configuration limits have started to bite, the vendor's pricing has compounded, and the team is rebuilding the integration layer for the third time. The technical decision was correct in isolation. The commercial trajectory was not.

Regulated industries amplify this trajectory by a factor of about two. Compliance constraints narrow your options, audit requirements demand artefacts that generic SaaS doesn't natively produce, and the cost of swapping the system out grows roughly linearly with the number of regulator filings that depend on it. By year three you are not running a vendor relationship - you are running a containment programme.

This post is the framework we use when a client asks us where the line sits.

The five inputs that actually decide

Ignore the framing of "core vs context" - it doesn't survive contact with a regulated environment, because half of what regulators care about looks like context until the auditor arrives. The five inputs that actually decide are:

1. Policy surface

How much of your business logic is policy vs mechanics?

Mechanics are the things every system in the category does: store records, send notifications, generate reports. SaaS handles mechanics well, because mechanics are the same across customers.

Policy is the things specific to your operating model: tier qualification rules, member-priority overrides, regional escalation routing, the way a refund interacts with a loyalty pack and a promotional voucher. SaaS handles policy badly, because policy is where each customer is different, and a configuration UI can only express a finite number of policies.

If your policy surface is small (you can write the entire decision logic on one page of A4), buy. If it spans multiple departments and changes quarterly, building is increasingly justified.

2. Audit trail granularity

What does your regulator actually want to see?

If the answer is "completion dashboards by user, by month, by region, exportable to PDF with an immutable timestamp" - that's the standard ISO/SOC bar, and most enterprise SaaS clears it.

If the answer is "every state transition on every record, with the actor, the source IP, the input payload, and the prior state, retained for seven years" - now you're at financial-services or public-sector bar, and you are likely going to be either building it or paying the vendor enough to build a custom version that you may as well own.

The audit-trail spec is the most underrated input in build vs buy. Get it from your compliance team in writing before you talk to vendors.

3. Integration depth

Count the systems that the new platform needs to talk to. Then for each one, ask: does the vendor have a maintained connector, or are we going to maintain the integration?

A pattern we see often: a vendor lists "100+ integrations" on their marketing page. On closer inspection, 8 are maintained, 30 are community-maintained (i.e. one engineer at a small company), and 60 are "available via webhooks" which means write your own.

If you have three or more deep integrations into operational-criticality systems (core banking, ERP, MES, billing), and at least one of them isn't on the vendor's maintained list, your real cost is the integration layer you'll be running for a decade. Often this number alone tips a buy decision to a build.

4. Switching cost in year three

Run this thought experiment honestly: if in year three the vendor doubles its pricing, gets acquired by a competitor, or starts deprecating the feature you depend on - what does it cost to move off?

Cost is not just the migration project. It is also:

• The compliance re-filings (every regulator who certified the previous system needs to recertify the replacement)
• The integration rewrites (each downstream system is now a project)
• The training (every operator who learned the previous system relearns)
• The reporting continuity (auditors want apples-to-apples year-over-year)

Quote a build-or-buy decision in terms of three-year total cost including this exit scenario. Many SaaS deals that look 60 percent cheaper at year one are 30 percent more expensive at year three when exit cost is included.

5. Talent supply

The unspoken input. If your industry has thin technical talent supply (regional banks in second-tier markets, ministry IT departments, energy operators in remote markets), buying is more defensible even when the long-term economics favour building, because building requires a team you may not be able to assemble or retain.

This is also where a delivery partner changes the maths. Building with an embedded delivery team is structurally different from building with an internal team. We've shipped systems with three-person internal IT teams as the client side, paired with five-person delivery teams from our side, that operate for years afterwards on a small retainer. If you cannot hire the team yourself but you can contract a team that hands over cleanly, the build economics often hold.

A short diagnostic

If you tally three or more "buy" indicators against three or more "build" indicators on your specific situation, you are likely facing a hybrid path rather than a clean choice: a productised platform for the mechanics, a custom layer for the policy and the deep integrations. This is the configuration most of our larger clients settle into - their LMS is bought, their training-compliance reporting layer is built, their core operational system is built, their generic ticketing system is bought.

The two questions to bring to a procurement meeting:

1. What is the policy surface, and which side of it is each candidate strong on? Make the vendor demo your weirdest policy case, not their cleanest.
2. What is the three-year exit cost? Quote two numbers per option: year-one TCO, and year-three TCO including a hypothetical migration. The gap between those numbers is the most revealing single signal in the entire process.

If you'd like a working version of this framework calibrated to your specific situation, book a 30-minute call.