Build, buy or no-code?

When off-the-shelf wins

If the problem is common, someone already sells a good answer to it, and they have spent years on edge cases you have not thought of yet. Accounting, payroll, email, calendars, a CRM, a helpdesk, online booking, e-signatures: for almost every small business these are bought, not built. Your customers will never notice which accounting package you use.

I follow the same rule myself. The booking link on this site is an off-the-shelf booking tool, because building one would have been time taken away from things people pay for.

Buying is not free of thinking, though. The trap is choosing a tool and then customising it into something it was never meant to be. Signs that is happening:

• The workarounds have workarounds.
• You pay someone more to configure the tool than you pay for the tool.
• Nobody on the team can explain how it is set up.
• People export to spreadsheets to do the job the tool was bought for.

At that point there are two honest options. Change tool, or change your process to fit the one you have. Fitting your process to good software is often cheaper than the other way round.

When no-code is enough

No-code platforms and AI app builders have made building cheap, and I think that is a good thing. For testing an idea, internal tools used by a handful of staff, and simple workflows such as forms, approvals, notifications or a basic customer portal, they are often all you need.

They start to strain in predictable places:

• Permissions: who can see which customer's data, once there are many customers.
• Volume: pages and reports slow down as the data grows.
• Integrations: the platform does not connect to a system you depend on.
• Scrutiny: a bigger customer sends a security questionnaire the platform cannot answer.
• Pricing: per-user or per-record pricing that climbs faster than your revenue.

If you have already built something this way and real users are coming, start with what I check in a vibe-coded app before launch.

None of these is a reason not to start with no-code. They are the signals to watch for.

Keep the option of moving off later from day one. Keep your data somewhere you can export it in full. Write your business rules down outside the tool, so they can be rebuilt elsewhere. Know roughly what leaving would take before you need to.

When custom software earns its cost

Custom software earns its cost in two situations. Either it is the thing customers pay you for, or it removes a cost so large that nothing on the market does the job.

"Earns its cost" is arithmetic, not a feeling. Add up what it costs to build and what it costs to run over three years: hosting, monitoring, updates, and the time of whoever looks after it. Set that against what it brings in or saves over the same three years. If the case only works in the best case, it does not work.

Being strict about this is part of how custom work paid where I was CTO. Bespoke projects at that cybersecurity SaaS company ran at an 80% profit margin, and every technology project we delivered paid for itself in under two years. That only happens when you are strict about what gets built and what gets bought.

The best pattern is usually to build the smallest custom part and buy the rest. Sign-in, payments, sending email, hosting and analytics are solved problems with good services behind them. Your own code should be the part that makes you different. If your product has its own payment system, ask why.

Mistakes in both directions

Building what could have been bought. Building is more interesting than buying, especially for technical teams. The result is months spent on a weaker version of something available for a monthly fee, which you then have to maintain for as long as you run it. To spot it early, ask one question: would a customer notice if we bought this instead? If the answer is no, buy it.

Buying, then bending a tool until it costs more than building. It starts with one plugin, then an integration, then a few scripts to fill the gaps. Each step is cheap. Together they become fragile and expensive, and nobody dares change anything. To spot it early, count the hours spent each month working around the tool, and watch how long simple changes take.

Both mistakes come from deciding once and never checking. Revisit the decision whenever your scale, your team or your customers change. The right answer for ten customers is often the wrong one for five hundred.

The hidden costs of each

Hosting and licence costs drift quietly, so check them every year, not only when you sign up. When I rebuilt a legacy licensed platform as a cloud-native SaaS on AWS, infrastructure costs fell by 96%.

A simple way to compare: for each option, write down three years of costs. Include setup, monthly fees, hosting, the time your team spends looking after it, and what it would cost to leave. Put the three columns side by side. The cheapest option to start is often not the cheapest to own.