Buy or build? A simple test for custom software

I build custom software for a living, so you might expect me to recommend it every time. I don’t. On a fair share of first calls, the most useful thing I can say is “you don’t need me for this, here’s the tool that already does it”. That call costs the client nothing and saves them a lot.

The question I ask to get there is simple.

The 80/20 question

Is there an off-the-shelf product that does 80 percent of what you need, and can you genuinely live without the other 20 percent?

If the answer is yes, buy it. A good SaaS product has had thousands of users finding its bugs before you. It has someone on call when it breaks. It gets better every month without you paying for a project. Even if the monthly fee feels steep, it’s almost always cheaper than building and maintaining your own version.

The trick is being honest about the second half. A physio clinic I spoke to wanted a custom booking system because none of the existing ones let them colour-code appointments by practitioner and room at the same time. That was the 20 percent. When we talked it through, the colour coding was a nice-to-have from one person’s wishlist. They bought an existing product and were live in a week.

When custom is clearly right

There are two situations where I’ll recommend building without much hesitation.

The first is when the missing 20 percent is how you make money. If your process is the thing that sets you apart, squeezing it into someone else’s software means working like everyone else. A freight broker I worked with had a pricing method that took into account return loads and driver hours in a way no off-the-shelf tool supported. That method was their margin. Building around it paid for itself in about five months.

The second is when the gap is between tools rather than inside one. You’ve bought good products for each job, but someone spends ten hours a week copying data between them. Often the answer here isn’t a whole new system. It’s a small integration that joins the tools you already have. That’s some of the best value custom work there is.

Either way, remember that building is the cheap part. A custom system needs hosting, updates, security patches and someone who understands it when it breaks in three years. I price that in from the first quote, and if a client can’t see it being worth the ongoing cost, that’s a strong sign they should buy.

What it looked like for OnCloudWine

OnCloudWine started as a build-versus-buy question. A small winery wanted to run a wine club: members, quarterly shipments, payment on a schedule, and the ability to swap bottles before each release. I looked hard at the existing options. Generic subscription tools handled the billing but had no idea what a shipment allocation was. The wine-specific platforms existed, but they were built for much bigger wineries and priced to match.

Neither got to 80 percent for a small cellar door. So I built it, and then other wineries asked for the same thing, and it became a product. That’s the happy version of the story. Most custom builds stay custom, and that’s fine too.

A quick checklist

• List what you need. Mark each item as must-have or nice-to-have, and be ruthless.
• Try two or three existing products against the must-haves only.
• If one covers them, buy it and revisit in a year.
• If none do, ask whether the gap is your competitive edge, or the space between tools you already use.
• If it’s neither, you probably need to change the process, not the software.

If you’re weighing it up, tell me what you’re trying to do. I’ll give you a straight answer, even if that answer is someone else’s product.