Custom software vs standard software: an honest decision for an SME in 2026

There are two ways to get business software wrong. The first is buying an expensive, rigid standard product for a process that isn’t standard, and ending up running parallel spreadsheets to cover what the software doesn’t do. The second is commissioning a custom build from scratch for a process that actually is standard, and paying for an 18-month project to end up with a worse version of Holded.

This article isn’t a sales pitch. It’s the decision seen from the inside: when standard software is the right answer, when custom development is the right answer, and when the right answer is not to buy anything yet. The headline question — custom software vs standard software — is usually framed as if they were two rival religions. They aren’t. They’re two tools for different cases.

Quick decision by profile (fifteen-second summary)

• 100% standard process, small team, in a hurry: standard software (Holded, Odoo, Sage). Don’t overthink it.
• 80% standard process with 20% unusual: parametrised standard software plus an external custom integration. Pragmatic hybrid.
• Unique operational process, critical integration with a legacy system, or a competitive edge in how you work: custom software (or a modular product like Rowan ERP that starts with a built core).
• You’re going to change your process in the next 12 months and you don’t yet know how the operation will settle: don’t buy anything yet. Sort out the process first.
• Small company unsure where to start: an invoicing tool, a well-organised spreadsheet and a lightweight CRM will take you further than you’d think.

The rest of the article develops each profile with the criteria that matter: how they really differ, what real cost they carry over three years, and what signals to use to decide without a salesperson pushing you towards an option that doesn’t suit you.

What standard software is and what custom software is

Before comparing, it’s worth pinning down what each thing is, because the market uses the terms fairly loosely.

Standard software (also called packaged software, catalogue software, “off-the-shelf” or standard SaaS) is a closed product. You buy a licence or pay a monthly subscription and access an application built for many different companies to use. Adaptation happens through configuration: brands switch modules on or off, adjust fields within the product’s limits and choose templates. Holded, Sage 200, Odoo (in its Community version without partners), SAP Business One, Microsoft Dynamics 365 Business Central or Salesforce are examples. They’re good products for standard processes.

Custom software (or bespoke development) is a system built specifically for one company: it starts from an analysis of how that company actually works, defines its own data model, builds the screens and flows the real processes need, and integrates with the systems already in place. It doesn’t have a “billing module” — it has a billing module that does exactly what your company bills. Adaptation isn’t through configuration: it’s by design from day one.

Adaptable modular product is the middle category that has grown over the last five years. Products like Rowan ERP start with an already-built core (purchasing, sales, warehouse, production, CRM, treasury) and are then shaped to each client’s operation from there. It’s neither pure standard (because each implementation ends up different from the last) nor a build from zero (because much of the work is already done before you start). For many B2B SMEs with a semi-unique process, it’s the most sensible route.

Comparison table: standard software vs custom vs modular product

Note: the relative cost refers to 3-year TCO (licence or development + implementation + training + maintenance + future adaptations), not the sticker price. And the “Fit to process” column carries the most weight: if your process is atypical, what the other columns measure flips.

Criterion	Standard software	Adaptable modular product	Custom software
Starting point	Closed product	Already-built modular core	Blank page
Fit to process	Limited — you adapt to it	High — the product is shaped to your process	Total — the software is built around the process
Time to production	2-12 weeks	4-12 weeks (first phase)	4-18 months
Initial cost	€ (monthly licence)	€€ (closed implementation)	€€€ (full project)
3-year cost	€-€€ (depends on per-user licences)	€€ (typically no per-user licences)	€€-€€€ (no licences, variable maintenance)
Changes after go-live	Via configuration or extra module	Days — dedicated development team	Days — the team who built it
Who’s in charge	The product is in charge	Negotiation between product and process	The process is in charge
Obsolescence risk	Low (vendor maintains it)	Low (vendor maintains the core)	Medium-high (depends who maintains it)
Verifactu / B2B e-invoicing	Yes (vendor builds it)	Yes (included)	Yes (built as a requirement)
Integrations with your systems	From a connector catalogue	Custom, per project	Custom, per project
Learning curve	Variable (steep in SAP/Dynamics, gentle in Holded)	Medium (training included)	Medium-high (custom UX, no public documentation)
Support when something breaks	Via partner or vendor	Direct with the development team	Direct with the team that built it

Two more things, outside the table. For well-solved standard processes, custom software is always worse than standard: it takes longer, costs more and delivers less. And the reverse: for atypical processes where the way you work is part of your competitive edge, standard software is always worse: it forces you to erase the difference.

When to choose standard software (and stop looking)

There are profiles where the right decision is clear. If you’re in one of these, stop reading comparisons and buy:

1) Your process really is standard. Not “standard with quirks.” Standard. If what you do is sell product, invoice, collect payment, run the books, manage payroll and comply with the tax authority, there are good products for that. Holded, Sage 200, a3ERP, Odoo. Buying custom here is vanity.

