Build vs buy software: when a custom tool beats SaaS

The short answer to build vs buy software: buy SaaS for common problems, and build a small custom tool when the process is specific to how you work and your team spends hours every week patching the gaps by hand. Most small businesses end up in between: they keep the subscriptions that work and build one small tool that connects them. I build custom tools for a living, and my default is still to buy. This guide shows where that default stops being right, what each option costs over three years (upkeep included), and a scorecard you can fill in for your own case.

Build, buy, or buy then extend

"Build vs buy" sounds like two options. For a small business there are three.

Buy means off-the-shelf software, usually a monthly SaaS subscription: a booking app, an invoicing service, a CRM. Someone else writes it, hosts it, fixes it and decides what it does next.

Build means a tool made for your process. For a small business this is rarely a big platform. It is usually an internal tool: one dashboard, one form, one script that does a job your team now does by hand. Custom software vs SaaS comes down to who adapts to whom: with SaaS you adapt to the product, with a custom tool the product adapts to you.

Buy then extend (the hybrid) means you keep the SaaS products that do their job well and build a small piece that connects them or fills the one gap they leave.

When buying SaaS is the right call

Buy when the problem is common. Email, accounting, payroll, video calls, file storage, scheduling: thousands of businesses need the same thing, so the market has solved it well and cheaply. Building your own version of a solved problem is a hobby, not a business decision.

Buy also when the work is regulated or risky to get wrong (tax, payroll, payments), when you need it this week, when nobody can own a tool after it is built, or when the process is still changing. Do not freeze a process into code before you know how you will work in six months. And if a tool fits 90% of your process, it is a good deal.

When building a custom tool wins

Build when the problem is yours. Once a process is specific to how you work, SaaS starts to chafe. The common signs:

• Someone copies data from one tool into another by hand, every day or every week.
• A spreadsheet sits next to the SaaS because the SaaS cannot show what you need.
• You pay per seat for software you use a small fraction of.
• The workaround lives in one person's head, and things break when that person is away.

If you pay per seat for software you use a fraction of and duct-tape the rest by hand, a small custom tool often pays for itself. Often, not always: run the numbers below first.

The third option: keep your SaaS, build the glue

This is the option I recommend most, and the one most build vs buy articles skip. You rarely need to replace a SaaS product to fix the pain around it. The subscription is usually fine; the problem is the manual work between it and everything else.

Typical hybrid builds: a script that copies new orders or payments from one system into another so nobody retypes them, a small dashboard that combines two or three tools into the one view the owner checks every morning, or a scheduled check that flags mismatches (an unpaid booking, a missing invoice) before a customer notices.

The vendor stays responsible for the hard, generic parts, and you own a small tool for the specific part. It costs less to build and maintain than a full replacement. The trade-off: it depends on the vendors' APIs and export formats, so when one of them changes, the glue needs a fix.

The real cost math over 3 years

A monthly subscription and a one-time build quote are not comparable until you put both on the same timeline. Three years is a fair horizon for a small business tool.

What SaaS really costs

Start with seats x monthly price x 36. Then add what the invoice does not show: price increases over three years, the plan upgrade you need for one feature, and the glue work, meaning the hours your team spends exporting, copying and reconciling. Glue work is the line people leave out, and it usually decides the answer. It is also what drives SaaS sprawl: each new subscription solves one problem and adds another gap, until a small team pays for many tools that do not talk to each other.

What a custom tool really costs

The build fee is the visible part. Over three years you also pay for hosting (small for an internal tool, but not zero), upkeep (updates, fixes, small changes), and your own time to explain, test and check the result.

To sanity-check the build side, I use the website cost calculator. Choose "Custom web app" as the site type and "Freelancer" as who builds it, then tick "Maintenance (monthly)" and "Hosting and domain (yearly)". It shows the one-time build range and, separately, the yearly running costs. These are market ranges from published price guides, not a quote, and the "Custom web app" band is sized for a full application. A single-purpose internal tool or a hybrid connector usually lands below it, so treat the build range as an upper bound and the yearly lines as proof that upkeep is a real number.

A worked example (hypothetical numbers)

Say a small service business has five people on a scheduling and invoicing SaaS at $30 per seat per month. The team spends about 3 hours a week copying bookings into a spreadsheet and matching payments, at an internal cost of $20 an hour. Every number here is invented to show the method; replace them with yours.

Subscriptions are 5 x $30 x 12 for two years plus a 10% rise in year three. Glue work is 3 hours x $20 x 48 weeks x 3 years.

Three things stand out. First, the build only wins because of the glue work; the subscriptions alone are cheaper than any build. Second, one input flips the answer: at 1 hour of glue work a week, keeping the SaaS costs $8,460 and becomes the cheapest option. Third, the hybrid wins here because it removes the expensive part (manual work) without rebuilding what the vendor already does well.

So measure the glue work before you decide. For one or two normal weeks, have the people doing it note the minutes they spend moving data between tools. Estimates from memory are usually off.

Upkeep: what "near-zero running cost" really means

An earlier version of this article said a custom tool has near-zero running cost. That was too generous, and it is the claim build vs buy decisions most often get wrong. The hosting bill for a small tool can be tiny. The upkeep is not zero:

