When Should a Business Build Custom Software?

“Should we build this ourselves?” is one of the most consequential questions a growing business asks about technology, and it is usually asked at the wrong moment — either in frustration after a packaged tool has failed, or in excitement after seeing something a competitor has. Neither is a good state to decide in.

This article sets out how we think about the decision at Qumaxa, including the cases where our honest advice is don’t build.

The three options

There are really three choices, not two.

Buy. Use a packaged product as it comes. Fastest to start, lowest initial cost, and you benefit from every improvement the vendor ships. The price is that you work the product’s way.

Customize. Take a packaged product — very often an ERP or accounting platform — and extend it: reports, interfaces, enhancements, forms, workflows. You keep the vendor’s core and add what is specific to you. This is a large part of what ERP consulting actually is.

Build. Design and develop software around your own processes. Highest control, highest fit, and the highest responsibility — you own it, including everything that goes wrong.

Most organizations end up with a mix: packaged software for the commodity functions (email, accounting, payroll), customization where a platform is close but not quite right, and custom software only where the process is genuinely theirs.

Signs you have outgrown packaged software

These are the patterns that, in our experience, mean a packaged tool is costing more than it saves.

• The process lives in spreadsheets around the tool. The software holds the official record, but the real work happens in exports, macros and shared files that feed it. The spreadsheets are the system; the tool is a filing cabinet.
• People have stopped using features because they fight the process. A tool configured so heavily to avoid its own workflow is telling you something.
• Integration is manual. Data moves between systems by someone exporting from one and importing into another, on a schedule, by hand.
• The process is your competitive advantage. If how you handle orders, or claims, or client onboarding is part of why customers choose you, forcing it into a generic shape costs you something that does not show on an invoice.
• You are paying for a hundred features and using six. Enterprise licensing for a function that could be a focused internal tool.
• The vendor’s roadmap is not your roadmap. The things you need are “under consideration” and have been for two years.

If three or more of these describe you, building — or at least seriously scoping a build — is worth the conversation.

Signs you have not

Equally important, and less often said by people who build software for a living:

• The process is still changing every month. Custom software locks in a process. If you have not yet settled what the process is, you will be paying to change the software as fast as you change your mind. Run it in a flexible tool first; build when it stabilises.
• The problem is a process problem wearing a software costume. If two departments disagree about who approves what, no application will fix it. Fix the agreement; then automate it.
• A good packaged product exists and you have not really tried it. It is easy to dismiss what you have not configured properly.
• You cannot name the owner. Custom software needs someone inside the business who owns it: decides what changes, tests it, lives with it. If nobody will, it will decay.
• The budget covers building but not keeping. Software is not a purchase; it is a running cost. If there is money for version one and nothing for the years after, buy instead.

We say these things in scoping conversations, and sometimes they end the engagement. That is the right outcome more often than people expect.

How to scope a first module

Suppose the signs point to building. The mistake that follows most often is scoping the whole system at once — every department’s wish list, every edge case, a two-year plan.

Build one module instead.

Pick the process with the worst ratio of effort to value. Not the most important process in the business — the one where the most manual work produces the least. That is where the gain is largest and the risk smallest.

Draw the process as it actually runs, not as the procedure manual says. Who starts it, what they look at, what they decide, where it goes next, what is recorded. Every hand-off is a candidate for automation; every decision is a candidate for a rule or an approval.

Decide the boundaries. What systems does the module read from and write to? What does it not do? A first module that connects cleanly to the accounting system and does one thing well is worth more than one that half-does five.

Define done. Working software that a named person uses for the real process, every day, is done. A demo is not.

Plan the second module only after the first is in use. You will learn more from a month of real use than from any amount of planning.

This is the “modular business application” approach: shared foundations — users, roles, organizations, audit — and modules added one at a time, each paying for itself before the next begins.

What good custom software looks like

Finally, because “custom” is sometimes used as a euphemism for “undocumented,” here is what we think the word should mean.

Clear architecture. Someone who did not build it can read it and understand where things live. Boundaries between the application, its data and its integrations are explicit.

Version control for everything. Not just the code — the configuration, the rules, the integration definitions. You can see what changed, when, and why.

Tested, production-ready code over visual workflow builders. Low-code tools are excellent for prototypes and for processes that will keep changing. For something that runs the business, code that can be tested and reviewed ages better.

Security designed in, not bolted on. Role-based access, encrypted credentials, least-privilege access to other systems, audit logs. These are far cheaper on day one than on the day they are needed.

Documentation and hand-over you can actually use. How to run it, how to change it, how to recover it. If the knowledge lives only in the heads of the people who built it, you have not bought software; you have rented a dependency.

An honest scope. It does what was agreed, says what it does not do, and has a plan for what comes next.

If a proposal — ours or anyone else’s — cannot describe how it meets each of those, keep asking until it can. Building the right software for your business is one of the best investments available to you. Building the wrong one, or building the right one badly, is one of the most expensive. The difference is almost entirely in how the decision is made.

Written by Altaf Hussain Khan, Director, Qumaxa. Qumaxa builds custom software, automates business processes and applies AI for organizations in Pakistan and internationally.