2) You’re just starting out and don’t yet know what your process will look like. If the operation isn’t settled yet, building custom software is building on sand. Standard software gives you a prefabricated box that structures your business while you define it. Once the operation matures, you can decide whether to move to something more tailored.

3) Your team is small and you need something running now. If there are three people in billing and nobody is going to run a six-month implementation project, standard is the only viable option. Implementing it properly takes weeks, not years.

4) Implementation cost outweighs the differential value. If your process is semi-unique but the saving or competitive gain doesn’t justify paying for a custom project, accepting the cost of adapting yourself to the product is a valid call.

5) You need something very specific that standard already solves well: B2B e-invoicing compatible with Verifactu, a connector with your accountant’s A3 system, integration with your standard banking gateway. Cases where standard has the edge through inertia and network effects.

For profiles 1 and 2, the natural next step is reading an honest comparison of ERP for SMEs. For 3, it’s even worth sticking with an invoicing tool plus an organised spreadsheet if your volume allows it.

When to choose custom software (and it’s not what the salesperson told you)

Custom software has a bad reputation because a lot of people buy it for problems it doesn’t fit. But there are profiles where it’s clearly the better option:

1) Your operational process is the competitive edge. If what sets your company apart from the competition is how you work (production route, pricing logic, logistics model, approval flow), standard software pushes you to erase that difference. Custom software preserves it and leverages it.

2) You work in a vertical the market hasn’t covered. There are sectors where no good standard software exists: municipal recycling centre management, wine cooperative control, dual-temperature refrigerated distribution, reverse logistics for pallet returns. If your sector doesn’t appear in the Sage or SAP catalogues, it’s not because it doesn’t exist — it’s because the market isn’t big enough for them to bother.

3) You have critical integrations with legacy or industrial systems. Warehouse PLCs, connected scales, specific scanners, systems that have been running for years and can’t be touched. Standard software solves “REST API against Salesforce,” not “RS-232 scale reading connected to a 2008 Siemens PLC.”

4) You’ve outgrown the product. You started with Holded six years ago, now you have 80 people, three warehouses, two countries and a production process that fits no module. You’ve parametrised the product to its limit and filled the rest with spreadsheets and surface-level workarounds. Custom software at this point usually turns out better than migrating to SAP B1.

5) You’re about to change your process radically. If your business model is shifting (say, from classic wholesale to D2C marketplace, or from professional services to a SaaS product), building on standard means building on something that will stop fitting. Custom software lets you adapt to the new process without the product holding you back.

For profiles 1 to 4, the usual path is to consider custom software or an adaptable modular product that starts with much of the work already done. For 5, it’s better to wait until the new model is a bit more mature, unless you’re certain the transition will be final within six months.

How much it really costs to digitalise a company

The question of how much it costs to digitalise a company usually comes with a vendor-dependent answer: everyone gives you a range that happens to match what they sell. Here’s the breakdown by component, brand-free, so you can work it out yourself.

Cost components (regardless of the type of software)

• Licences or development: the part everyone looks at most. In standard, it’s a per-user licence or monthly subscription; in custom, it’s closed development priced per project; in a modular product, it’s closed implementation with no per-user licences.
• Implementation and consultancy: analysis, parametrisation, data migration from the previous system, integrations with systems that stay, training. This line item is usually double or triple the licence cost in standard software for a medium-sized SME, and almost every proposal underestimates it.
• Team training: hours spent learning, reduced productivity for the first two or three months, formal training with a consultant.
• Maintenance: bug fixes, evolution, mandatory updates, support. In standard, it’s usually a percentage of the annual licence; in custom, it’s a direct maintenance contract with whoever built it.
• Future adaptations: what you’ll pay in year 2 and year 3 when you discover you need an extra field, a new report, an integration with a system that didn’t exist when you started.
• Opportunity cost: what you lose while the system isn’t working or the team hasn’t mastered it. It’s real, it doesn’t show up in budgets, but it shows up in the numbers.

Relative ranges by company size

Company size	Standard software (3-year TCO)	Adaptable modular product	Custom software
Micro (1-5 people)	€ (light subscription)	Usually doesn’t make sense	Doesn’t make sense
Small (5-25)	€ to €€	€€	€€€ (rare)
Lower-medium (25-50)	€€	€€	€€-€€€
Medium (50-150)	€€-€€€	€€-€€€	€€€
Upper-medium (150-300)	€€€	€€€	€€€-€€€€

Three principles to estimate better:

1) Real TCO is double the sticker price. If you’re quoted an ERP for X €, the 3-year cost will land at 2X-3X once you add implementation, training, maintenance and future adaptations. This holds for any model (standard, modular or custom).

2) In standard software, licence cost grows with headcount; in custom and modular, it doesn’t (or barely does). If you’re going to grow from 30 to 100 people in three years, per-user licences in standard can triple your TCO, while custom development or a modular product without licences stays flat.

