Build, Buy, or Configure: A Decision Framework

The usual framing is build versus buy, and that framing is why the decision goes wrong so often. There is a third option that covers most cases well: configure — take an existing platform and shape it to your process through its own extension points, without writing a system from scratch.

Three options, each with a distinct profile:

The question that decides it

Not "what can we afford" and not "what do competitors use." The question is:

Is this process a source of competitive advantage, or is it table stakes?

Table-stakes processes — payroll, accounting, email, calendars, document storage, e-signature — should be bought. There is no advantage available in doing payroll differently, and a vendor with thousands of customers will do it better than you can. Buying anything in this category is almost always correct.

Processes that are the reason clients choose you should not be forced into someone else's model. If your fulfilment sequence, your quoting logic or your quality control is genuinely part of why you win, then bending it to fit a generic tool means giving up the thing that differentiates you in exchange for a licence fee.

Most companies have between one and three processes in the second category. Everything else belongs in the first. The error is treating everything as one or the other.

When to buy

• The process is standard and you have no unusual requirements
• A mature product exists with a real customer base in your category
• You can export your data in a documented format
• Per-seat cost stays sane at the headcount you expect in three years
• You are willing to adapt your process to the tool

That last condition is the one to be honest about. Buying and then working around the product produces the worst outcome available: a subscription plus the workarounds it forced. If you are going to fight the tool, you have not really bought anything.

When to configure

Configuring is right far more often than it gets chosen, because it is unglamorous. It means starting from a platform and using its intended extension points: custom fields, automations, webhooks, an API, a scripting layer.

Choose it when:

• Roughly 70–90% of your process matches the platform's model
• The gap is in workflow and reporting rather than in the core data model
• The platform has a genuine API — not "integrations available," an actual documented API
• You can accept the vendor's data model, because that is what you are inheriting

The failure mode to watch for is configuration that keeps growing until you have built a system inside someone else's product, with all the constraints of both. If configuration work exceeds roughly a third of what building would cost, and the platform is still fighting you, the answer was build.

When to build

• The process is genuinely non-standard, and that is why clients choose you
• You have tried a product and the gap is in the data model, not the workflow
• Per-seat licensing has become the dominant cost as headcount grew
• You need integration between systems no vendor connects
• The process will keep changing, and each change through a vendor is a support ticket and a wait

Building is also correct in a case people rarely name: when the cost of the workarounds already exceeds the cost of building. That is a calculation worth running rather than assuming. SaaS Subscriptions vs Custom Software: The Five-Year Math works through it with numbers.

Costs that get left out

Buy: per-seat cost at future headcount, not current. Integration work to connect it. Data extraction if you leave. Feature requests that never arrive because you are not a large enough customer.

Configure: platform subscription plus the configuration maintenance. Whether your configuration survives the vendor's major version upgrades. Whether the person who understands the configuration is documented or just employed.

Build: maintenance at roughly 15–20% of build cost annually. Hosting. The handover risk if the builder disappears — which is a contract issue, covered in what to put in an agency contract.

The sequence that avoids expensive mistakes

1. Write down the actual process, exceptions included. Do this before evaluating anything — most tool evaluations fail because nobody knew what they were evaluating against.
2. Split it: which parts are standard, which are genuinely yours?
3. Buy the standard parts. All of them, without debate.
4. For the rest, try to configure first. Set a budget for the attempt and a criterion for abandoning it.
5. Build only what remains, and only if configuring failed for a reason you can articulate.

Step one is where the value is and the step most often skipped. A decision made without a written process is a decision made on someone's recollection of the process, which is how companies end up with a tool that handles the happy path and nothing else.

The most common wrong answer

Building something table-stakes because it felt strategically important, or buying something differentiating because it was cheaper this quarter.

The first wastes money. The second wastes the advantage.