Build vs Buy vs Customize: A Practical Framework

Criteria That Separate the Options in Practice

Once you have answered the differentiator question, two more do most of the sorting: how often does this rule change, and who gets to change it. If a rule changes several times a year and the person who decides sits in the business rather than in engineering, what you actually need is a configurable surface: a rules table, a template, a threshold someone can edit without a deployment. A build satisfies that only if you build the configuration layer too, which is a larger project than the feature itself. A product satisfies it only if the specific rule you change is exposed in configuration rather than compiled into the vendor's code, and that is worth verifying in a sandbox rather than assuming from a feature list.

The second question is who controls the specification. When a process is governed by someone outside your company (a regulator, a payer, a tax authority, an EDI trading partner, a card network), the spec changes on their schedule and compliance is not optional. Products in those categories earn most of their price by tracking those changes: sales tax rate and sourcing rules, e-invoicing mandates, EDI transaction set versions, payment card scope. Building means adding "watch the spec and ship before the deadline" to your team's standing responsibilities, permanently. That is why a function that looks simple in code is still often worth buying.

Fit is easiest to judge at the data model rather than the feature list. Ask whether your entities exist in the product as first-class records with their own identifiers, relationships and permissions, or whether you would have to represent them by overloading something else: encoding structure inside a notes field, using a picklist as a foreign key, creating placeholder customer records for things that are not customers. Each of those workarounds blocks reporting immediately and becomes a migration problem later. A product with fewer features that models your world correctly is usually the better buy.

Then count exceptions instead of arguing about them. Take a hundred real transactions from last quarter and sort them into the ones the standard path handled and the ones where a person intervened, then group the interventions by kind. Twenty exceptions of one kind is a configuration change or a feature request. Twenty exceptions of eighteen different kinds is a process problem that no software of any origin removes, and building for it produces the most branch-heavy, least maintainable code you will ever own.

Where the Obvious Answer Is Wrong

The most common mistake is treating one system as one decision. "Our quoting system" is usually a commodity core (catalog, versioning, approval routing, document generation, e-signature) plus one or two rules that are genuinely yours, such as how you price a nonstandard configuration or how you allocate scarce capacity. Split it by hand before deciding: list the capabilities and mark each one commodity or specific. The pieces you cannot confidently mark either way are usually the ones nobody can explain well enough to specify, which is the clearest evidence that they do not belong on the same side of the line.

Being core is not by itself a reason to build, because most of the work often sits underneath the part that differentiates you. If your advantage is how you route field technicians, the routing heuristic is yours, but the map data, geocoding, traffic model, and the mobile client's offline sync are not, and they will consume most of the build. The same shape appears with relevance ranking on top of a search index, fraud rules on top of a payment processor, and scheduling logic on top of a calendar system. Buy the substrate, build the decision layer, and you own something much smaller. The reverse case also exists: a genuinely commodity function that you have to build because of a constraint rather than an ambition, such as a network with no outbound internet access, a data residency requirement no vendor meets, per-event pricing that does not survive your transaction volume, or a vendor that will not accept your contract terms. Label those builds as constraint-driven, because they should be kept as small and as boring as possible rather than grown into a platform.

The comparison most teams run is annual subscription spend against an estimated build cost. The direction it points usually holds, but both numbers are softer than they look, and they are soft in opposite directions. Subscription spend is elastic and reversible: seat counts move, tiers get renegotiated at renewal, modules get dropped, and when you stop using the product you stop paying for it. Money already spent on a build is not recoverable whether or not the system stays in use. The build figure is also a construction estimate, which means it typically omits the line items that begin at launch: language and framework major-version upgrades, dependency and security patching, someone carrying a pager, rebuilding environments when a managed service is deprecated, secret and certificate rotation, and bringing a replacement up to speed on a system whose author has moved on. None of that argues against building. It argues for putting the license figure next to a build figure that includes those items, rather than next to the estimate to reach launch.

What Each Choice Costs You Later

The exit cost of a purchased product is not in the contract, it is in what you can extract. During evaluation, ask for a full export and check three things specifically: whether custom fields come with it, whether attachments come with it, and whether the audit history comes with it. Attachments and history are the two most often missing, and history is frequently the one you are required to retain. Beyond the data, three things bind you in ways a contract clause will not fix. Vendor record identifiers become load-bearing once they appear in your warehouse, in other systems' integrations, and on printed documents. Logic built in the vendor's workflow or rule engine has no export format and has to be reconstructed by reading configuration screens. And identity integration means switching the product also means touching directory groups and provisioning rules that other systems depend on.

