Quick verdict
| If the software is… | Do this |
|---|---|
| A standard business function such as payroll, accounting or email | Buy it. You will not out-build vendors who have spent decades on it |
| A shallow internal tool: a dashboard, an admin screen, a simple workflow | Build or extend. This is the layer where building got cheap |
| Moderately complex but not your competitive advantage | Buy and configure. The most common right answer and the least often chosen |
| The thing customers pay you for, or the process you do better than rivals | Build it. Off-the-shelf forces you to work like everyone else |
| Something you cannot yet describe precisely | Buy the closest thing and wait. Buying is reversible; building is not |
TL;DR
- 68% of fast-growing businesses regret a software purchase and 31% have replaced software because it cost too much (Gartner Digital Markets, 2024). Buying disappoints often.
- 35% of enterprise teams have already replaced at least one SaaS tool with a custom build (Retool, 2026 survey). That sounds like a case for building until you look at what was replaced.
- The replaced categories were internal admin tools, dashboards and simple workflow automations. Nobody replaced payroll, accounting or the core CRM. The line moved for shallow software only.
- AI-assisted development is why. Internal dashboards and integration glue that took a quarter now ship in days. That covers a narrow slice, not the broad decision.
- Buying is reversible and building is not. You can leave a vendor. You cannot un-own a codebase. Under genuine uncertainty, take the option you can undo.
This article covers which way to go. The arithmetic that proves it, including the break-even sum against per-seat licence fees, sits in our guide to custom software development cost.
Should I build custom software or buy off-the-shelf?
Custom software vs off the shelf comes down to one thing: buy, unless the software is shallow enough to build cheaply or deep enough to be your competitive advantage. Those are the two ends where building wins. The middle is where money gets lost.
Three plain-English terms, because quotes and vendor pitches use them loosely:
- Off-the-shelf or SaaS means software somebody else built, which you rent monthly, usually per person.
- Custom software means something built for you, which you own and maintain.
- Configure means changing settings, fields and workflows inside an off-the-shelf product without writing code. Most modern business software allows far more of this than buyers realise.
The common mistake is treating this as a question about your company. It is a question about the software.
What are the four options, not two?
Custom software vs off the shelf is really a four-way choice, and most teams only seriously consider the first and last.
| What it is | Typical cost shape | |
|---|---|---|
| 1. Buy as-is | Subscribe and adapt your process to the product | Monthly per user, rising over time |
| 2. Buy and configure | Subscribe, then use the product's own settings, fields and workflow tools to fit your process | Subscription plus setup effort |
| 3. Buy and extend | Subscribe, then build a thin custom layer on top using the product's API, the connection point that lets other software talk to it | Subscription plus a smaller build |
| 4. Build | Commission software you own | One-off build plus ongoing maintenance |
Options 2 and 3 are where most companies should land and where fewest look. Skipping from "the product does not do exactly what we want" to "we should build our own" misses two intermediate steps that cost a fraction as much.
Before commissioning anything, ask the vendor of the closest existing product two questions: what can we configure ourselves, and what can we build on top through your API. The answers are frequently more generous than the sales demo suggested.
Where has the line actually moved?
Toward building, but only for shallow software. The custom software vs off the shelf boundary moved in one direction only. This is the finding most coverage reports halfway.
Retool's 2026 build-versus-buy survey found 35% of enterprise teams have already replaced at least one SaaS tool with a custom build, with many planning more. Quoted alone, that reads as a general shift toward building.
35%: the share of enterprise teams that have replaced at least one SaaS tool with a custom build (Retool, 2026)
The detail that changes the meaning is which tools were replaced: internal admin tools, business intelligence dashboards and simple workflow automations. The shallow, generic, horizontal layer. Nobody in that data replaced their payroll system, their accounting platform or the core of their CRM.
The reason is specific rather than philosophical. AI-assisted development tools have compressed a particular kind of work. Internal dashboards and the integration code that connects systems together, which used to take a quarter, can now ship in days. That is a real change and it covers a narrow slice of software rather than the whole decision.
So the honest 2026 update is not "building is cheaper now". It is: building got much cheaper for the thin, generic layer, and barely changed for everything else. If someone tells you AI has made custom software broadly affordable, ask which layer they mean.
Which decision can you undo?
Buying. In the custom software vs off the shelf decision, only one side has an exit: not easily, not cheaply, but you can leave a vendor. You cannot un-own a codebase.
This asymmetry is missing from almost every comparison and it is the thing that should break a genuine tie.
Leaving a purchased product costs you migration work, retraining and probably some lost data fidelity. It is painful and it is finite. Companies do it regularly, which is what the 31% replacement figure describes.
Leaving custom software is a different shape. There is nothing to leave. You own it, so you own the maintenance, the security patches, the dependency updates and the eventual rebuild. The only exits are to keep paying for it, to rebuild it, or to migrate to a purchased product and write off what you spent.
Two practical rules follow.
When genuinely uncertain, buy. Buying is a decision you can revisit in eighteen months with better information. Building commits you before you have that information.
Treat "we might need it to do X later" as an argument for buying, not building. Future requirements are the most common justification for a custom build and the least reliable, because most of them never arrive. Buy the thing that solves today's problem and keep the option open.
How do custom software and off-the-shelf compare?
| Off-the-shelf | Custom software | |
|---|---|---|
| Time to working | Days to weeks | Months |
| Upfront cost | Low, usually a subscription | High, a build |
| Ongoing cost | Per user per month, typically rising annually | Maintenance at roughly 15% to 20% of build cost per year, plus hosting |
| Fits your exact process | Partly | Yes |
| Who fixes it when it breaks | The vendor | You, or whoever you pay |
| Who decides the roadmap | The vendor | You |
| Where your data sits | The vendor's infrastructure | Wherever you put it |
| Reversible | Yes, painfully | No |
| Gets better without you doing anything | Yes, vendors ship updates | No |
| Where custom is the weaker choice | Anywhere the process is standard. If your problem looks like a thousand other companies' problems, vendors have spent more on solving it than you ever will. Building your own payroll, accounting or ticketing system is the most reliable way to spend six figures reproducing something that already exists for a monthly fee |
That last cell applies to work Euracle is capable of selling. It is still the right answer for those categories.
One row deserves more attention than it usually gets. Purchased software improves while you sleep, because the vendor keeps developing it. Custom software does not. It stays exactly as good as the day you launched it until somebody pays for the next change. Over five years that gap compounds.
Choose off-the-shelf if, choose to extend if, choose custom if
Choose off-the-shelf if the function is standard, you need it working in weeks, nobody in the company will own software after launch, or you cannot yet describe the process precisely enough to write it down. This covers most business functions for most companies.
Choose buy and configure if an existing product does most of what you need and the gap is workflow, fields or reporting rather than fundamental capability. Test this properly before rejecting it, because configuration options are routinely underestimated.
Choose buy and extend if a product handles the core well but you need one specific thing it does not do, and it has an API you can build against. You get vendor updates on the engine and control over the part that matters.
Choose custom if the software is either shallow enough to build in days with modern tooling, or it is the process you compete on, or your data genuinely cannot sit on someone else's infrastructure, or nothing on the market fits and you have looked properly.
Choose to wait if the requirement is speculative. Buy the closest thing, learn what you actually need, and revisit in a year with real information.
What do buyers regret, and what do builders regret?
Both, frequently, and for opposite reasons.
Buyers regret purchases often. Gartner Digital Markets reported that 68% of fast-growing businesses regret a software purchase, and 31% have already replaced software because it cost too much (2024). Per-user pricing that looked reasonable at 20 people looks different at 200, and enterprise subscription costs have been rising.
Builders regret builds differently. The regret arrives later and is harder to act on: the maintenance nobody budgeted, the original developers leaving, the dependency that went out of support, the change that should take two days and takes two weeks.
The pattern worth noticing is that buyer regret is loud and early, builder regret is quiet and late. That biases the conversation. A company that overpaid for SaaS talks about it. A company slowly maintaining software nobody enjoys maintaining usually does not.
Neither figure is an argument for the other option. They are both arguments for making the decision on the software's depth rather than on frustration with your current tool.
What do most teams get wrong?
Calling something a differentiator when it is a preference. The test: would a customer pay more because you do this differently? If not, it is a preference and off-the-shelf will do.
Skipping options 2 and 3. Going straight from "it does not fit" to "let us build" without testing configuration or the API is the most expensive shortcut in this whole decision.
Underestimating integration. Connecting any new system to what you already run costs more than expected in both directions. It is not an argument for either option, but it should be in both estimates.
Building for requirements that have not arrived. Most speculative future needs never materialise. The ones that do usually look different from what was predicted.
Nobody owning it afterwards. Custom software with no named maintainer degrades quietly. Purchased software with no owner just gets renewed.
Deciding while annoyed. The moment a vendor raises prices or refuses a feature request is the worst moment to commit to a build. Note the frustration, then decide on depth in a calmer week.
How does Euracle run this decision?
Discovery frequently ends with a recommendation to buy, and saying so is the point of running it before quoting.
The Eureka Method, Euracle's discovery sprint, applies four steps.
Discover establishes where the software sits on the depth axis, which is the actual decision, and tests what the closest existing product can be configured or extended to do before anything is designed.
Design writes the recommendation down with the reasoning, including when that recommendation is a subscription rather than a build.
Deploy builds only the layer that needed building, which is often a thin extension rather than a whole system.
Scale reviews annually, because a decision that was right at 20 users can be wrong at 200.
The stack stays conventional where custom work happens: Next.js and TypeScript, PostgreSQL, AWS and Docker, connected to whatever is already in place such as HubSpot or Salesforce. Conventional choices are cheaper to maintain and easier to hand over, which matters more across five years than anything novel.
Two structural commitments come from how Euracle is set up. Senior practitioners only: the people in the pitch do the work, which matters most in the week where the honest answer might be "do not commission this". And one contract across six disciplines, so a finding that the right move is a subscription plus some automation does not require finding a different vendor to deliver it.
If you want the depth question answered before anyone quotes you a build, that is Euracle's web and software development service. The decision comes up constantly in real estate operations, where property and portfolio management sit exactly in the moderately-complex middle that the framework above warns about.
If what you are weighing is a phone app rather than a business system, the same logic applies with different economics, and our app development cost guide covers that version.
FAQ
Conclusion
You can now settle custom software vs off the shelf on the right variable. Place the software on the depth axis: standard business function, shallow internal tool, moderately complex but not differentiating, or the thing you compete on. Buy the first, build or extend the second, buy and configure the third, build the fourth. Test configuration and the API before rejecting any existing product, because those two middle options are the ones most often skipped and the cheapest by far. And when the answer is genuinely unclear, buy, because that is the decision you can undo. If you want the depth question answered before anyone quotes you a build, talk to Euracle about custom software development.
