Skip to content
Business Foundation

Build vs Buy Software: An Honest Framework for SMEs

SME Academy ·Updated 30 Jul 2026 ·7 min read
Build vs Buy Software: An Honest Framework for SMEs
Key takeaways

Most SME software decisions are made backwards — the tool is chosen before the problem is written down. This framework starts with the honest version of the question, includes the answer nobody sells you (a spreadsheet is sometimes correct), and puts a number on the cost everyone forgets: maintenance.

The build-versus-buy question is almost always asked too late. By the time someone says "should we build this?", a tool has usually already been picked, a vendor has been spoken to, and the actual problem has never been written down in one sentence. So this framework starts earlier than most, and it includes an option nobody will sell you: for a genuine share of SME problems, a well-structured spreadsheet is the correct answer, and choosing it deliberately is not a failure of ambition.

Step 1 — Write the problem as a sentence with a number in it

Before any option is considered, complete this:

"Right now, [who] spends [how long] doing [what], and it costs us [how much] or causes [what error], [how often]."

If you cannot fill in the numbers, you are not ready to choose software — you are ready to observe the process for two weeks. Almost every failed software purchase traces back to skipping this, because a tool bought to solve an unmeasured problem cannot be shown to have solved it, and it never gets removed either.

Step 2 — Consider all four options, honestly

Most people compare two. There are four.

Option Best when Real cost The catch
Do nothing (better) The process is fine; the discipline is missing Free Requires someone to actually enforce it
Spreadsheet, properly built One team, stable process, under a few thousand rows A few days of someone's time Breaks with concurrent editing and no audit trail
Buy off-the-shelf Your problem is a standard problem Subscription + setup + training You adapt to it, not the reverse
Build custom Your process is genuinely your competitive advantage Build + a permanent maintainer It is never finished

The spreadsheet row deserves more respect than it usually gets. A shared sheet with validated columns, one owner and a weekly review will run a small operation properly for years. The three things it genuinely cannot do are concurrent multi-user editing at scale, an audit trail of who changed what, and enforcing a workflow. If your problem does not require those, you may be about to spend money on nothing.

Step 3 — Apply the differentiation test

The single question that decides most cases:

Is this process how we win, or is it just something we have to do?

Payroll, accounting, invoicing, email, file storage, CRM — these are things every business has to do. Somebody has already built a better version than you will, and they maintain it for a living. Buy.

The specific way you route field teams, price your unusual product, or handle a workflow no competitor has — that is not commodity. Build, maybe.

The trap is the middle: a process that feels unique because it is yours, but is actually a standard process with local habits attached. Test it honestly by asking whether the difference is something a customer would notice or pay for. If not, it is a habit, and buying plus adapting is cheaper than building plus maintaining.

Step 4 — Cost it over five years, not at launch

This is where build-versus-buy comparisons go wrong, and the error is always the same direction.

A build quote is a launch cost. The real cost includes everything after:

  • Maintenance and fixes — permanently, not for a warranty period.
  • Platform upkeep — operating system, framework, library and security updates that arrive whether you want them or not.
  • Changes — because your business will change, and the software will not change itself.
  • Availability — someone reachable when it breaks during business hours.
  • Knowledge risk — if one developer built it and leaves, the next person's first task is understanding it.

Write down the five-year total for each option, including a maintainer for the build. The comparison frequently reverses at that point. And note the asymmetry: a subscription stops when you stop paying it; a system you built still needs maintaining whether or not it is still the right system.

Step 5 — If you buy, buy properly

  • Trial with your own real data, not the vendor's demo data. Demo data is chosen to make the product look good.
  • Check the exit before the entry. Can you export your data, in a format you can read, without the vendor's help? If not, price in that you may never leave.
  • Count the integrations you will need, and confirm each one exists today rather than being "on the roadmap".
  • Budget for setup and training, which routinely cost more than the first year's subscription and are the reason most tools go unused.
  • Assign one owner. Software with no internal owner is abandoned within a quarter, regardless of quality.

Step 6 — If you build, build the boring parts first

The failure mode is predictable: the interesting parts get built, the unglamorous parts — reconciliation, reporting, permissions, exports — do not, and the system is unusable for the people who need it daily. Sequence the boring parts first. If the project cannot survive doing them first, it will not survive doing them at all.

Scope it properly before anyone quotes — how to brief a software vendor covers what that document contains — and get realistic about price with what software actually costs in Malaysia. If the answer turns out to be "we need someone senior to own this decision", when do you need a CTO is the next question rather than this one.

Step 7 — Sequence by money, not by enthusiasm

When several processes could be digitised, do the ones that touch money first: invoicing, payments, stock, payroll. They have measurable payback and they are where errors cost most. Digital transformation on an SME budget sets out the full sequencing argument.

Frequently asked questions

Is custom software always more expensive than off-the-shelf?
Over five years, usually — but not always. Where a subscription is priced per user and you have many users, or where a standard product would need heavy customisation and integration work anyway, custom can win. That is why the comparison has to be a five-year total for both, rather than a build quote against a monthly price.

What about no-code and low-code tools?
They are a genuine fourth-and-a-half option and often the right one: much faster than building, more flexible than off-the-shelf. Apply the same discipline — check data export, understand the pricing as usage grows, and remember that someone still has to maintain what you assemble. "No code" does not mean "no owner".

Our processes really are unique. Doesn't that mean we should build?
Perhaps, but test the claim. Ask whether a customer would notice or pay for the difference. Many processes are unique in the sense that no two businesses do them identically, without being unique in any way that creates value. Uniqueness that customers do not perceive is usually just accumulated habit.

How do I know if a spreadsheet has stopped being enough?
Four reliable signals: more than one person needs to edit it simultaneously, you need to know who changed a figure and when, the file has developed rules only one person understands, or a mistake in it has already cost real money. Any two of those and it is time.

Should I hire a developer to build it, or use an agency?
Different question, and it matters — see hiring your first developer vs using an agency. Broadly: an agency for a defined project with an endpoint, an employee for continuous evolution. Hiring an employee to deliver one project, or an agency to be your permanent technology function, are the two common mismatches.


Sources: this guide is a decision framework rather than a factual reference, and deliberately contains no vendor pricing — build costs, subscription prices and maintenance costs vary too widely by scope and supplier for any published figure to be useful. Get quotations for your own scope; our guide on what software costs in Malaysia explains what drives the range and how to obtain a real number.

Recommended tool
Not sure how much SST you'll owe?

Estimate it in under a minute with our free calculator.

Open calculator
Share:

Related guides