Custom software vs off-the-shelf: an honest guide for small teams

I build custom software for a living, so you might expect me to tell you to build custom. Often I tell people the opposite. The right choice depends on how your business works, how many people use the tool, and how much your process is part of what makes you good. This guide is the framework I use with every small team that asks.

The short answer

Use off-the-shelf software for jobs that every business does the same way. Build custom for the jobs that make your business different, or where the gaps between your tools are costing you real time and money.

When off-the-shelf is the right call

• The job is standard: accounting, payroll, email, basic invoicing, simple appointment booking.
• A tool already fits how you work with only small compromises.
• You need it working this week, not next month.
• Your team is small and the process is still changing every few weeks.
• You do not want to think about hosting, updates or security at all.

In these cases a ready-made tool is faster and usually cheaper. You get a product that thousands of other businesses have already tested. Take it, set it up properly, and spend your energy elsewhere.

When custom is worth it

• Your process is unusual, and bending it to fit a generic tool would make your team slower.
• You are paying for several tools that do not talk to each other, and someone copies data between them by hand.
• Per-user subscription fees keep growing as the team grows.
• You need a specific workflow: a multi-step approval, stock across several locations, a booking rule that no tool supports.
• The data matters a lot to you and you want it in your own database, under your control.

A quick decision framework

Score each question honestly. The more "yes" answers you have, the stronger the case for custom.

1. Is this process part of what makes customers choose you?
2. Have you tried at least one ready-made tool and found real gaps, not just small annoyances?
3. Does someone spend hours every week copying data between systems?
4. Will more than a handful of people use it every day?
5. Do you expect to rely on this process for years, not months?
6. Do you need the data in one place to make decisions?

Rule of thumb

Mostly "no": buy a tool. A mix: start with a tool and automate the gaps. Mostly "yes": a focused custom build is likely worth it.

How the costs compare over time

Off-the-shelf tools are cheap to start and cost you every month for as long as you use them, usually per user. As the team grows, so does the bill, and you pay for features you never touch. You also pay in time: workarounds, copy-pasting and training people around the tool's limits.

Custom software costs more upfront, because someone has to design and build it. After launch, running costs can be small, mainly hosting and occasional improvements, and they do not grow with every new person you hire. The real question is not which is cheaper on day one, but which costs less over the years you will use it, including your team's time.

The middle path most teams miss

It is rarely all or nothing. Many small teams get the best result by keeping good ready-made tools for standard jobs and adding small pieces of custom work around them: an automation that moves data between two tools, a dashboard that pulls numbers together, or a document reader that turns invoices and forms into clean data instead of manual typing. That is often where AI and automation pay off fastest.

Questions to ask before anyone writes code

Whether you buy or build, these questions save money because they force clarity before work starts. Write the answers down; any developer worth hiring will want to see them.

1. Who will use it every day, and what is each person trying to get done?
2. What is the one problem that, if solved, would make the biggest difference this month?
3. Where does the data come from today, and where does it need to go?
4. What must never happen? A double booking, a wrong bill, a lost lead?
5. Who owns the code, the hosting and the data once it is built?
6. What happens after launch: who fixes things, and how are changes requested?

What a sensible first version looks like

The most common mistake is trying to build everything at once. A good first version does one job end to end, for the people who feel the pain most. For a shop, that might be stock across two locations with low-stock alerts. For a services team, a single place where every enquiry is logged, assigned and followed up.

Your team should be clicking a working version early, on a private link, not waiting for a big reveal. Their feedback in the first weeks is worth more than any amount of planning, and it is far cheaper to change direction before the second feature than after the tenth.

Ownership matters

If you pay for custom software, the code, the database and the hosting accounts should be in your name, with a handover document. Otherwise you have not bought software, you have rented a dependency.

When I would tell you not to build custom

• You have not tried any existing tool yet.
• The process is still changing every week. Settle it first, then build.
• Nobody on your side has time to answer questions and test early versions.
• The only reason is that it would be nice to have your own app.

A good developer should be willing to say no. If a ready-made tool will do, I will point you to it. If it will not, we start with the smallest version that fixes the most painful problem, put it in front of your team, and grow it from there.