Build vs Buy: Off-the-Shelf or Custom Software for Your Business?

Here is something a custom software studio probably should not open with: most of the time, you should buy the off-the-shelf tool. Accounting, email, payroll, video calls — these are solved problems, and rebuilding them is how budgets are vaporised.

The interesting question is where “most of the time” ends. Because there is a moment in many companies’ growth where the standard tool stops fitting — and recognising that moment early is worth a lot of money in both directions.

The 80% rule

Our rule of thumb: if an existing product covers 80% or more of your actual workflow out of the box, buy it and adapt your remaining 20% to the tool. The economics of SaaS — shared development cost across thousands of customers — are unbeatable for common problems.

The rule cuts the other way too. When the coverage is closer to 60%, your team spends its days in the gap: exporting, re-importing, maintaining “the spreadsheet that fixes the system.” That gap has a payroll cost, an error cost and a morale cost — it just never appears as a line item, so nobody budgets it.

The real comparison: total cost of ownership

Compare a three-year horizon, not a purchase price:

Buying means subscription × seats × 36 months, plus the workaround hours in the gap, plus the price increases you do not control, plus the day the vendor sunsets the feature you depend on. For a 15-person team on a €40/seat tool, that is over €21,000 — before counting a single workaround hour.

Building means a one-off project (see our honest cost breakdown — focused internal tools land in the low five figures or less), plus maintenance around 10–20% per year. No per-seat math: user 5 and user 50 cost the same. And it fits 100% of the workflow, because the workflow is the spec.

Neither column wins universally. The point is to actually run both columns — most companies only ever price one.

Signs off-the-shelf is enough

Be honest about these — they save you from an expensive vanity build:

• Your process is standard for your industry (if every competitor does it the same way, a product already serves it well).
• The volume is low and the stakes are modest.
• You need it next week, not next quarter.
• Nobody in the company would own a custom tool’s evolution.

Signs you’ve outgrown it

These are the patterns we see again and again in custom software projects that should have started a year earlier:

• Workflow contortions. Your team has changed how it works to satisfy the tool, not the customer.
• Spreadsheet glue. The real process lives in spreadsheets that bridge two systems, maintained by one heroic person.
• Per-seat pain. You hesitate to give someone access because of what the next seat costs.
• Data silos. The numbers exist, but assembling them for one decision takes a day of exports.
• Feature-request purgatory. The improvement your operation needs has been “on the vendor’s roadmap” for two years.

Three or more of these and the 80% rule has already flipped — you are paying custom-software costs in workaround hours while getting off-the-shelf limitations.

The hybrid path

The strongest pattern is rarely all-build or all-buy: buy the commodity, build the differentiator. Keep the standard accounting package and CRM — then build the custom layer that is actually yours: the quoting logic only your business has, the production planning that fits your floor, the integrations that make your tools talk to each other. You get SaaS economics where you are ordinary and a custom edge where you are not.

The 5-question checklist

Before any build-vs-buy decision, answer these in writing:

1. Does a product cover 80% of our real workflow? Demo it against your actual process, not the vendor’s demo script.
2. What does the gap cost per month? Hours × people × error rate. Put a number on it, even a rough one.
3. Is this process a differentiator or a commodity? Build only what makes you different.
4. What is the 3-year cost of each path? Subscriptions compound; builds amortise.
5. Who owns it on day 400? A vendor roadmap on one path; on the other, your code, your call — if your partner hands over everything properly.

If the answers point to building, scope it honestly with someone senior before believing any quote — a free, no-pressure version of that conversation is exactly what our discovery call is for.

Frequently asked questions

Isn’t custom software risky for an SME? The risk is concentrated in how it is built, not in the decision itself: fixed quotes, milestone payments, weekly demos and full code ownership remove most of it. Open-ended builds with vague scope deserve their reputation.

Can we start off-the-shelf and migrate later? That is often the ideal sequence: the tool teaches you your real requirements cheaply. Just keep your data exportable — the lock-in to fear is data, not contracts.

What about low-code platforms as a middle ground? They are genuinely useful for internal tools — until volume, complexity or licensing terms find their ceiling. Treat them as “buy” with extra flexibility, and apply the same 80% rule.

How long does a custom build actually take? Focused tools: roughly 6–12 weeks from kickoff to production, with working software visible weekly along the way. The calendar killer is not the code — it is undecided scope.