Business management software: when the package is enough and when you need custom

The administration manager of a manufacturing company with forty employees keeps an Excel file open all day next to the business management software. Inside it are the subcontracted operations: which parts went out, to whom, when they should come back, what price was agreed. The system the company has been paying for over six years cannot handle that step, so she handles it by hand. She has been doing it for three years. Nobody in the company sees it as a problem: they see it as her job.

That file costs the company more than the software does. That is not a figure of speech: by the end of this article you will have the calculation line by line, a threshold in euros above which the arithmetic flips, and five questions to put to your own people so you can work out where you stand without calling a single vendor.

I am writing this because every article on the subject is written by someone who sells business management software, which is why they all end with the same advice. I do not sell it. I have been building custom software for twenty six years, and that is exactly why I can say the thing no vendor will ever say: for the large majority of small and mid sized companies, fully custom business management software is a waste of money. The right answer is almost always something else, and it is not keeping the off the shelf package exactly as it is either.

One note about the market before we get into it, because it says something about the people around you. On 19 August 2026 I checked what a click costs on these searches in Google Keyword Planner: from 1.88 euros for the generic term up to 22.24 euros for the custom variants. Twenty two euros for a single click means the people selling these products know precisely what a customer arriving from here is worth. Keep that in mind when you read your next quote.

What business management software actually does, beyond invoicing

Business management software is the system that keeps a company's data and repetitive processes in one place: customer and supplier records, orders, stock, purchasing, invoicing, accounting, tax obligations. Its real job is not producing invoices, which is the visible part. Its real job is being the one place where a piece of data is written once and read by everybody else without being retyped.

Three words get used interchangeably in conversations with vendors, and they are not the same thing.

Management software is the generic label: it covers everything from electronic invoicing to a complete company system. ERP means a system that genuinely integrates every area, from production to cost accounting, on a single data store. Vertical means a package built for one specific industry: the one for body shops, the one for law firms, the one for wineries. The vertical is the most interesting middle ground on the market and it is routinely skipped in evaluations, because it already arrives with your industry's vocabulary and processes inside it.

The distinction that matters for the decision in front of you, though, is not between those three words. It is between the processes your company runs the same way as everybody else and the processes your company runs its own way. You do accounting the way everyone does: the rules are written by the state, not by you. Invoicing likewise. How you calculate agent commissions, how you price a job, the logic by which you decide which batch ships first: those you do your own way, and they are the reason customers pick you. The entire off the shelf versus custom question is decided along that line, and the rest of this article walks it.

Off the shelf business management software: what you get now and what you pay later

An off the shelf package gives you three things custom cannot: it starts in weeks rather than months, it costs little in the first year, and regulatory updates arrive on their own. That last point is worth more than it looks. When the electronic invoicing format changes or a new obligation appears, the vendor implements it once for ten thousand customers and you receive an update. If that piece were yours, you would be paying for that work yourself.

The package is the right choice as long as one condition holds, and the condition is this: the company accepts working the way the software says. That is not surrender. For most administrative processes it is actually an advantage, because the way the package does them is the distilled result of thousands of installations and is probably tidier than yours.

Where the bill starts climbing

The price in the first quote is almost always the entry price, and it grows along three predictable lines.

The first is seats. Per user subscriptions in Italy sit roughly between thirty and eighty euros a month depending on the product and the profile. Fifteen people using it, at an average of fifty five euros, is about ten thousand euros a year in subscription alone. It is a figure that looks reasonable in year one and that by year five you have paid five times over while owning nothing.

The second is modules. The base package does not include production, or advanced warehousing, or site management, or cost accounting. Each one is switched on separately, and each has its price, sometimes one off and more often another subscription.

The third is customisation. Every serious package lets you adapt something: extra fields, printed layouts, a few automations. They are billed by the day, and a day from someone who knows that specific product costs what a developer's day costs. The delicate part is not the price. It is that customisations are tied to the version. When a major upgrade lands, they have to be checked and often redone, and that item never appears in the initial quote.

None of those three items is dishonest. They are the business model, and it is a model that works. The problem starts when a company keeps paying them for years to obtain an adaptation that stays partial, while the fourth item, the one nobody counts, grows quietly.

The cost nobody puts in the books: the hours your company spends patching

The biggest cost item of a system that no longer fits is not the subscription. It is the people who every day do by hand what the software does not do: the parallel spreadsheet, moving data from one system to another, the cross check before anything goes to a customer, the phone call to find out a number that should have been on screen.

