Build vs buy: when custom software is (and isn't) worth it

Buy software for anything that is not a source of competitive advantage, and build custom software only where off-the-shelf tools force you to change how your business actually works. A spreadsheet, a no-code tool or a SaaS product is the right answer more often than software people admit. Custom software earns its cost when the process is your edge, when existing tools cannot fit it, or when the total cost of renting and working around them passes the cost of owning a better fit.

Key takeaways

• The default answer should be “buy”, and custom software has to justify itself against a specific, named alternative rather than against an abstract idea of “what we could build”.
• Compare options on total cost of ownership over three years, not on the build price or the monthly licence, because maintenance, integration and workarounds often outweigh both.
• Build when the process is a differentiator, when the fit is poor, when data ownership or integration matters, or when licence costs scale badly with your growth.
• A hybrid approach is often best: buy the commodity core, build the thin layer unique to you, and connect them through APIs.
• Signs you have outgrown off-the-shelf tools include manual copy-paste between systems, staff building workarounds, and pricing that rises faster than your revenue.
• If you do build, start with the smallest version that proves the value, ship it in weeks, and keep the option of replacing it or the tool it supports.

What is the short answer to build vs buy?

Buy first. Build only when you can explain, in one paragraph, what a bought tool cannot do and what that costs you each month. If you cannot write that paragraph, you do not have a case for custom software yet.

The reasoning is simple. A bought product is used by many companies, so its development cost is shared and other people find its bugs. Custom software is paid for and maintained by you for as long as you use it. The code is an asset, but also a liability: someone must update dependencies, fix security issues and understand it when its author has left.

That does not make custom software a bad idea. It makes it a deliberate one. For some companies the software is the business: a marketplace, a booking engine, a pricing system, a logistics workflow nobody else runs. Renting your core to a vendor who could change the price or the product is a strategic risk.

How do you decide? A decision matrix

Score each option against the same criteria and look at where they diverge. The table shows what to look for under each.

Criterion	Points towards buying	Points towards building
Differentiation	The process is the same as competitors’; it is a back-office or commodity function	The process is part of why customers choose you
Fit	A tool covers around 80 to 90 per cent of needs with configuration	You would change your process to fit the tool, or stack workarounds on top
Total cost of ownership (3 years)	Licences plus setup are lower than build plus run	Licences scale with users or volume and exceed the cost of owning
Integration	The tool has good APIs and connectors for your systems	You must glue five systems together and none talks to the others
Data ownership	You can export everything in a usable format	Data is locked in, or its structure matters to your product
Vendor risk	Established vendor, clear roadmap, easy exit	Small vendor, unstable pricing, you depend on one feature
Time to value	You need it this month	You can wait weeks for a better fit

Use it as a conversation tool, not a calculator. Two or three criteria usually dominate. If differentiation and fit both favour building, build. If only time to value favours buying and everything else says build, consider buying now and building later.

Differentiation

Ask: “If a competitor had exactly this tool, would they get closer to winning customers from us?” If not, it is a commodity function such as payroll, accounting, email or a help desk. Buy it.

Fit

Fit is the gap between how the tool works and how you work. You can close it by configuring the tool, changing your process, or building around it. Changing your process to match a good tool is often the cheapest move.

Total cost of ownership over three years

Total cost of ownership (TCO) is everything you pay over the life of the thing: licences or build cost, setup, integration, hosting, maintenance, staff time, training and workarounds. Three years is long enough to include maintenance and short enough to be realistic. The worked example below shows how it plays out.

Integration, data and vendor risk

A tool that cannot talk to your accounting, CRM or data warehouse costs you a person doing copy-paste, so check for real APIs and webhooks. Check that you can export all your data in a usable format. Vendors change pricing, get acquired and drop features, so read the exit terms before you depend on the product. Time to value matters too: a bought product can work this week, and that is why a spreadsheet often beats everything else at the start.

When is a spreadsheet, a no-code tool or SaaS the right answer?

A spreadsheet, a no-code tool or a SaaS product is the right answer when your process is simple, changing, or not yet understood. We say this openly because it is true, and because building an app when a spreadsheet would do is something we turn down.

A spreadsheet is enough when a handful of people in one team use it, the process still changes every few weeks, and errors are cheap and visible.

A no-code or low-code tool (Airtable, Notion, Retool and similar) fits when:

• You need forms, simple workflows or an internal dashboard on top of existing data.
• The users are internal, the volume is modest, and you accept the platform’s pricing and limits.

Off-the-shelf SaaS is the right answer when:

• The function is a commodity (accounting, HR, CRM, ticketing, scheduling, billing).
• A mature vendor covers most of what you need.
• Your team would rather configure than maintain software.
• You need it working this month.

There is nothing wrong with starting this way. Much good custom software began as a spreadsheet someone outgrew, and the months of use taught the team the real requirements. If a bought tool fits, we would rather tell you so than sell you a build.

What about a hybrid approach?

A hybrid approach means buying the commodity core, building only the part that is unique to you, and connecting both through APIs. It is often the best answer because it gives you the speed and low maintenance of a product with the fit of custom work where it counts.

A pattern that works:

1. Buy the system of record for the boring parts: accounting, CRM, payments (for example Stripe for subscription billing), identity, email.
2. Build the edge: the pricing logic, the customer portal, the workflow, the matching algorithm, the dashboard your operations team needs. This is what customers or staff actually experience.
3. Integrate with APIs and webhooks so data flows between the two without manual steps.
4. Keep the seam clean. Put the integration behind an interface in your code, so that replacing the bought tool later does not mean rewriting the edge.

Imagine a small training company. It buys a CRM for contacts and invoices, and Stripe for payments. It builds only the booking and scheduling tool that matches how its trainers and venues work. That is a small application: lower cost, faster delivery, less to maintain. It is the logic behind our web app and SaaS development work: build the part that is yours, and do not rebuild what the market already sells.

AI features follow the same rule: a hosted model such as Claude or a GPT model through an API, with your own retrieval and evaluation around it, usually beats training anything from scratch. See AI in your business.

What does a worked cost comparison look like?

The example below uses invented numbers to show the structure of the calculation, not real prices. Replace every figure with your own quotes before drawing a conclusion.

Imagine a company of 40 people that runs a field-service business. It needs a tool for scheduling visits, sending quotes and tracking jobs. It has three options over a three-year horizon.

Assumptions (all hypothetical):

• Buy SaaS: 25 users at €60 per user per month, a one-off setup of €6,000, and about four hours a month of internal admin time valued at €50 per hour. The tool fits most of the process, but staff spend time on workarounds worth about €2,000 a month.
• Build custom: €90,000 to build, €400 a month for hosting and monitoring, and yearly maintenance and changes at 15 per cent of the build cost, which is €13,500 a year. Workarounds disappear because the tool matches the process.
• Hybrid: the same SaaS licences, setup and admin time, plus a small custom layer that handles the unusual quoting rules. It costs €25,000 to build, €300 a month to host, and 15 per cent a year for maintenance, which is €3,750 a year. Workarounds shrink to €500 a month.

Cost over 36 months	Buy SaaS	Build custom	Hybrid
Licences (25 users × €60 × 36)	€54,000	€0	€54,000
Setup	€6,000	€0	€6,000
Internal admin time (4 h × €50 × 36)	€7,200	€0	€7,200
Build	€0	€90,000	€25,000
Hosting (€400 or €300 × 36)	€0	€14,400	€10,800
Maintenance (3 years)	€0	€40,500	€11,250
Workarounds (staff time, 36 months)	€72,000	€0	€18,000
Total	€139,200	€144,900	€132,250

What this example shows, and what it does not:

• The three totals are close. That is the point: the headline price (a €90,000 build against a €1,500 monthly licence) misleads in both directions.
• The workaround line decides the result. If staff time lost to the SaaS is only €500 a month rather than €2,000, buying wins easily. If it is €4,000, building wins.
• The hybrid wins here only because the custom layer is small and the licence is cheap. A different assumption could flip it.
• Not in the table: licence price rises, user growth, vendor risk, the value of owning your data, or a build that overruns. Add them if they matter to you.
• A custom build only beats the others if it also creates value the table does not capture, such as faster quotes that win more jobs. That is a differentiation argument and should be stated separately.

For help turning a build option into a realistic number, our guides on the cost of an MVP and custom software development cost explain how cost is built from team size and weeks.

What are the signs you have outgrown off-the-shelf tools?

You have outgrown a tool when the effort of working around it exceeds the effort of replacing it. These signs repeat across companies.

• Copy-paste between systems. Someone moves data by hand every day or week.
• Spreadsheets next to the tool. The real process lives in a shadow spreadsheet because the tool cannot hold it.
• Customers see the limits. You turn down requests because the tool cannot do them.
• Licence costs rise faster than revenue. Per-seat or per-record pricing punishes your growth.
• Workarounds have owners. One person knows how the process really works, and if they leave, it stops.

One or two signs is normal. If most apply and the monthly cost of the workarounds is visible, it is time to price the alternative. Do not leave the old tool until the new one is proven.

How do you start small if you decide to build?

Start with the narrowest version that proves the value, and build it on top of the tools you already have. A custom build does not have to replace everything. It can replace the most painful 20 per cent.

1. Write the problem and the metric. One paragraph on what hurts, and the one number that should change, such as hours per week or error rate.
2. Map the current process with the people who do the work, noting every workaround.
3. Pick the smallest slice. One flow that is painful, frequent and well understood. Leave the rest on the existing tool.
4. Prototype before you build. A clickable prototype, or a no-code version, tests the idea cheaply.
5. Integrate, do not migrate. Connect the new piece to existing systems through APIs.
6. Ship in weeks and measure. Put the first version in front of real users and check the metric.
7. Own it and budget to run it. Own the repository and cloud accounts from the start, and budget for hosting, monitoring and maintenance from the first month.

This is how an MVP is meant to work: a small, measured first version that either proves the idea or stops you wasting more money.

How Hidook approaches this

Hidook is a remote-first product engineering studio that designs, builds and runs custom web applications, SaaS platforms, MVPs, AI systems and cloud infrastructure. We also say no to building an app when a spreadsheet or an off-the-shelf tool would do, and we will tell you so in the first conversation.

When custom software is justified, we begin with discovery to write down constraints and the one metric that matters. You leave with a written scope and a price. The build runs with a demo and a deploy to a live URL every Wednesday, and the client owns the repository and cloud accounts from day one. We often combine bought tools with a small custom layer, which is the hybrid approach above. You can see how we work on our about page.

Frequently asked questions

Is custom software always more expensive than SaaS?

Not always, but it usually costs more upfront and carries ongoing maintenance. Over several years, per-user licences can add up, especially as you grow. Compare total cost of ownership over three years, including workarounds, rather than only the build price or the monthly fee.

When is no-code a better choice than custom code?

When the users are internal, volumes are modest and the process is still changing. It becomes limiting when you need complex logic, performance, custom integrations or control over the data model.

Can I start with SaaS and build later?

Yes, and it is often the sensible order. Choose a tool with good export and API options, keep your data clean, and put an integration layer between the tool and your own code. That makes a later switch a smaller project.

How do I stop custom software from becoming a maintenance burden?

Keep the scope narrow, write tests for the important flows, keep documentation current, and budget for maintenance from the start. A common planning rule is to expect yearly upkeep to be a meaningful fraction of the original build cost. Own the repository and accounts so any capable team can take it on.

Should an early-stage startup buy or build?

Buy everything that is not the product. Build the product itself, because that is what you are selling. Use a hosted service for authentication, payments and email, and write custom code for the thing customers pay for. Our SaaS stack guide goes into the choices.

If you are weighing a build against a bought tool and want a straight opinion, write to [email protected] or book a call at https://hidook.tech/contact/.