For a build, the stack is a hiring decision. Runtime, framework and database determine how large a pool you can recruit from and how quickly a new person becomes productive; a niche language or a homegrown framework narrows that pool at exactly the moment you most need it wide. The build is also a decision to operate: whatever you write, you also monitor, back up, restore, patch and answer for at two in the morning. And be deliberate about what stops being yours to change. Code is the easy part. The schema is harder, and anything you have exposed outward (an API a customer's system calls, a file layout a partner parses, a URL that already sits in someone's inbox) becomes a contract you cannot revise on your own schedule.

The later cost of the customize path shows up as upgrade friction, and it depends almost entirely on which surfaces you built against. Customizations that use documented extension points (published APIs, webhooks, plugin interfaces, supported scripting hooks) tend to survive upgrades because the vendor regression tests them. Customizations that read internal tables, patch vendor files, or rely on undocumented behavior break on a release whose timing you do not control, and often break quietly. The predictable end state is a pinned version, and staying pinned to keep working means declining security fixes. So evaluate the extension surface as a product in its own right: is it documented and versioned, is there a sandbox that runs the next release before you get it, is there a deprecation policy with a notice period long enough to act on.

Test the Decision Before You Commit To It

All three options can be tested for a small fraction of what choosing wrong costs, usually in days rather than quarters.

• Run your worst records through the trial, not the demo data. Load the transactions your current process chokes on: the partial shipment, the credit against a voided invoice, the customer who is also a supplier, the order that spans two currencies or two tax jurisdictions. You already know the standard path works, because that is what the demo showed you.
• Spend a day against the API before signing anything. Authenticate, create a record, read it back, list everything changed since a timestamp, and deliberately trip the rate limit to see what comes back. Check two things in particular: whether the write API covers what the UI can do (read APIs are often complete while write APIs are partial), and whether there is a reliable changed-since query or event stream. Without one, every integration you build later degrades into full-table comparison on a schedule.
• Ask for the API documentation and a sandbox before the contract, not after. If both are gated behind a signature, that is itself a finding about how the integration work will go.
• Inventory the spreadsheets. The side files, shared docs and email threads that have grown around your current system are a written specification of the gap. Count them, then mark which ones a product's configuration could absorb and which encode a rule nobody has ever written down. The second group is where the real decision lives.
• For a build, prototype the data model and the three hardest business rules first, not the screens. Screens are the predictable part of the estimate. If the entities and their relationships will not fit on one page, you do not have a specification yet and any number attached to it is invented.
• Write the kill criterion before the pilot starts, with a date and a named decision maker. Pilots without one become deployments by default, because ending them requires someone to actively argue for stopping while the alternative requires no one to do anything.

Failure Modes Specific to Each Option

Buying fails in three recognizable ways. Per-seat pricing quietly shapes who has access, and shared logins are the visible symptom; data quality drops because the person who holds the information is not the person holding the seat. Configuration drift sets in around eighteen months, when nobody can say why a rule is set the way it is, so ask during evaluation whether the product keeps a change log of configuration and not only of data. And vendor risk is usually mispriced: an acquisition or sunset rarely switches the product off, it stops the product improving while the renewal price goes up. Worth noting too that a product configured deeply by one administrator carries the same single-owner risk people associate only with custom code.

Building fails differently. The half-finished second system becomes a permanent fork of the first. Features accumulate because they were easy to add rather than because anyone asked. Business rules ship without tests, so nobody is willing to change them and workarounds grow around the code instead of in it. And there is no support channel: a purchased product has a number to call at two in the morning, while an internal one has whoever happens to answer.

The customize path fails at the boundary. When the platform and the custom piece both hold a version of the same entity and no one has designated an owner field by field, the two drift and reconciliation becomes permanent work. Integration by scheduled file transfer fails the same way every time: the job stops, nobody notices because nothing errors, and the gap surfaces weeks later in a report. Alert on staleness (no file or no message since a threshold) rather than only on failures, and decide the record of truth per field before the first integration is written, because retrofitting that decision means reconciling history.