When to build custom software and when to buy

Buy software when your need is common and a product already does 80 to 90 percent of it well. Build custom software when the system is part of how you compete, when your process does not fit any product, or when the cost of bending your business to a tool is higher than the cost of building. Most businesses should buy most of their software and build only a few things.

We build custom web apps, and we also buy and self-host plenty of off-the-shelf tools for our own use. That is why we will tell you not to build things that you can simply buy.

What is the real question behind build versus buy?

It is not “which is cheaper?” It is “where does this system sit in how we make money?”

• Commodity functions are things every business does the same way: accounting, payroll, email, file storage, calendars. Buy these. Nobody wins customers with a custom email system.
• Differentiating functions are the way you do what you do better than others: how you quote, schedule, book, track or serve. Custom software can be worth it here, because it encodes your advantage.
• In between is the large grey area, and where most of the thinking belongs.

If a competitor can buy the same product tomorrow, it gives you no edge. That is fine for commodity tools, and a warning sign for anything you hoped would set you apart.

When should you buy?

Buy when most of these are true:

1. A product exists that covers the core need.
2. Your process is close to the industry norm.
3. You need it working soon.
4. The vendor looks stable, and your data can be exported.
5. The monthly cost is small next to what a build would cost.
6. You do not want to maintain software.

Buying also hands you the vendor’s R&D, security updates and support. A custom system gets none of those unless you pay for them.

When should you build?

Build when several of these are true:

1. Your process is the product. Off-the-shelf tools force you to change how you work, and that change costs you.
2. You are gluing together many tools. If staff copy data between five systems every day, a single purpose-built app may pay back fast.
3. You need a specific integration that no product offers.
4. Per-user pricing hurts. A tool that charges per seat can become costly at scale, while a custom app costs you the same for ten users or a hundred.
5. You need control over data location, branding or behaviour. White-label products are a good example: you want your brand and your customers on your terms.
6. You can name an owner who will decide what the software should do, and keep deciding.

Number 6 is the one people skip. Software without an owner turns into a project that never ends.

What does custom software really cost?

Costs vary widely by country and by team, so these are rough guides in USD.

• A simple internal tool, such as a form flow with a database and a few reports, often lands in the low thousands to the low tens of thousands.
• A multi-role business app with integrations typically runs from tens of thousands upwards.
• Running it afterwards usually costs roughly 15 to 25 percent of the build cost each year, for hosting, fixes, security updates and small changes.

The build is the smaller part of the cost over five years. If a vendor shows you only the build price, ask about the run price.

Is there a middle path?

Yes, and it is often the best one.

• Configure a product that has strong customisation, such as a low-code platform or an open-source system you can adapt.
• Buy the core, build the edges. Keep the accounting system you bought, and build a small app that feeds it clean data.
• Start with a thin first version. Build the one workflow that hurts most, in a few weeks, and learn from real use before you commit to more.
• Use open-source components inside a custom app, so you build only the part that is unique.

A useful rule is to build the smallest thing that removes the biggest pain, then stop and see.

What are the risks of each choice?

Risk	Buy	Build
Fit	Process bends to the tool	Fit is exact, if the brief was right
Cost over time	Rising fees, per-seat growth	Upfront cost plus ongoing upkeep
Speed	Fast to start	Slower to start
Lock-in	Vendor controls pricing and features	You depend on whoever knows the code
Security	Vendor handles patches	You must patch and monitor
Exit	Export may be poor	You own the code and data, if the contract says so

The build-side lock-in risk is real. Insist on owning the source code, getting documentation and hosting it somewhere you control. A good partner will agree to that.

How do you decide in an afternoon?

Run through five questions with the people who use the system:

1. Does a product already cover most of what we need?
2. Is this a commodity function, or part of how we win?
3. How many staff work around the current tool, and for how many hours a week?
4. Who will own the software after launch?
5. What is the cost over five years, build plus run, against the cost of buying plus the workarounds?

If the answers point to buying, buy, and spend the saved effort on getting the rollout right. If they point to building, write down the one workflow that matters most and start there.

How do we approach this ourselves?

We run our own booking, file sharing and mail on our own servers. Some of it we built because nothing fitted. Most of it we adopted from open-source projects and configured, because building it again would have been waste. We try to give clients the same honest answer.

Short answer

Is custom software always more expensive than buying? Not always, but it usually costs more up front. Over several years, per-seat fees and workarounds can make a custom build cheaper, particularly for a process that is central to your business.

What should I never build myself? Commodity tools like email, accounting, payroll and general file storage. Buy or self-host a proven product instead.

How do I avoid being locked in to a developer? Own the source code, ask for documentation, host the system where you control access, and use common, well-supported technology.

Want this set up for your business? Ask for a quote.