3) Switching cost counts. Once a system is implemented, leaving it costs between 50% and 100% of what implementing it cost. Deciding well the first time is cheaper than deciding fast and migrating later.

Hybrid: what many SMEs choose in practice

Most SMEs that arrive after three or four years with standard software end up in a hybrid model. They don’t jump to “everything custom”; they keep Sage or Holded for accounting and payroll (the most standard and regulated areas) and build custom software for the unique operational part (specific warehouse management, product configuration, pricing logic, production flows).

It’s a healthy pattern. It recognises that within one company there are highly standard processes (accounting, payroll, e-invoicing) where standard wins, and non-standard processes (operations, competitive edge, integration with industrial systems) where custom wins. The integration between both systems is built as a specific piece of the project.

The risk of a badly done hybrid is double data entry: if Sage and the custom system don’t talk to each other, someone ends up entering invoices or delivery notes by hand. A properly solved integration (ideally automatic via REST API) is what separates a good hybrid from a mediocre one.

Warning signs before you sign (standard or custom)

Before closing any contract, standard or custom, it’s worth checking these points. If two or more fail, the proposal isn’t mature yet.

For standard software:

• Is there a demo with your real data, not the provider’s?
• Does the quote include closed implementation, or just the licence?
• Are Verifactu and B2B e-invoicing native, or an extra module?
• Will the invoice double or triple if your team grows?
• Is support provided directly by the vendor or via an intermediate partner?
• Is there a real case of a company similar to yours using it in production?

For custom software:

• Who’s the actual technical team? Will you have access to them after go-live?
• Is the proposal phased with productive deliverables every 4-8 weeks, or a big bang after 18 months?
• Is it clear what happens to the code if the relationship breaks down (escrow, shared repository)?
• Does the architecture allow another company to pick up development in the future?
• Is the price fixed or hourly? Who absorbs overruns?
• Are Verifactu and B2B e-invoicing built in from the start as a requirement, or “we’ll see later”?

If a proposal fails on several points in its column, the right move is to renegotiate or walk away. The investment is big enough not to rush.

Frequently asked questions

What’s cheaper over 3 years: custom software or standard? It depends on volume and growth. In small companies (under 25 people), standard is almost always cheaper. In medium companies (50-150) with per-user licences and sustained growth, custom or a modular product without per-user licences tends to level out or come in lower from year 2-3 onward. Beyond 150 people and with a semi-unique process, custom or modular is cheaper in TCO almost every time.

Does custom software become obsolete? If nobody maintains it, yes. Same as standard software if the vendor discontinues it. The right question isn’t whether it will become obsolete, but who will maintain it and for how long. Well-built custom software costs less to maintain than paying a vendor for standard software’s ongoing evolution. Badly built custom software (a surface-level build on top of spaghetti code) does age badly.

How long does it take for custom development to be productive? A custom project from scratch usually takes between 4 and 18 months depending on scope. Adaptable modular products (which start with a built core) usually have a first productive phase in 4-8 weeks and a full go-live in 3-5 months. If someone promises custom software from scratch “in six weeks,” either you’re buying something that’s really a dressed-up WordPress, or you should question the scope.

Do I need an ERP or custom software? The question is framed wrong. An ERP is a category of software (integrated business management). It can be standard (Sage 200, SAP Business One) or custom (an ERP built for your company). The right question is: for my process, is a standard ERP, an adaptable modular ERP, or a custom ERP better? All three are valid depending on the case.

Does the Kit Digital grant cover this? For basic standard digitalisation software, yes. For real custom development, generally not: the programme’s amounts and conditions are designed for websites and catalogue tools. If you need operational custom software, the route is a private budget.

How do I choose between building in-house (with an internal team) or outsourcing? If you have your own development team, know the business domain and will maintain the software for years, doing it in-house is reasonable. If you don’t have a team or the development is a one-off project, outsourcing to a company that can maintain it afterwards is the usual option. The common mistake is hiring a cheap freelancer for a long project: when the freelancer moves on to another client, your system is left orphaned.

In summary

The choice between custom software and standard software isn’t a decision of identity (“we’re a premium company, we go custom”) or budget (“we’re small, we go standard”). It’s a technical decision with clear criteria: how standard your process actually is, what your current and projected volume is, what role the software plays in your competitive edge, and how much real maintenance capacity you have over three years.

For standard processes in small and medium SMEs, standard software is almost always the right answer. For atypical processes where the way you work is part of the value, custom software (or an adaptable modular product) tends to win. And for companies in the middle of a model transition, the cheapest option is usually not to buy anything yet and sort out the process first.

If you’re genuinely unsure where your company fits, the most useful next step is an honest look at your current operation before choosing a path. A first consultation with a team willing to tell you “you don’t need custom” is worth far more than three demos from vendors trying to sell you something.