Why "custom or off-the-shelf" is the wrong question
You've got an Excel sheet for orders, an ERP module the team works around for half the steps, or a SaaS that leaves out exactly the part that matters most. At some point, someone says "let's just build our own software". The question that follows is usually the wrong one: custom software or off-the-shelf, as a single choice for the whole process.
In fact, the decision is made piece by piece: which part of the process is too common to be worth reinventing, and which part is specific to your company, so specific that no standard package covers it. The article walks through the criteria that matter, shows the hybrid option most companies miss, then a decision table and the warning signs of an unreliable software development proposal.
First criterion: how standard the process is, and how much it sets you apart
A simple software engineering test helps with the decision: if the process you want to change is something every company in your industry does the same way — accounting, onboarding, issuing an invoice — you buy an off-the-shelf tool and adapt your process to it. If the process is the very reason customers choose you, that part deserves purpose-written code. Martin Fowler puts it directly: if the process is part of your competitive advantage, you build custom software; if not, you buy a package and adapt to it.
Context: across the EU, off-the-shelf tools are already the norm — the share of companies with an ERP ranges from 41% at small companies to 89% at large ones, and 53% of EU companies use at least one ERP, CRM, or BI system, according to Eurostat (2025). The standard core is almost always the right starting point; the useful question is what's missing from it, for you.
Second criterion: what needs to talk to what
Few off-the-shelf tools talk natively to everything you already have in the company. An ERP like SAGA or SAP, a courier with daily AWBs, ANAF's RO e-Factura system — each has its own format, and a generic SaaS rarely covers all of them out of the box, especially for a flow specific to a Romanian company. Most of the time, this friction isn't solved by replacing the core, but through small, dedicated web apps built exactly for the bridge between systems.
The deadlines aren't theoretical: B2B reporting in RO e-Factura became mandatory from 1 January 2024, and B2B invoicing through the same system from 1 July 2024, according to the Ministry of Finance. Whether invoicing stays on the bought tool or ends up in a custom-built piece, e-Factura integration isn't optional — it's a legal requirement that gets ticked off either way.
Third criterion: who owns the code, the infrastructure, and the data
When you buy a subscription, your data usually sits in the provider's format, on the provider's infrastructure. As long as the relationship goes well, it doesn't matter. It matters the day the provider changes its prices, gets bought out, or shuts the product down — at which point you're negotiating from the position of a company that owns none of what it built.
Hence the trap of aggressively customising a bought package. Thoughtworks points out that customising bought software carries the same risks as building from scratch — delays, unforeseen costs, skills unrelated to your core activity — but without the advantage of owning the code at the end. Fowler recommends the opposite: instead of customising the bought core, you build separate pieces, connected through APIs, that you own outright — exactly the principle behind the hybrid option.
Fourth criterion: the three-year cost, not the starting price
A subscription looks cheap in the first month. Over three years, the cost grows with the number of users, with the volume of data and, almost always, with the fees for exactly the exceptions you need — an extra module, a higher-tier plan, an add-on just for your flow. A custom build costs more upfront and needs maintenance afterwards, but its curve is different: the big effort is concentrated at the start, and it doesn't multiply with every new user.
There's no universal verdict — neither "always buy" nor "always build". Forrester describes it as a pendulum: companies that consistently go to one extreme lose control or speed, while deliberate combination brings the most stable result. Time to value matters just as much as price — a bought tool is almost always faster to get up and running than a build from scratch, one more reason not to throw out the core.
The option most companies miss: the core stays, the pieces get custom-built
The "custom or off-the-shelf" discussion gets stuck because it's framed as a single choice for the whole system. The hybrid option — you keep the standard core and only custom-build the pieces that are missing — is the option companies that look at long-term cost, not just the starting price, often land on. The pieces built around it are usually three: integrations, internal admin panels, and automations.
AutosWorld is a concrete example, still in the launch stage: an online store built on WooCommerce, with the standard platform untouched. What's custom-built is the back-office admin panel — a dashboard, quick product editing, dedicated fields for supplier and margin, calculated automatically. After logging in, the team lands directly in their own panel, not in WordPress, so day-to-day stock operations don't depend on anyone outside the company.
Tchibo GAME ON shows the opposite situation — the process really is the product. The campaign needed receipt uploads from a phone, automatic validation, and anti-fraud rules against duplicate receipts. No off-the-shelf tool covered this combination, so the platform was built entirely custom, by The Niche Society. The difference from AutosWorld isn't one of quality, it's a difference in the type of process.
The decision table: what we recommend, depending on the situation
The criteria above give a different answer for every company. The table gathers the common situations and the recommendation that fits each one.
| Situation | Recommendation | Why |
|---|---|---|
| A process that's identical at every company in the industry | You buy the off-the-shelf tool | Nobody wins by reinventing a standardised process |
| The team wastes time manually copying data to another system | You build a custom integration on top of the core | The problem sits at the border between systems, not in the core |
| The process is why customers choose you, not the competition | You build custom software for that piece | A standard package brings you up to market level |
| You need a simple back-office on top of a standard platform (e.g. an online store) | You keep the core, and add a custom-built panel | The core stays easy to update |
| You don't yet know which process you want to automate | Start with a written discovery, not a code order | A wrong scope costs more than a month of analysis |
What a serious first build looks like — and what to look for in a proposal
A serious first build doesn't start with code, but with a short discovery wrapped up in a document: what gets built, what doesn't, what the integrations look like, and who does what. The first launch is deliberately small — a single flow, taken all the way through. The code and infrastructure sit, from day one, on the client company's account.
Maintenance doesn't stop at launch: dependencies age, integrations can break when the ERP or the e-Factura spec changes, and security patches aren't optional. Software "forgotten" for two or three years quietly becomes a risk — the maintenance budget is worth discussing from the first proposal.
- 01Fixed price before any discovery the effort was guessed, not seen
- 02Scope only in verbal discussions, not written down misunderstandings only surface at delivery
- 03The code stays on the provider's account without access, you're tied to them indefinitely
- 04A single launch, with everything at once problems surface too late
- 05No discussion of what comes after launch the first problem becomes an emergency, not a planned task
Sources and further reading.
Frequently asked questions
When is it worth building custom software instead of buying an off-the-shelf tool?
When the process is the reason customers choose you over a competitor, or when no combination of tools on the market covers the exact flow you need. For everything that's common in your industry, it's usually cheaper to buy and adapt your process to it.
What does the hybrid option mean, and why do most companies miss it?
Keep the standard tool you're already using and only custom-build the pieces that are missing — integrations, internal panels, automations. It's often missed because the discussion starts as a single choice between "buy everything" and "build everything", when the decision is actually made separately, piece by piece.
How do I recognise a serious custom software development proposal?
Start with a discovery and a written scope, not a fixed price given in the first conversation. Propose a small first launch, not a "big bang" with everything ever imagined, and leave the code on your company's account from day one.
Who should own the code and infrastructure on a custom software project?
The client company, not the agency building it. The code sits on your organisation's account, the infrastructure on your own cloud account, even if the agency manages it day to day. That way you can switch providers any time, without losing what you've built.
Let's see what can be automated in your business.
A free 30-minute session: we'll tell you what can be automated, how long it takes and what it costs, with a fixed price after discovery.