That cost appears nowhere in the accounts, because you pay those people anyway. Which is exactly why it is dangerous: an invisible cost never gets compared against the investment that would remove it.

The calculation, with real numbers

Take one person in administration or production planning who spends two hours a day on patch work. Two hours is a conservative estimate: in the companies where I have actually looked, once you add up the parallel file, the checks and the retyping, it is usually more.

Two hours a day, over two hundred and twenty working days, is four hundred and forty hours a year. At twenty five euros an hour of fully loaded cost, which is a realistic and not inflated figure for an Italian administrative role, the total is eleven thousand euros a year, for one person. If two people are patching, and in a forty employee company there are almost always at least two, you are at twenty two thousand euros a year walking out of the company without anyone seeing it.

The three items that stack on top

Three further costs are harder to quantify but they weigh.

Errors. Data retyped by hand has a failure rate that is not theoretical. A wrong quantity on an order, an old price on a proposal, a delivery promised against stock that was not there: the company knows what each of those episodes costs because it has already paid, and nobody ever traces them back to the software.

Slow decisions. If working out the real margin on a job takes somebody three days, that number gets asked for only when it is already too late. It is not a loss you see in the profit and loss account. It is a loss you see in decisions taken worse than they could have been.

Dependence on one person. Only one person knows how to use the parallel spreadsheet. When that person is on holiday, the process slows down. When that person changes job, the company discovers it had outsourced a piece of its own functioning to an individual memory. That is the risk that most often turns an annoyance tolerated for years into an emergency inside a week.

Custom business management software: the thirty thousand euro threshold

The threshold is this: as long as the total annual cost of your current system stays below thirty thousand euros, the package almost always wins. Above it, every year that passes makes custom pay back sooner.

Two honest caveats before I explain it. It is a rule of thumb, not a law, and I have seen cases that break it in both directions. And total annual cost is not the subscription: it is the sum of everything the current arrangement costs you in a year, including the hours from the previous section.

The calculation, line by line

Take the company from the opening: forty employees, fifteen people using the system.

Base subscription, fifteen seats at fifty five euros a month: 9,900 euros a year. Two modules added over the years, production and cost accounting, at roughly three thousand euros each: 6,000 euros. Support and upgrade contract, which when it is not already inside the subscription runs around fifteen per cent of licence value: 1,500 euros. This year's customisation work, five days at six hundred euros: 3,000 euros. The patching hours of two people: 22,000 euros.

Total: 42,400 euros a year. Of which only 20,400 shows up anywhere as a software cost. The other twenty two thousand is salary.

Why thirty thousand and not some other number

The threshold is not arbitrary and it does not come from a study. It comes from the real price band of a well scoped custom project in Italy. A piece of work covering two or three specific processes, integrated with what you already have, without touching accounting, sits in a range that starts around twenty five thousand and reaches forty five thousand euros. Spent once.

If your current arrangement costs forty two thousand a year, a thirty five thousand investment that removes twenty a year pays back in under two years and is margin from the third onwards. If your current arrangement costs twelve thousand a year because five people use it and nobody keeps a parallel file, the same investment never pays back, and whoever is proposing it is selling you something you do not need.

That is why the first question I ask anyone who contacts me about custom business management software is not what they would like to build, but what they are spending today, hours included. If the number is low I say so and the conversation ends there. You can run the same calculation yourself this afternoon, and it is worth more than five quotes. If you would rather run it with someone who has seen those numbers in dozens of companies, you can ask for the real cost of the software you already run.

Three signs your business management software is no longer enough

The euro calculation tells you whether you can afford to change. The three signs below tell you whether you need to. They take two minutes to spot and require no technical knowledge: two questions to the right people is enough. If you recognise two out of three, the package is no longer enough.

First sign: somebody keeps a parallel file

Somewhere in the company there is a spreadsheet, or a notebook, or a chat group, holding data that ought to live in the system. Subcontracted work, contract expiry dates, delivery planning, parts on loan to customers.

The way to find it is not to ask the managers, who often do not know. It is to ask the people doing the work, and to ask well. The question that works is "what do you open in the morning besides the system?". The answer comes in ten seconds and without embarrassment, because to the person doing it this is not a workaround, it is their method.

What it means if you recognise it: the company has already paid to build itself a piece of custom software. It did so with the wrong tool, without oversight and without anyone deciding to, and it keeps paying for it every day in hours.

Second sign: the process that sets you apart runs outside the system

