Custom or off-the-shelf business software: how to choose

When a company has to choose between ready-made business software and something built for it, the discussion usually starts with products: demos, price lists, feature grids. I start with how the work gets done today. The product comparison comes later, and by then you know exactly what to check in each demo.

These are the criteria I use. The legal points link to their source; for contracts you still need a lawyer.

In short

Before looking at products, map today’s workflow and try to shorten it.
Compare costs over at least five years, maintenance included.
Accounting, payroll and invoicing are well served by existing products. Custom software makes sense for the processes that are yours alone.
Integrations with the tools you already use often matter more than features.
Always ask how your data gets exported and, for custom work, who owns the code.
Consider the middle way: an off-the-shelf product for the standard part, connected to a custom part.

Start with the workflow

The first thing I look at is the work as it happens now: who does what, in what order, where people wait for someone else, where the same data is retyped from one program into another.

The mistake I see most often is a very long workflow, with many steps in a row. Every step is a point where something can go wrong, and the chances of error add up. Automate a twelve-step workflow and you get software with twelve steps: more to build or configure, and every one of them has to be tested. So before automating a workflow, I try to shorten it. Two steps can sometimes be merged; sometimes a step exists only to fix the mistakes of the one before, and can go.

Then I break the problem into smaller parts and put it on paper, as flow diagrams and written descriptions. For each step I write down:

who does it and when;
which data it uses and where that data comes from;
where the result goes and who uses it next;
what happens when a piece of data is missing or wrong.

The document is useful even if you end up buying a product: at demos, ask the vendor to walk through your steps, with data like yours. Code, if needed, comes only at the end, once the workflow holds up on paper.

The real cost, over five years

A monthly subscription and a quote for custom development can only be compared once you add up everything you’ll pay over the years.

For an off-the-shelf product:

licences per user or per site, and how they grow as the team grows;
add-on modules you discover you need after buying;
initial setup, data migration, training;
price increases at renewal;
the time staff spend working around what the product doesn’t do, usually in side spreadsheets.

For custom software:

analysis and initial development;
hosting and backups;
yearly maintenance: security updates, new versions of libraries and of the language, small changes;
documentation, so someone else can work on it later.

A worked example with made-up figures: 15 users at €40 a month is €7,200 a year, €36,000 over five years, before modules and price rises. Compare a custom project against that total, with its own maintenance costs added in.

Italian public bodies are legally required to make this comparison before buying software, and one of the criteria the law sets is the overall cost of the solution, covering purchase, implementation, maintenance and support (Italian Digital Administration Code, art. 68). It’s a sound rule for a private company too.

How specific your processes are

If a process works the way it does in any other company, building it from scratch rarely pays off. Invoicing, accounting and payroll are covered by mature products.

Custom software starts to make sense when you see signs like these:

every day someone copies the same data from one program to another;
one spreadsheet holds everything together, and only one person knows how it works;
you changed a process that worked in order to fit the product;
the changes you ask your vendor for take weeks, or sit in a queue.

The opposite case exists too. If the process changes every month, or you can’t describe it yet, settle it before you turn it into code.

Integrations often decide it

List the systems your business software has to talk to: invoicing, payments, your online shop, your accountant’s software, customer or supplier platforms. For a product, ask whether it has documented APIs, whether they’re included in the plan you’re buying, what limits they have and whether it can notify another system when something happens (a webhook, for example).

With custom work it’s better to connect to what already exists than to rebuild it. If several platforms each have their own users and passwords, single sign-on can sit on top: for a professional football club I built single sign-on across all the club’s platforms, so each user sees the platforms they belong to.

Data, code and lock-in

With an off-the-shelf product, before signing, ask how your data is exported (all of it, attachments and history included), in what format, and what happens when the contract ends.

If the product runs in the cloud, the EU Data Act (Regulation 2023/2854) has set specific rules since 12 September 2025. It covers “data processing services”, and says these include software as a service, SaaS (recital 81). Among other things, the contract must set out (art. 25):

a maximum notice period of two months to start switching to another provider;
a transition period of 30 days, during which the service keeps running;
at least 30 days to retrieve your data after the transition;
an exhaustive list of the data that can be exported.

From 12 January 2027 providers can no longer charge for switching; until then they may charge only reduced fees, capped at the costs directly linked to the switch (art. 29). The ban on switching charges doesn’t apply to services mostly custom-built for one customer and not offered at broad commercial scale (art. 31).

With custom software the question is who owns the code. In Italy, copyright law gives the employer the rights to software written by an employee, unless agreed otherwise (Law 633/1941, art. 12-bis). With an outside supplier, put it all in the contract: transfer of rights, source code in your own repository, documentation. In my work, code and data stay with the client.

Custom software has its own lock-in: if only one person knows how it works, you depend on that person. That’s why my projects include documentation and a proper handover, and why I choose technologies partly based on who will maintain the software after me.

The middle way: customising an existing product

You can start from an off-the-shelf product and:

configure it: fields, roles, statuses, document templates;
extend it with a module or plugin that uses the official APIs;
run a small custom application beside it, connected through the API, for the part the product doesn’t cover.

For a job listings portal, for example, I connected a WordPress plugin to the listings backend to handle applications.

The risk to watch is updates. Customisations that change the product’s internal code can break with the next version. Before starting, ask whether they survive updates and who maintains them. Where possible, go for extensions built on the documented APIs.

To look at your case before choosing, see custom business software consulting.