Blog
Build vs buy: when custom software actually wins.
Buy for common needs, build for the workflow you compete on. The trade-offs, the hidden costs on both sides, and four questions that settle the choice.
Custom software wins when a workflow is central to how your business competes and no packaged product fits it without changing how you work. For everything else, buying is usually faster and cheaper. That one distinction, core workflow against common need, settles most build-or-buy debates before the spreadsheet comes out.
This guide covers the real trade-offs, the places where off-the-shelf tools quietly add work, how a custom build fits an unusual process, the long-run cost comparison, and a four-question framework you can use with your team this week.
What are the real trade-offs?
The trade is control and fit against speed and cost. In the Standish Group's 2020 CHAOS data, only 31% of software projects succeeded on time, on budget and with full scope; 50% were challenged and 19% failed (the report itself is paid; these figures are as summarised by OpenCommons). Buying removes most of that delivery risk. Building accepts it in exchange for software shaped around your operation.
Buying gives you a working product in days, predictable pricing and a vendor who maintains it. The cost is fit: you adopt someone else's assumptions about how your work should flow.
Building gives you exact fit and control over what changes next. The cost is time, budget and a real chance that the project stalls. The honest version of this decision weighs those costs against how much the fit actually matters.
There is a quieter trade-off too. Buying keeps you aligned with how a vendor thinks your market should work. That is an advantage when you want standard practice, and a liability when your edge comes from doing something differently.
When do off-the-shelf tools create more work?
When you spend effort adapting the business to the software instead of the other way round. The signs are familiar: the same data typed twice, spreadsheets bridging the gaps between apps, and staff running manual steps the product never anticipated.
The sprawl adds up. Zylo, which sells SaaS management software, reports that its average customer held 275 SaaS applications in 2024, that 53% of licences went unused in a typical 30-day period, and that this came to about $21 million of wasted spend a year (Zylo, 2025 SaaS Management Index). Those are large organisations, so the dollar figure will not match yours, but the pattern scales down: every tool bought to patch a gap is another login, another integration and another renewal.
A hotel running three separate products for reservations, housekeeping and billing is a common example. Each tool works alone. Together they make staff re-key the same guest in three places. The licence cost looks small; the labour cost of the workarounds does not.
When a packaged tool covers most of a need and the missing part is exactly where you compete, the gap is not a minor inconvenience. It is the reason the tool fails to help, and the point where buying starts to cost more than it saves.
How does custom software fit an unusual workflow?
It is built around the process you already run, not a generic version of it. Instead of mapping your operation onto a product's menus, the product mirrors your operation. That matters most where the workflow itself is the differentiator.
The payoff shows up as friction removed rather than a longer feature list. When the booking screen shows the fields your front desk actually uses, and billing flows straight from the booking with no spreadsheet in between, the daily tax of workarounds disappears. A system built for your process can also take on new rules as the business changes, instead of waiting for a vendor to prioritise the feature you need now.
We sit on both sides of this choice, so it is worth saying what we do. We run eight ready-made systems, including PMSNow for hotels, EMSNow for schools, HMSNow for clinics, TOSNow for tour operators and ERPNow for orders, stock and the ledger. If one of them covers most of your process, we say so. If it does not, custom work is quoted per project, in writing, before anything starts.
How do you compare the long-term cost?
Compare the full cost of ownership on both sides, not the upfront price. Buying looks cheaper on day one and often stays cheaper for common needs. The case for building strengthens over years, as subscription fees, per-seat pricing and the labour of workarounds pile up against a custom system's development cost.
On the buy side, count four things: subscription and per-seat fees over several years, integration and maintenance work, unused licences, and the staff hours spent on manual steps the tool forces.
On the build side, count development, ongoing maintenance and hosting, and delivery risk. Keep the risk honest. Large builds fail far more often than small ones, which is why tight scoping is the most effective way to protect the return. Our guide to what custom software costs to build covers the running costs most quotes leave out.
The answer turns on time horizon and fit. For a need you run the same way as everyone else, buying almost always wins. For a core workflow you will run for a decade, a system that removes daily friction can pull ahead.
A decision framework for leaders
A clear framework keeps the choice out of the realm of opinion, and project size is the strongest predictor of success. The same CHAOS 2020 summary puts small projects at about 90% success and large ones below 10%. Whatever you build, build it small.
Work through four questions in order:
- Is this workflow a core differentiator? If it is how you win customers, lean towards building. If it is a common back-office need, lean towards buying.
- Does a packaged tool fit without heavy workarounds? If yes, buy it. If you are already bending the operation to match the product, that friction is your answer.
- Can the build be scoped small? A tight first version that solves one painful problem beats a grand platform that may never ship.
- What is the five-year cost on each side? Compare subscriptions plus workaround labour against development plus maintenance, not sticker prices.
If the workflow is core, the fit is poor and the scope can stay small, custom usually wins. If any of those fails, buying is the safer bet.
Questions leaders ask
What does build vs buy software mean?
The choice between building an application around your own workflow and buying an off-the-shelf product. Building gives you control and fit; buying gives you speed and a lower upfront cost.
When is custom software worth the cost?
When a process is central to how you compete and no packaged tool fits it well. If you are bending your operations to match a product, that friction is the signal.
Is building software riskier than buying?
Large builds are. In the Standish Group's 2020 CHAOS data as summarised by OpenCommons, 31% of projects succeeded outright, with small projects at about 90% and large ones under 10%. Small, tightly scoped builds carry far less risk.
Who owns software built for us?
It depends on the contract, so read that clause before you sign. With us, unless the written agreement says otherwise, you get a licence to use what we build for your business, and the platform underneath it stays ours. When an agreement ends, you get an export of your data.
Pick one workflow where your team currently fights its software and run it through the four questions. Within an hour you will know whether the next step is a purchase or a build, and if it is a build, how small the first version can be. Our case studies show what that looked like for two clients.