This is the most important sign and the least noticed. Ask yourself what makes customers choose you rather than a competitor. The way you configure a product to order, the speed with which you answer a complex request for quotation, the after sales service the others do not provide.

Now look at where that activity runs. If it runs inside the system, you are fine. If it runs in people's heads, in email and in a spreadsheet, your competitive advantage is resting on the only part of the arrangement nobody ever designed.

There is a structural reason for this, and it is not the vendor's fault. A package is built on the common denominator of ten thousand companies. What sets you apart is by definition not in the common denominator. A package can never contain your competitive advantage, because if it did, your competitors running the same package would have it too.

What it means if you recognise it: this is candidate number one for custom work, and it is probably the only one you genuinely need.

Third sign: the number exists but arrives late

Ask for margin by job for the last quarter, or the real stock value as of today, or which customers bought less than last year. Time how long the answer takes.

If the answer is "I will have it for you Thursday", the number exists but is not available, and for the company those two states are equivalent. A number that takes three days does not enter daily decisions. It only enters the monthly meeting, by which time whatever needed deciding has already been decided by somebody on instinct.

What it means if you recognise it: often you do not need new software, you need a way to read what the system already holds. It is the cheapest intervention described in this article, and almost nobody proposes it because there is little in it for the seller.

What custom business management software really costs

The bands below are orders of magnitude for the Italian market, for work done by serious suppliers with people based in Italy. They are not a price list and they do not replace an analysis, but they let you tell immediately whether a quote in your hand belongs to the real world.

Entry band: twenty to forty five thousand euros

Custom work in this band covers one or two well bounded processes, integrates them with the system you already run, and puts them in the hands of a limited number of people. The subcontracting management from the opening example belongs here, along with a quotation configurator for made to order products, a delivery planning system, or a portal where customers see the state of their orders.

This is the band where most projects that make sense actually live, and also the least talked about, because it is not big enough to be news and not small enough to be an app.

Middle band: forty five to ninety thousand euros

Here custom work covers an entire area of the company: all of production, or all of sales, or all of logistics. It involves several departments, requires migrating historical data from the old system, has to work on a mobile device or a shop floor terminal, and needs serious roles and permissions because twenty or thirty people work in it.

This is the band where the project stops being a technical job and becomes a company project: the variable that decides the outcome is no longer the software, it is how much time the company's own people can genuinely give it.

Upper band: above ninety thousand euros

You get here when custom work replaces the system as a whole, accounting included, or when the software is not just internal but becomes a product the company offers its own customers. This is the territory I worked in when I built and later sold a product for law firms, and it is a different trade: you are no longer computerising processes, you are making a product, with everything that implies in maintenance and evolution.

In this band the right question is not what it costs, but whether the company wants to enter the business of owning software. Some do, and for them it is the best decision available. Many do not, and for them it is a burden.

The four things that move the price inside any band

For the same set of features, quotes differ for four reasons, and those four are what to settle before asking for a number.

How many integrations are needed. Every system the new software has to talk to is work: the existing package, the courier portal, the web shop, the shop floor terminals. Integrations are also the least predictable part, because they depend on how the other system is built and not on you.

How much data has to be brought across. Migrating ten years of history from an old system, with duplicated records and fields used for purposes nobody intended, is often a fifth of the project. In optimistic quotes it is worth half a line.

How many people will use it and with what training. Software used by three people in an office and software used by thirty operators on a shop floor are two different projects even when they do the same thing. The second has to survive haste, gloves and low familiarity.

Where it has to work. On an office computer only is one thing. Also on a phone, also off site, also when the shop floor connection drops: those are three more things, and each has a price.

If you are also weighing up doing it with your own people, the honest comparison runs through what a development team costs, which is a different calculation with a different threshold.

The most expensive mistake: rebuilding everything instead of replacing the parts that hurt

This is where the article turns, and it is the part worth having read this far for.

The question almost everyone arrives with is "off the shelf or custom". It is the wrong question, because it assumes a single, permanent, company wide choice. It is not. The right question is: which processes deserve software you own, and which do not.

The answer, in the large majority of companies I have seen, is that two or three processes deserve software you own. Not thirty. The rest, accounting and invoicing and tax obligations first among them, should stay on the package, for the three reasons above: they start immediately, they cost little, and they update themselves when the law changes.

What it looks like in practice

The package stays the company's cash register: records, orders, invoices, accounting, basic stock. It keeps doing what it does well, and you keep paying the subscription you pay today, possibly with one module fewer.