• Dependencies and security. Frameworks, libraries and the server need updates. Skipping them works until the day it does not.
• Things it connects to. A change in a SaaS API, a payment notification or a spreadsheet layout can break your tool without warning.
• Your process. You will want changes as the business moves.
• Backups and monitoring. Someone should know when it stops working, ideally before a customer does.
• The bus factor. If only one person understands the tool and that person disappears, you have a problem. Documentation and access to the code are part of the cost.

Budget upkeep as a recurring line from the start, either a few hours a month or a share of the build cost per year, and decide who does it before the build begins. A well-scoped tool needs little attention most months, then a burst of work when something it depends on changes. Plan for both.

Ownership and your data

With SaaS, you own your data but not the tool. Check how you get the data out before you depend on it: is there a full export or an API, does it include history and attachments, and what happens to your account after you cancel? A product that makes leaving hard has a cost, even if it never shows on an invoice.

With a custom tool, ownership depends on the agreement, not on the fact that you paid. Make sure the source code sits in a repository you control, the server, domain and third-party accounts are in your name, you have a short note on how it is deployed and where the data lives, and the contract says the code is yours once paid. I cover the same question for websites in hand-coded websites vs page builders.

Build vs buy decision matrix

Turn the decision into a scorecard instead of a gut feeling. Score each criterion from 1 to 5 (5 strongly favours building), multiply by the weight, and add it up. Adjust the weights to what matters to you.

The maximum is 80. As a rough guide: under 40, buy and accept the gaps. From 40 to 60, look hard at the hybrid. Above 60, a small custom build deserves a serious quote. One override: if "Someone can own upkeep" scores 1, buy anyway. A tool nobody maintains becomes the next problem.

How AI changed the build side

AI coding assistants have made small builds faster and cheaper across the industry: a focused internal tool or a connector between two systems now takes much less time than it used to. That pushes some decisions toward building, especially the hybrid kind.

AI does not change the upkeep. Code written faster still needs updates, still breaks when an API changes, and still needs someone who understands it. It also makes it easy to generate a lot of code nobody reviewed, which raises the maintenance bill later. For narrow jobs, AI makes a custom tool realistic where it was not before. For commodity software, the vendor's value was never just the code; it is hosting, security, compliance and support, and that is still worth paying for.

Real examples from my own work

My own business, Tangkap Rasa, is a camera rental in Jogja, and it runs on a mix of bought and built tools. Three builds came from exactly the friction described above.

An operations dashboard instead of a spreadsheet. Bookings, deliveries and payments used to live in a Google Sheets based dashboard. It was fine at low volume, then became slow and fragile as data piled up. I replaced it with a custom operations dashboard on a proper database. The trigger was not a feature list; the daily view had become something I waited for and worked around.

An automatic payment check. Matching incoming transfers to the right booking was a manual chore. Now a check matches transfers to bookings automatically, so the manual work is reviewing exceptions instead of every transfer. That is the hybrid pattern: the bank and the booking system stay as they are, and a small tool connects them.

My own SEO tools. I write my own crawlers and a self-hosted Search Console and Analytics console instead of paying for some subscriptions, because the reports I need are specific to how I work. That is easy for me because building is my job; for most businesses it would be the wrong call.

What I do not build: anything a solid vendor already does well, especially where mistakes carry legal or financial risk. I would not rebuild email or accounting.

How to start small

If the scorecard points toward building, keep the first step small:

1. Pick one bottleneck: the single task with the most glue work.
2. Describe the tool as one screen or one script, with its input and output.
3. Run it next to the existing SaaS for a two-week pilot.
4. Keep the data exportable in a format you can read without the tool.
5. Agree on upkeep and ownership in writing before the build starts.

If the pilot does not save measurable time, stop. That is a cheap lesson compared to a big project that never pays back.

Frequently asked questions

Is it cheaper to build or buy software?

For common problems, buying is almost always cheaper. Building becomes cheaper when the manual glue work around your current tools costs more over three years than a small tool plus its hosting and upkeep. Put both on a 3-year timeline before you compare.

When should a small business build custom software instead of using SaaS?

When the process is specific to how you work, the team spends hours every week moving data by hand, and someone can own the tool after it is built. If any of those is missing, buy, or try the hybrid first.

What is a build vs buy decision framework?

A structured way to compare options on the same criteria instead of by feel: fit, total cost over several years, upkeep, risk and ownership. The scorecard above is a simple version you can fill in for one decision in a few minutes.

Who owns custom software after it is built?

Whoever the agreement says owns it. Make sure the contract states the code is yours once paid, that the repository, server and domain are in your name, and that you get a basic note on how it is deployed.

How much does a small custom internal tool cost?

Scope decides it. A single connector or a one-screen dashboard costs far less than a full custom web app, and published ranges for full apps are a reasonable upper bound. Add hosting and upkeep every year on top of the build.

Can AI really replace SaaS for a small business?

For narrow, specific jobs, AI makes a small custom tool cheaper to build than it used to be. It does not remove upkeep, and it does not replace what commodity vendors really sell: hosting, security, compliance and support.

What is SaaS sprawl?

It is what happens when a business adds subscriptions one problem at a time until it pays for many tools that overlap and do not share data. The visible cost is the subscriptions; the hidden cost is the manual work between them.

What happens if the developer who built my tool disappears?

If you hold the code, the accounts and a short deployment note, another developer can pick it up. If you do not, you may have to rebuild. Settle ownership and documentation before the build starts.

Wondering if your process is a build candidate, or whether a small connector would do? Here is how I approach custom tools, or get in touch and tell me which task eats the most hours.