At some point most growing businesses reach the same crossroads. The tools you use have started to get in the way. Staff export data to spreadsheets to do what the software cannot. Someone suggests building something of your own, and someone else points out, reasonably, that there are dozens of products that already do this.
Both instincts are right some of the time. Packaged software is excellent when your needs are common. Custom software is excellent when they are not. The hard part is telling which situation you are in, and being honest about the real costs on both sides.
This article gives you a framework for that decision. It covers what each option really costs over time, where each one tends to fail, the signals that point toward custom development, and a middle path that is often the best answer. If you want a companion to this piece, we also wrote about how to know if your business needs custom software.
What we mean by each option
Off-the-shelf software is a product built for many customers. You subscribe or buy a licence, configure it within the options it offers, and use it more or less as designed. Accounting packages, standard CRMs and project tools fall into this group.
Custom software is built specifically for your organisation. Its features, workflows and data model follow your process. You usually pay to have it built, then pay for hosting and maintenance.
There is also a middle category: configurable platforms, such as ERP systems, that can be heavily adapted through settings, add-ons and development. We come back to these near the end.
The real cost comparison
Most comparisons stop at the upfront price, which is where off-the-shelf looks cheap. A fair comparison looks at the whole life of the software, typically five years or more.
| Cost area | Off-the-shelf | Custom |
|---|---|---|
| Upfront | Low to moderate (setup, configuration, training) | Higher (design and development) |
| Recurring | Subscription, often per user, often rising | Hosting and maintenance |
| Growth | Cost rises with users, modules and tiers | Mostly flat as users grow |
| Workarounds | Staff time spent bridging gaps | Little, because it fits the process |
| Change requests | Wait for the vendor, or pay for add-ons | Scheduled on your roadmap |
| Exit cost | Data export and retraining | You own the code and data |
Neither column wins automatically. A five-person team with standard needs will almost always be better off with a subscription. A sixty-person company paying per-user fees for a tool they still have to work around is a different story.
For a sense of the upfront investment on the custom side, see our custom software cost guide, which lays out typical ranges by project size.
Where off-the-shelf works best
Choose packaged software when:
- Your process is standard. Invoicing, payroll, email and general project tracking are solved problems. Reinventing them rarely pays.
- Speed matters more than fit. You can start using a product in days.
- You have no technical capacity. The vendor handles hosting, security and updates.
- The category is crowded and mature. Competition keeps quality high and prices fair.
- The software is not a competitive advantage. If it does the same job for you as for everyone else, there is no reason to own it.
Where off-the-shelf fails
It tends to struggle in predictable ways:
- Workarounds multiply. Staff copy data between tools, keep side spreadsheets and follow unwritten rules to get around limitations.
- Per-user pricing stings at scale. A fee that seemed small for ten people becomes significant for a hundred.
- Integrations are thin. Two tools that "integrate" often exchange only part of the data you need.
- You adapt to the software. Your process bends to match the product, rather than the other way round.
- Vendor decisions affect you. Features change, prices rise and products are discontinued, and you have little say.
Where custom software works best
Choose custom development when:
- The workflow is your advantage. If how you do something is what sets you apart, software that mirrors it protects and scales that edge.
- You are paying for gaps. The hours lost to workarounds, duplicated entry and errors can be added up. When that figure exceeds the cost of a proper solution, custom starts to make sense.
- You need systems to talk to each other. A custom layer can connect your tools with the exact data flows you need.
- You serve customers through the software. A customer portal, booking system or marketplace is part of your product and brand, not just an internal tool.
- You expect to grow. Flat running costs and freedom to extend are valuable as headcount and volume rise.
Where custom software fails
Honesty requires covering this side too. Custom projects go wrong when:
- The scope is vague. Building without clear requirements is the main cause of overruns. We cover how to avoid this in how to write a software requirements document.
- The first version tries to do everything. Large first releases take long and learn slowly. Start small, as described in MVP vs full product.
- Nobody owns it afterwards. Software needs updates, hosting and security patches. Plan who looks after it.
- The vendor is wrong. A poor developer can leave you with code nobody can maintain. Our guide to choosing a software development company covers how to avoid that.
- A packaged tool would have worked. Sometimes the honest answer to a request for custom software is "buy this instead".
A six-question framework
When a client asks us whether to build or buy, we work through these questions. Score each honestly.
- Fit. Could a packaged product cover at least 80 percent of what you need with no workarounds?
- Differentiation. Is this software part of what makes your business different?
- Volume. How many users, records or transactions will it handle in three years?
- Integration. How many other systems must it exchange data with, and how accurately?
- Capacity. Do you have the time and appetite to specify, test and own a custom system?
- Cost over time. What will the subscription cost at your projected size in five years, plus workaround time?
If the answers mostly say "standard process, small team, low volume", buy. If they say "unique process, growing team, many integrations, strategic importance", build. If they are mixed, read the next section.
The middle path: configure, extend, integrate
Many businesses get the best result by combining approaches rather than choosing one.
Start with a packaged product for the standard parts. Accounting, email and general collaboration rarely need customising.
Build custom only where you differ. The booking rules, pricing logic or client portal that make your service unique can be developed on top of, or alongside, standard tools.
Connect them properly. A small custom integration layer that moves data accurately between tools often delivers most of the benefit of a full custom system at a fraction of the cost.
Consider a configurable platform. ERP and CRM platforms such as Odoo can be shaped to a business through configuration and modules, with custom development for what is left. We explain where to draw the line in Odoo customisation: configure, customise or leave alone, and you can hire Odoo developers if you want help with that route.
Examples from different businesses
Some short, generic scenarios show how the framework plays out.
- A five-person design studio needs invoicing and project tracking. Standard tools fit. Buy.
- A clinic chain wants online booking tied to its own scheduling rules and patient records. The rules are specific and the software is customer-facing. Custom, or a configurable platform extended for the clinic's process. See our healthcare software page for how we approach this.
- A distributor uses four tools that do not share data, and staff re-key orders daily. A custom integration or a unified system would pay for itself quickly.
- A growing retailer pays rising per-user fees for a point-of-sale system that cannot handle its loyalty scheme. Time to consider a custom retail system or a better-matched product.
How to reduce the risk of going custom
If you decide to build, these habits protect your investment.
- Begin with a small first release and expand based on real use.
- Write down the requirements and agree what is in and out of scope.
- Insist on ownership. The code, data and documentation should be yours, in your own repository.
- Deliver in stages, so budget and progress stay visible.
- Use proven technology. Mainstream frameworks such as Laravel make it easy to find other developers later.
- Plan maintenance from day one, including hosting, backups and updates.
A decision checklist
Before you commit either way, make sure you can answer these.
- What is the real annual cost of our current tools, including staff time spent on workarounds?
- Which parts of our process are genuinely unique, and which are standard?
- What will the subscription cost at our expected size in five years?
- Who will use the system, and how many of them?
- What other systems must it connect to?
- What is the smallest useful first version?
- Who will own and maintain it afterwards?
Final thoughts
The choice between custom and packaged software is not a matter of preference. It is arithmetic plus judgement: add up the true cost of each path over several years, and be honest about how different your process really is.
If you are weighing the options, we are happy to look at your situation and tell you plainly which route we think fits, including when that means buying something off the shelf. Get in touch and describe what is not working today, and we will take it from there.