With 50 to 250 employees, an organisation sits in an awkward middle ground. You have outgrown the standalone packages you started with: every department now has its own tool, and someone bridges the gaps with Excel and manual re-typing. For heavyweight enterprise systems you are too small. The implementation alone costs more time and money than you want to spend.
You see the result on the work floor. Your team’s week is full of work nobody ever intended: retyping orders from emails, pasting figures from three systems into a spreadsheet every Monday, keeping a separate list because the package cannot hold certain information. This is the middle ground where custom software pays off. Not because bespoke development would not work elsewhere, but because the ratio between investment and effect is strikingly favourable at this size. Here is why.
Large enough to repeat, small enough to decide fast
The quiet advantage of a mid-sized company is scale without sluggishness. A clunky process that is merely irritating at eight employees repeats hundreds of times a week at a hundred and twenty. Every minute a custom application takes out of that process therefore counts heavily.
At the same time, decision lines are short. The owner or operations manager who signs off the investment knows the work floor and sits at the table themselves. No steering committee is needed to establish which process hurts most. That keeps a custom project sharp: it targets the work that matters, not the wish list of everyone who got a say.
Where your team’s time actually goes
Off-the-shelf software is built for the average company. A mid-sized company has usually grown with its own way of working, and that is exactly the part a package does not recognise. The gap between how the package wants to work and how your team works is bridged with workarounds: exports, intermediate files, double entry, checking rounds. Those hours appear on no budget, yet they are paid every week.
The tricky part is that such detours become invisible: after a few months nobody mentions them, because they have become part of the job. The signs are recognisable, though:
- ‘the system can’t do that’ has become an everyday sentence on the team
- the same data is kept up to date by hand in more than one system
- reports require cutting and pasting from different sources every week
- you pay licences for modules and users that barely touch them
- the number of people or transactions keeps growing, and the manual work grows with it
Each sign is manageable on its own. Together they form a cost that grows with the organisation and never shows up as a separate line anywhere. We wrote earlier about what goes wrong when this situation persists, in what happens when your systems don’t communicate with each other.
Work out what the manual work is costing you now
The case for custom software does not start with what it delivers, but with what the current way of working costs. You can do that sum yourself, without a quote. Say four people in your back office each spend five hours a week moving orders from one system to another. That is twenty hours a week, well over nine hundred hours a year. Multiply those hours by what a working hour costs your organisation and you have the annual price of that one process. The errors that come with re-typing and the work left undone are not even in that figure yet; how to include them is explained in what manual data copying between systems costs.
Set that figure against the investment in software that takes over the work, and you have a fair basis for a decision. Such an application also lasts for years, so the saving counts every year. Often one visible process is enough to tip the balance, and there are usually more.
Start with a task, not a system
Custom software rarely means rebuilding your entire system landscape. Your accounting package does its job fine; you do not replace it, you connect it. The biggest gain usually sits in the one task that comes back every day. Think of a planner who copies incoming jobs from email into the planning system: reading, retyping, checking, confirming. An internal tool that reads that message and prepares the job turns the chore into a check of a few seconds. The task does not disappear, the manual work does.
The same applies to reporting. Where someone merges figures from different sources every week, an integration can do that continuously, so the overview is always there instead of only on Monday afternoon. That keeps the investment limited to the process that demonstrably costs money.
Fewer errors is the quieter win
Time savings are visible, but the drop in errors counts at least as much. Every manual handover is a chance for a mistyped figure or a missed line, and such a mistake costs more than the correction alone. Software that follows your process validates data at the source and removes the handover itself, so that chain never starts.
On top of that, everyone works from the same up-to-date data. The argument about which version of the overview is correct disappears, and with it a good deal of friction in the team.
When custom software is not the right choice
Custom development is not a goal in itself. If an off-the-shelf package covers your process almost entirely, that is usually the faster and cheaper choice. If it is a few minutes of manual work a month, leave it be. The investment starts to pay off once you recognise several of the signs above at once and manual work has become a fixed part of someone’s week.
In that case, record beforehand what you expect: how long a process takes now and how often work has to be redone. Without that baseline you cannot prove afterwards what the software delivered. How to do that is explained in how to measure whether your custom software pays for itself.
So start not with the biggest system but with the process your team complains about most. That is almost always the process where the sum comes out strongest. Is the figure one you do not want to leave on the table? The page on custom applications explains what we develop for organisations that have outgrown their packages. If you are unsure whether your process qualifies, we would rather have that conversation around that one task than around a quotation.