When should a business build custom software?

Most businesses should start with off-the-shelf software. It is quick to set up, someone else maintains it, and thousands of other businesses have already found its problems. For accounting, payroll, email and many other jobs, there is no good reason to build your own.

But there is often a point where the tools that helped a business grow begin to hold it back. Work happens around the software instead of inside it. Spreadsheets fill the gaps. People copy the same information into three places.

This article explains how to recognise that point, when to stay with what you have, and how to approach custom software without taking on unnecessary risk.

Signs that off-the-shelf software no longer fits

Your team works around the software

When people keep a spreadsheet next to the system "because the system can't do it", the tool no longer matches the way your business works. One workaround is normal. A collection of them is a sign.

Your tools do not talk to each other

Many businesses use a separate tool for sales, operations, scheduling, invoicing and customer support. Each one is good at its job, but the information between them moves by hand. The cost is not only the time. It is also the errors, and the fact that nobody has a complete picture.

The way you work is your advantage

If customers choose you because of how you do something, such as a faster quote, a more flexible service or a better way of tracking their work, generic software can force you to do it like everyone else. Custom software can protect and strengthen the thing that makes you different.

Licence costs grow faster than the value

Software priced per user or per feature can become expensive as a team grows, especially when you pay for several tools that overlap. This alone is rarely a reason to build, but it changes the comparison.

Your data is hard to get at

If you cannot easily export, report on or combine your own data, decisions get slower and you depend on the supplier's roadmap for features you need.

When not to build

Custom software is the wrong choice when:

• The process is standard. Accounting, payroll and email are solved problems. Buy them.
• You cannot describe the problem. "We need a new system" is not a problem. "We lose two days each month reconciling orders between three tools" is.
• There is no budget for the long term. Software needs updates, security patches and small improvements after launch. If there is no money for that, the system will slowly decline.
• A configuration change would do. Many tools can do more than businesses use. Check the settings, the integrations and the add-ons first.

The options between "buy" and "build"

The choice is not always all or nothing. Often the best answer is in between.

1. Configure what you have. Use the features and settings you are not using yet.
2. Connect your tools. An integration that moves data between existing systems can remove a large amount of manual work without replacing anything.
3. Build a small piece around them. A focused application, such as a customer portal or an internal dashboard, can fill the gap while your other tools keep doing what they are good at.
4. Replace one system. Build a custom replacement only for the tool that fits worst, and keep the rest.

Each step is smaller and less risky than the next. It is worth asking which one solves the problem before you commit to a larger project.

The real costs of custom software

The build is only part of the cost. Plan for these too:

• Hosting and services. Servers, backups, monitoring, email delivery and any paid services that the application uses.
• Maintenance. Security updates, framework upgrades and fixes. Every application needs these, however well it is built.
• Change. Your business will change, and the software must change with it. The first release is the start, not the end.
• Your team's time. Someone must explain the process, test the software and make decisions during the project.

In exchange, you get software that fits the way you work, that you can change when you need to, and whose data you control.

How to reduce the risk

Start with the smallest useful release

Do not try to build everything at once. Agree a first version that solves one real problem for real users, put it into use, and let what you learn shape the next step. This is how we approach custom software development.

Own the code and the data

Make sure your business owns the source code, has access to the hosting, and can export its data. You should be able to move the system to another developer if you ever need to.

Insist on tests and documentation

Automated tests let developers change the system with confidence. Clear documentation means the knowledge does not live only in one person's head. Both make the software cheaper to maintain over its whole life.

Choose established technology

A widely used framework, such as Laravel for web applications, means more developers can work on the system, more libraries are available, and security updates arrive regularly. Unusual technology choices can make a system expensive to support later.

An example of the decision in practice

Consider a business that runs training courses. It uses an online form for bookings, a spreadsheet for course places, an accounts package for invoices and email for joining instructions. Each course means copying the same delegate details into four places, and mistakes happen when a course is busy.

The first instinct may be to replace everything with a custom booking system. But the accounts package works well, and the email tool is fine. The real problem is the gap between them.

A sensible first step is a small application that takes the booking, tracks the places and sends the invoice details to the accounts package automatically. The business keeps the tools that work, removes the copying, and gets one reliable list of who is booked on each course. If it later needs features such as a customer portal or online payment, they can be added to the same application.

This is a common pattern. The custom part is small and focused, and it connects to the off-the-shelf tools around it instead of replacing them.

Questions to ask before you decide

Before you commit, try to answer these questions honestly:

1. What specific problem are we solving, and how do we know it is a problem?
2. What does it cost us today, in time, errors or lost opportunities?
3. Have we checked whether configuration or an integration would solve it?
4. What is the smallest version that would be useful?
5. Who in our business will own the project and make decisions?
6. What budget do we have for maintenance after launch?

If you can answer these clearly, you are in a good position to decide. If you cannot, the next step is to find the answers, not to start building.

The short version

Buy software for standard problems. Connect your tools before you replace them. Build custom software when the way you work is distinctive, when workarounds have become a real cost, and when you can commit to looking after it.

If you are not sure which side of that line you are on, talk to us. We will tell you honestly if an off-the-shelf tool or a simple integration is the better answer.