A department has a process that has been choking on spreadsheets and email for months. Someone suggests a ready-made tool on subscription, someone else wants to hire a software house, and an enthusiast in IT says he'll build it himself after hours. The question usually gets framed as a binary choice and settled on licence price. Both assumptions are wrong. The decision depends on what the process is like and what should remain in the company once the work is done — and the right answer is most often neither pure renting nor pure building, but a combination of both.
What follows is a single decision frame: first whether to buy or build (six criteria and the full cost of ownership), then who should build (in-house or a software house), and finally the condition that decides whether any of it survives.
In short
- "Which is cheaper" is the wrong first question — the licence price describes the least reliable component of cost.
- Buy versus build is decided by six criteria: process uniqueness, strategic weight, data sensitivity, depth of integration, speed of deployment and economics over time.
- Licence cost ≠ cost of ownership. On the subscription side add integrations, workarounds and lock-in that surfaces at renewal; on the build side, maintenance.
- Producing a tool ≠ implementing it. The first ends with handing over code; the second, with someone in the company able to develop the tool. All three routes — in-house, software house and off-the-shelf — share this blind spot.
- The right answer is most often a hybrid — off-the-shelf where the process is standard, dedicated where it constitutes an advantage.
What "custom system" means here
A custom system is a tool built around a single company process, plugged into the existing way of working and existing systems, which — together with its data — remains the company's property. It doesn't have to cover the whole organisation or replace the ERP. Ready-made SaaS is the opposite: a product whose logic the company adapts its process to, with the data staying on the vendor's infrastructure. AI can be part of either — as one of the means, not the starting point. The process and its bottleneck come first, the tool second.
Why "what's cheaper" is the wrong first question
Licence price describes only the single most visible cost component. On the subscription side, the full cost of ownership also includes integrations, process workarounds forced by the tool's rigidity, and growing vendor lock-in that surfaces at contract renewal. On the custom side — the cost of building and maintaining the system, independent of the number of seats.
Both sides tend to be underestimated. Buyers don't count the integration work and the price escalation in year three; builders don't count maintenance. A rigorous comparison weighs the total cost of both models against a measurable effect — hours saved, fewer errors, shorter response times — not two line items on an invoice. More on this: why no one will give you a price for an AI implementation.
Buy or build: six criteria
Each of the six questions pushes the decision one way or the other; the more answers land on the "custom" side, the stronger the case for building.
Process uniqueness. If the process looks the same across most companies in the industry, a ready-made tool will handle it without costing you any advantage. If the way the company runs it is part of its edge, a ready-made platform will force the company to adapt to the tool, not the other way round.
Strategic weight. Processes tied to margin, customer experience or operational capacity deserve a solution built for them. Peripheral processes don't.
Data sensitivity and ownership. The more confidential the data, or the more it functions as a company asset, the more control over where it lives and who can access it matters. In a subscription model, the data stays with the vendor.
Integration depth. A tool that has to coordinate several systems (ERP, MES, existing databases) needs a growing and fragile integration layer in a ready-made model. A custom system is designed around those connections from the start.
Speed of deployment. If the solution has to be running within days, a ready-made tool wins — provided the process is standard. For a non-standard process, the subscription's "quick start" turns into months of configuration and workarounds.
Economics over time. A subscription grows along an axis the vendor chooses — seats, contacts, revenue — regardless of the value it delivers. A custom system costs once, plus maintenance, and doesn't grow with the company's scale.
Ready-made SaaS is the fastest route to getting started when the process is standard and the data isn't sensitive. A mid-sized manufacturer, however, rarely fits a ready-made product: processes tend to be specific, and data is scattered across spreadsheets and email. The result is either using a fraction of the features while paying for all of them, or costly customisation that is closer to a software project than a purchase off the shelf. A custom system becomes cheaper and safer as the company grows and the value of its accumulated data rises.
Who builds: in-house or a software house
If the criteria point towards building, a second question follows — who.
In-house. It looks like the cheapest option and gives full control, but it only works if someone in the company understands both the process and the tooling and has the time to finish the solution and keep it running. In most mid-sized manufacturers that person either doesn't exist or is the most overloaded person in the organisation. The typical failure: someone starts building after hours, a promising prototype appears, and then the project dies — day-to-day duties bury the priority, or the author leaves and the knowledge, which lived in one head, was never written down.
Software house. It solves the problem of time and technical skills, and works well for projects with a clearly defined, stable scope. The weakness shows up in two places. First, distance from the process: the vendor knows the technology but not your company, so the first weeks go on explaining how the department really works, and it's easy to end up with something technically correct that misses how things actually run. Second, dependence after go-live: every change goes back to the vendor, and the company is left with a tool it can't touch itself. The better the implementation, the stronger that dependence.
The blind spot of all three routes
All three routes treat implementation as a one-off act of producing a tool. The application gets built — and that's where the thinking stops. Yet survival depends on something else: whether someone stays in the company who understands how the tool works and can keep developing it.
Hence the route I run: building together with the department's team, on site, handing over competence along the way. The tool is built at the pace of an outside engagement, but it doesn't leave with the vendor — the knowledge of who maintains it and how stays behind. This also undoes the myth that "custom means expensive and slow". The picture of a costly, months-long project with its own engineering team is accurate — but it describes a grand transformation, not a microapp embedded in one process. The reference point for a single-process pilot is four to six weeks, ending in a working tool with a before-and-after effect; it requires no ERP replacement, and the system and its data remain company property. That moves "custom" from the megaproject category to a single, reversible step. See microapps instead of a grand transformation and a pilot implementation in 4-6 weeks.
Hybrid as the default answer
For most mid-sized B2B companies, the best answer is neither pure renting nor pure building. Ready-made tools handle universal processes — email, basic communication, standard tasks. A thin, dedicated layer is built where the company actually stands out: technical quoting, after-sales service, logistics, sales, production or marketing. The company buys what is the same for everyone anyway and invests in what constitutes its edge. An off-the-shelf tool ≠ the department's own tool — and a hybrid lets you have each where it fits. Choosing the first process is covered in don't start with the most interesting idea.
How to decide
Three steps, in this order:
- Buy or build? A majority of "standard, non-sensitive, urgent" answers points to ready-made SaaS; "differentiating, sensitive, deeply integrated" to a custom system; a mix to the hybrid.
- Who builds? Do we have someone with the time and skills to build and maintain it? Can the scope be described upfront? If so, in-house or a software house make sense.
- What remains? Does it matter to us to be self-sufficient afterwards? If so, what counts is how much knowledge stays in the company, whoever builds it. Over the years, this answer weighs most.
The worst choice is no choice. An implementation that drifts between routes, because no one decided who owns it and what should remain once it's done, ends worse than any route followed through consistently.
When not to build anything
If the process is standard, the data isn't sensitive, the integration is shallow and the need is urgent, building your own solution gives no advantage. Where a mature product covers the process without contortions, buying is more sensible than building anything. That is a valid outcome of the analysis, not a failure.
What we don't know yet
- what working around your current tool's limits costs you today — that figure usually decides the comparison;
- how long the company intends to use the solution — the arithmetic differs at a one-year and a five-year horizon;
- who maintains the solution in two years, whoever builds it — and whether that person is already on the payroll;
- which data genuinely has to stay in-house and which can be processed externally;
- what it costs to exit the chosen route if it turns out to be wrong.
Frequently asked questions
Is a custom AI system more expensive than ready-made SaaS?
In the first year, usually yes, because it requires a build cost. Over several years it depends on scale: a subscription grows with seats or revenue and never stops, while a custom system costs once, plus maintenance. What decides it is the total cost of ownership weighed against the effect, not the licence price.
Should we build in-house or outsource?
It depends on whether the company has someone who understands both the process and the tooling and has time not only to build but to maintain the solution. If not, the in-house route usually ends with a promising prototype that dies once daily duties take over.
When is a software house the right choice?
For projects with a clearly defined, stable scope. It fares worse when the scope is discovered along the way, and after go-live every change goes back to the vendor.
When is ready-made SaaS enough?
When the process is standard, the data isn't sensitive, the integration is shallow, the need is urgent, and a mature product covers the process without contortions. Then building your own gives no advantage.
How long does a custom system take in a mid-sized company?
In the model of a microapp embedded in one process, the reference point for a pilot is four to six weeks, ending in a working tool. A custom microapp plugs into existing systems and doesn't require replacing the ERP.
What is a hybrid approach?
Ready-made tools for universal processes and a dedicated layer built around the process that sets the company apart. For most mid-sized B2B companies, it is the most practical answer.
What's next
Start by identifying where the bottleneck sits and what the process really looks like — that decides which route fits, not the other way round. The Process Audit puts the answers to the six criteria in order; for wider context, see seven dimensions of readiness.
→ Book a 30-minute consultation
→ Find out where the bottleneck costs you most with a free process diagnosis
→ See what working together looks like
This article sets out the buy, outsource or build decision at the level of criteria. It is not a quote, a comparison of specific vendors or a recommendation for your company — that requires looking at your process.