Above and beside it, you build custom only the two processes that generate margin and that the package does not contain. In the example company: subcontracting management, which today lives in Excel, and the reporting that today arrives on Thursday. That is all.

The two parts talk to each other: customer records stay single, orders are created where they belong, and the new piece reads what it needs from the package instead of having it retyped.

Why it wins, in three numbers

It costs a fraction. The project sits in the entry band, twenty to forty thousand euros, rather than the upper band above ninety.

It takes months rather than years. Three or four months against the twelve or eighteen of a full replacement, and the difference is not only money: at three months the people who approved the project still remember it, while at eighteen half the assumptions have changed.

It throws nothing away. Accounting keeps working as it does today, tax updates keep arriving, and the project risk is confined to one area. If something goes wrong, it goes wrong on one process, not on the company.

The thing a supplier should not tell you

Recommending this route costs me ninety per cent of the contract value. A full replacement is worth six times what a targeted piece of work is worth, and every software company knows it. That is exactly why the advice you almost always receive is the full replacement: not out of dishonesty, but because it is the work the person proposing it knows how to do and wants to do.

I would rather lose the big contract and keep a client who trusts me. It is the same principle I apply when a company brings me software that is twenty years old: the answer is almost never to throw it away. In the Visual Basic 6 to .NET migrations I have run over the years, the biggest saving never came from the technology chosen. It came from deciding to modernise the software already there by replacing its parts one at a time instead of rebuilding from scratch. In those cases the bill changes by an order of magnitude.

How to combine package and custom without creating two truths

There is one serious objection to what I have just written, and it deserves an answer: if you put a custom piece next to the package, you risk ending up with two systems telling you different things. The risk is real, and it is the standard way these projects fail. You avoid it by respecting three rules, which are less technical than they sound.

First rule: one owner per piece of data

Every piece of information must have one single place where it is created and changed, and every other system reads it from there. The customer record is born in the package, the new piece reads it and does not duplicate it. The state of a subcontracted job is born in the custom piece, and the package reads it when it needs to invoice.

When this rule is not written down before work starts, what follows is predictable: six months later there are two slightly different customer lists and nobody knows which one is right. From there you do not get back without a clean up that costs as much as part of the project.

Second rule: the person working sees one place

Integration has not succeeded when two systems exchange data. It has succeeded when the person doing the work does not need to know there are two. If completing a task means opening two programs, remembering which one holds what, and copying a code from one to the other, you have moved the parallel spreadsheet, not removed it.

In practice that means the custom piece shows the package data that is relevant at that moment inside itself, and sends people back to the package only for the tasks that genuinely belong to the package.

Third rule: check before signing that the package lets itself be read

Not every package lets you read and write its own data from outside with the same ease. Some plan for it and document it, some allow it for a fee, and some make it awkward in a way that is not entirely accidental.

This is the first check to run, before even choosing what to build, and the question to put to the package vendor is blunt: can software of mine read and write my data, how, and at what cost. The answer is worth more than ten pages of quotation, because if it is negative the whole strategy changes: it means that package is not a component of your system, it is a cage, and the assessment you need to make becomes a different one.

Software as an asset: why owners are worth more when they sell the company

There is an argument no comparison site ever makes, and for a business owner it is worth more than all the technical ones combined: software you own is an asset, a subscription is a cost.

The difference is not philosophical. A process running on software the company owns is an asset: it sits on the balance sheet, it is amortised, and above all it gets examined in due diligence. The identical process running on a subscription is a recurring cost the buyer will have to keep paying, and it enters the valuation from the wrong side.

What a buyer looks at

Whoever is valuing a company to buy it, or taking a stake in it, looks at how much the company's functioning depends on specific individuals and how much of it lives in processes that stay. A company whose distinctive process sits in two people's heads and a spreadsheet is worth less than an identical company where the same process runs on software that is controlled, documented and transferable.

It is reasoning you rarely see in smaller Italian companies and that is entirely normal in any valuation done by an investor. I experienced it from the other side when I sold the product for law firms I had built: what was valued was not the technology used, it was the fact that a particular way of working sat inside the software and was therefore transferable to the buyer.

Exit cost, the other side of the same coin

There is a second, more immediate aspect. As long as your processes live inside a package, the cost of changing supplier grows every year. Not out of anyone's malice: because the data is there, the habits formed there, and the customisations you paid for are only worth anything there.

