"Should we buy something off the shelf, or have it built for us?" is one of the most consequential technology questions a business asks — and the honest answer is not always the same. As a team that both implements standard products and builds custom systems, we have no reason to push you one way. Here is the framework we actually use to decide.
Start with the truth about cost
The instinct is that off-the-shelf is cheaper. Sometimes it is. But compare the real totals, not the sticker prices.
A package's cost is the subscription — per user, per month, usually billed in US dollars so it drifts with the Pula-dollar rate — plus the add-on modules you need to reach feature parity, plus the hidden cost of the workarounds your team builds around its gaps. A custom system built on an open-source framework like Frappe has a higher upfront build cost, but no per-seat licence fees and full ownership. As headcount grows, the subscription line grows with it; the owned system doesn't.
So the question isn't "which is cheaper today?" It's "which is cheaper over three years, at the size we're actually heading towards?" That reframing changes a lot of decisions.
Then ask: how different is your process, really?
This is the deciding question. Off-the-shelf software encodes someone else's idea of how the job should be done. If that matches how you work, wonderful — buy it and move on. The trouble starts when your process is genuinely different and the package can't bend to it.
There's a reliable way to measure this without guessing. Count the spreadsheets. Count the manual workarounds. Count the reports someone rebuilds by hand every month because the system won't produce them. When a large share of the real work happens outside the software — in side spreadsheets, in someone's head, in a WhatsApp group — the software doesn't fit your business, and no amount of configuration will make it. That is the clearest signal that a custom fit will pay for itself.
Four questions that settle most cases
- Is this process a source of advantage, or just plumbing? Pay to make the things that make you you fit perfectly. Buy the standard plumbing (basic accounting, email) rather than building it.
- Does a good package already exist for it? If a mature, well-supported product does exactly what you need, building your own is usually vanity. Don't rebuild solved problems.
- How much does the misfit cost you? Put a number on the workarounds — the hours re-keying data, the errors, the month-end scramble. If it's small, live with the package. If it's a tax you pay every week, custom starts to look cheap.
- Where must the data live, and who must it talk to? If you have data-residency needs or several systems that must share information, a self-hostable, API-first custom system (see why Frappe is powerful) often wins on both counts.
The answer is often "both"
The most pragmatic outcome is rarely all-or-nothing. Use a standard product for the common parts, and build — or extend on a framework — only the piece that is genuinely yours. Because frameworks like Frappe ship with an API, that custom piece can connect to the rest of your stack instead of forcing a full rip-and-replace. You get the maturity of packaged software where it fits, and a perfect fit where it counts.
A note on ERP specifically
If the thing you're weighing is a full ERP — one system for finance, HR, inventory and the rest — that's a bigger buying decision with its own trade-offs, vendors and pitfalls. We cover that in depth on our ERP-focused site, erpbotswana.co.bw, so we won't rehash it here. This article is about the broader build-vs-buy call for business software of any kind.
The right decision is the one that fits your process, your budget and where your business is going — not a rule of thumb. If you'd like a straight, vendor-neutral read on your specific situation, that's exactly what our consultancy is for. We'll tell you to buy the package when that's the honest answer — and build you something that fits when it isn't. Talk to us.
Frequently asked questions
Is custom software always more expensive than a package?
Not always. A package looks cheaper because the upfront price is small, but per-user subscriptions, add-on modules and the workarounds your team builds around its gaps all add up. A custom system on an open-source framework like Frappe has a higher build cost but no per-seat licence fees, so over a few years the totals can be closer than they first appear — especially as your team grows.
How do I know if my process is unusual enough to justify custom software?
A good test: count the spreadsheets and manual workarounds your team keeps alongside the 'official' system, and the reports someone rebuilds by hand every month. If a lot of the real work happens outside the software because the software can't hold it, your process doesn't fit the package — and that's the strongest signal for a custom fit.
Can I mix both — a package plus something custom?
Yes, and it's often the smartest answer. Use a standard product for the common parts and build (or extend on a framework) only the piece that's genuinely different to your business. Because frameworks like Frappe have an API out of the box, a custom piece can connect to your other systems rather than replacing everything.
How Apjakal can help
Get a custom system that fits how you actually work
Tell us about the process stuck in spreadsheets or the package that almost fits, and we will give you an honest read on what a custom system on Frappe would take.