Build or buy? A simple test before you pay for software
Should you buy standard software or have something built? Our answer is usually "buy first, build the gap". Here is a four-question test to find where that gap is, and what it costs you.
Sooner or later every growing company hits the same question. The spreadsheet isn't enough any more, and someone has to decide: do we buy a standard system, or have something built for us?
The software vendor says buy. The developer says build. Both have a reason to say so. Here is a simple way to decide for yourself.
Our default: buy first, build the gap
For standard work, use standard tools. Accounting, payroll, email, calendars, file storage. Thousands of companies do these things the same way, and the products for them are cheap and well tested. Building your own would be slow, expensive and worse.
But almost every company has one or two processes that are its own. How you find customers, how you quote, how you follow up, how you keep members or clients engaged. That is usually where standard tools start to rub.
So the question is rarely "build or buy". It's "what do we buy, and where is the gap that nothing on the shelf fills?"
The test: four questions
1. Is this process the same in most companies? If yes, buy. Don't pay to reinvent invoicing.
2. Is it how you win or keep customers? If yes, be careful about bending it to fit a tool. This is where your way of working is the point, and where a custom tool can pay for itself.
3. Are people working around the tool? Look for the workarounds: an Excel file next to the system, copy-paste between two programs, notes in personal notebooks, "ask Anna, she knows". Every workaround marks a gap.
4. What does the workaround cost? Count it roughly. Hours per week, times the number of people, times their hourly cost. Two people spending three hours a week is about 300 hours a year. Add the mistakes and the customers who slip through. That number is the budget for fixing it, and it tells you whether a fix is worth it at all.
What "build the gap" looks like in practice
You keep the standard system. It stays the place where the data lives. Then you add a small tool that does the one job the system does badly, connected to it so nobody types anything twice.
Citydäck, a tyre retailer in the Öresund region, is a good example. Their business system already held the customers and the measured tread depth on every stored tyre. They kept it. What was missing was a way for the sales team to work through the customers who needed new tyres, without calling some twice and others not at all.
So we built a sales board on top of their system. It pulls the customers who need new tyres, gives each one an owner, keeps notes on every call, and shows orders straight from the business system. Five to six salespeople use it every day. You can read more in our Citydäck case study.
No new business system. Just the missing piece.
Signs you're about to build too much
- You're rebuilding something you could buy for a monthly fee.
- The plan has forty features before anyone has used version one.
- The new system replaces tools that work fine today.
Signs you bought the wrong thing
- You pay for modules nobody opens.
- The team keeps a spreadsheet next to the system "just to be sure".
- You changed how you work to fit the tool, and your customers noticed.
Try this this week
Write down the tools your team uses. Next to each one, write one line: what do people do outside this tool to get the job done?
The longest line is your gap. Start there.
We write about practical software for small and medium-sized businesses: what to automate, when to build, and how to get it right the first time. Follow ScideTech on LinkedIn to get the next post.