The day the subscription goes up twenty per cent, or the vendor is acquired and the product goes into maintenance, or a new version forces you to redo everything, your negotiating position is exactly that of somebody who cannot leave. Owning even just the two processes that matter changes that position, and it is a value that never enters the payback calculation but that you feel on the day of the negotiation. I have written a longer piece on software as an asset on the balance sheet, which is the natural follow up to this section.

When custom is the wrong choice

If you have read this far and convinced yourself that custom is for you, this section exists to pull you back in the cases where it is not. There are four, and I recognise them almost always inside the first half hour of a conversation.

The process you want to computerise is not stable yet. If the way you do a certain thing has changed three times in a year, or if you are about to change market, putting that process into software means setting in concrete something that is still moving. Stabilise the process first, even by hand, then build it. The reverse produces software that is born needing to be redone.

Nobody inside can follow the project. A custom project needs one internal person who knows the process, has the authority to decide, and can give it a few hours a week for its whole duration. This is not a technical role: it is whoever knows how things really work. If that person does not exist, or exists but is already saturated, the project will fail regardless of who builds it. It is the single most frequent cause of failure I know.

The problem is organisational and you are calling it a software problem. This happens more often than people think. Two departments do not talk to each other, and software is requested to make them talk. The software will be built, it will be delivered, and the two departments will carry on not talking using a new program. No tool fixes unassigned responsibility.

What you need already exists as a vertical for your industry. Before commissioning anything, it is always worth checking whether a package built for your trade exists. If it does and it is mature, it already contains ninety per cent of what you were about to have written from scratch, at a fraction of the price. The check costs two days of research and can save you forty thousand euros: it is the least profitable advice I can give and it remains the right one.

How to decide in a week, without calling five suppliers

Calling five suppliers as a first step is the fastest way to end up confused: you will receive five proposals describing different things, none comparable with the others, and you will choose based on who you liked most. What comes first is a picture taken in house. It takes a week and costs nothing.

The five questions, and who to ask

Ask the people who use the system every day, not their managers. Managers describe the process as it should be; the people working describe the process as it is. The gap between those two descriptions is, almost always, precisely the project.

1. What do you open in the morning besides the system? List every file, chat and notebook that comes out of this question, with the name of the person who keeps it.

2. How much time a day do you spend retyping or checking data the system already has? Ask for an estimate in minutes. Add it up across everyone and multiply by hourly cost and by two hundred and twenty days.

3. What do you ask the system to do that it cannot? Collect the answers unfiltered. Answers that repeat across people in different departments are the real priority list.

4. Which number do you need and have to ask somebody for? Every number that requires a request to another person is a number the system is failing to deliver.

5. If the system vanished tomorrow, what would you no longer be able to do? This is the question that reveals how much value is genuinely inside, and it exists to stop you discarding something that is working better than it seems.

How to read the result

Take the answers and put them in two columns. On the left everything to do with accounting, invoicing, tax obligations and basic records. On the right everything else.

If the left column is full and the right one nearly empty, you do not need new software: you need to use what you have better, or at most change package. If the right column is full, you are holding the list of candidates for custom work, ordered by how many times each item came up.

Then add up the minutes from question two, convert them to euros using the calculation from the threshold section, and add that to what you spend on subscriptions and modules. Now you have a number. Above thirty thousand a year, the conversation to have is about which two processes to bring in house. Below it, the conversation is about spending better what you already pay.

With those two sheets in hand you can finally call somebody, and the difference is enormous: you will no longer be asking "what does a management system cost", a question nobody can answer seriously, but "what does it cost to build these two processes and integrate them with what I have", which is a question with an answer. And if one of the processes that emerges could benefit from intelligent automation, it is worth understanding what changes with artificial intelligence in smaller companies before settling the final shape.

The point, briefly

The package is not the enemy and custom is not the answer. The package is perfectly good for everything your company does the way everybody else does, and that is where it should be left. Custom is for the two or three processes you do your own way, which are also the reason customers choose you, and which no package can ever contain by construction.

The thirty thousand euro threshold is the fastest way to know whether you can afford the change; the three signs are the fastest way to know whether you need it. The five questions are a week of work that makes any conversation afterwards useful, with me or with anybody else.

And if you keep one sentence from this article, keep this one: the right question is not what the system costs. It is what the work you do by hand costs you, because the system does not do it. That number, in most of the companies where I have calculated it, is larger than the subscription being argued over, and nobody had ever put it on a sheet of paper.