When you DON'T need custom software: 6 scenarios where an honest partner saves you money

The conversation happens several times a year, and it’s always awkward. An operations manager, with an approved budget, with three proposals on the table, with a vendor almost picked. They come to us for a technical second opinion. And our answer, after two discovery meetings, is that in their particular case hiring custom software would be throwing 40,000 EUR in the bin. That what they have only needs tweaks. That the real problem isn’t technological.

It’s an awkward post to write because it works against VisibleSoft’s pocket. We sell custom software. We live off it. But the right decision for the client is the right decision, and over the long run saying “no” to projects that don’t need us is what makes the same clients call us back two years later when they do. If after reading this post you decide that your case fits one of the 6 scenarios, it will have been worth writing even if you lose the conversation with us.

The 6 scenarios where custom software is the wrong call

1. The process is still changing every few months

If the way of doing things isn’t stable, systematising it in a custom app means paying twice: first to build, second to rebuild when the process changes again. It happens often in growing companies: sales changes the quoting flow every quarter as they learn what works, operations reorganises the warehouse twice a year, marketing changes the funnel every launch. Building custom software on shifting sand is buying technical debt from day one.

The clear signal: in the last 6 months you’ve changed the way that process is done more than 3 times. Substantial changes, not minor adjustments. While that frequency holds, iterate in Excel, in Notion, or in a cheap low-code tool. Hard systematisation comes later.

2. There’s a vertical SaaS for your sector that covers 90% of the case

This happens more often than the client suspects. For almost any sector there’s a vertical SaaS: dental clinics, auto repair shops, accounting firms, training academies, HVAC installers, law offices. We’re talking about products designed for your niche, proven across hundreds or thousands of companies like yours, costing 50 to 500 EUR per user per month.

Building from scratch something that 90% resembles what already exists is vanity. The right question isn’t “could it be built custom for me?”, but “what does that SaaS actually do, what does it miss for my case, and how much does it cost to cover that gap?”. Sometimes the answer is a custom module on top of the SaaS, or integration with a secondary system, or SaaS personalisation. Almost never is it throwing it all out and rebuilding.

We cover the decision in depth in Custom software vs SaaS: when to choose each, with the matrix we apply in discovery.

3. Volume doesn’t justify the investment

The honest ROI calculation is brutal in many small cases. A reasonable piece of custom software costs between 20,000 and 60,000 EUR for an SMB. For that investment to pay off, the problem it solves needs to free up at least 1,000-3,000 EUR per month in hours, errors, or lost income. If you’re saving 150 EUR per month, the system will take 15 years to pay back, and systems don’t last 15 years without reinvestment.

Typical cases where volume kills ROI: teams of 3-5 people with occasional processes, seasonal businesses where the system would only be used 4 months a year, companies considering a sale or shutdown in 2-3 years. In these scenarios, the rational stance is to accept that the current Excel with occasional pain costs less than a well-executed migration.

4. What you have works, it just needs tweaks

Sometimes the client arrives with “the system is obsolete” and, when we look at it, what’s there is a system that works well for 95% of the work, with two or three specific points that grate daily. In those cases, rebuilding everything from scratch is disproportionate. What’s needed is to intervene on those points: integrate the current system with a new tool, add a module on top without touching the core, automate the manual flow that sits between two systems.

The instinct of “since we’re at it let’s redo it all” costs 5-10 times more than fixing what hurts. And it rarely turns out as well as expected: the new system brings its own problems, which now have to be managed. We cover this in depth in Modernising a legacy ERP: when to migrate and when not to, where strategy 4 (extend instead of migrate) is often the right answer for more cases than is admitted.

5. The real problem is organisational, not software

This is the most delicate and also the most frequent. The client explains that they need a system to stop the team from skipping process steps. Or that they want a tool that forces sales reps to log calls. Or a dashboard that prevents managers from skipping reports.

No software solves that. If people don’t follow a process, it’s not because the tool is bad. It’s because the process isn’t clear, because no one verifies it, or because following it doesn’t add value to whoever has to follow it. Building a custom app to solve an organisational problem always ends the same way: the system goes live, people use it the first week, and two months later they’ve invented a thousand ways to skip it or fill it with junk data to comply.

Here what’s needed before software is reviewing the process with whoever executes it, understanding why it isn’t followed, and fixing the cause. Sometimes the solution is as silly as changing who verifies compliance, or removing steps that didn’t add real value. When it’s later systematised, what’s built fits how people work, not against how they work.

6. You want to “modernise” with no concrete problem behind it

The most expensive emotionally: approved budget, eagerness to modernise, trade press talking about digital transformation, competitors who seem to have made the leap. But when asked to define what problem the software will solve, there’s no clear answer beyond “be more efficient” or “stay current”.

Modernisation with no concrete pain behind it ends up as a project with no success metrics. You build it, you deliver it, and nobody can say if it worked. If you can’t quantify the problem before starting (in hours, in euros, in errors, in lost orders), you’re not in a moment to invest in custom software. You’re in a moment to audit your operation and find where it really hurts.

The 3-question test

When a client asks us for a second opinion before investing, the test we use to tell a problem software can solve from one it can’t is this one. If all three answers are yes, there’s a case. If any fail, it’s time to pause.

1. Can you describe the problem without mentioning technology? “It takes us 3 days to close monthly inventory because someone has to cross-reference 4 different files by hand” is a problem. “We need to modernise the ERP” isn’t. Describing it in business terms is the proof that you know what hurts.

2. Would it save measurable time or money if it were solved? Quantifiable, ideally in EUR per month or hours per month. “If solved, we’d recover 80 hours a month of Marisa’s time that could go to new accounts, worth around 2,500 EUR in salary and around 6,000 EUR in new account margin”. That’s a defensible ROI. “We’d be more efficient” isn’t.

3. Do the people who suffer the problem identify it the same way you do? Ask whoever is on the front line. If your definition of the problem matches theirs, you’re going the same way. If they disagree, there’s a disagreement that software won’t fix, and building it will only crystallise the signer’s version while ignoring the user’s.

The cheaper alternatives, in order of cost

Before jumping to custom software, this is the sensible order. Each step is cheaper than the next. Skip one only if you have evidence it doesn’t solve your case, not on instinct.

Level	What it is	Indicative cost	When it fits
1	Polish your current Excel (templates, validations, macros, documentation)	1,500-4,000 EUR	Almost always before any other option
2	Low-code / no-code (Airtable, Notion, AppSheet, Bubble)	3,000-12,000 EUR setup + 50-300 EUR/month	Process defined but still changing, small teams
3	Vertical SaaS for your sector	50-500 EUR per user/month	Standard sector process, no differentiation
4	Well-configured generic SaaS (HubSpot, Notion, monday.com)	50-300 EUR per user/month + setup	Cross-cutting processes (CRM, management, communication)
5	Personalisation of the SaaS you already have	5,000-25,000 EUR	A SaaS covers 80%, the 20% gap needs filling
6	Custom software	25,000-150,000 EUR	Real differentiation, deep integrations, strategic ownership

For more detail on when Excel still works vs when it’s time to migrate, we cover the specific Excel scenario here. And if you do reach level 6, before signing anything it’s worth reviewing how to evaluate the development partner.

And when it DOES make sense

So we don’t leave you hanging: there are cases where custom software is the right answer. The four clearest:

• Differential processes that are part of your competitiveness. If your way of doing something is what sets you apart, systematising it in a standard tool levels you with everyone else. Here custom pays.
• Deep integrations with legacy systems. When you need to read and write in real time on a 15-year-old ERP no SaaS knows how to handle.
• User volume that breaks the per-user model. From 100-150 users on, paying SaaS comes out more expensive than amortising custom over 3-4 years.
• Strategic need for code ownership. Regulated sectors, sensitive data, operations in countries where SaaS doesn’t operate, M&A decisions where owning the system matters.

The nuances between the two answers live in Custom software vs SaaS: when to choose each.

If your case fits one of the 6 scenarios

Save the money. No going back. Polishing what you have will make you more profitable this year than investing in a custom app that arrives in 4-6 months and solves a poorly defined problem. And if your case is different, or you’re in real doubt, let’s talk. In 30 minutes we usually know whether your case falls in one of the 6 scenarios from this post or whether it’s worth moving forward. We say the first too: it pays us more in the long run to say an honest no than to sign a project we shouldn’t have started.

Resources

• Custom software vs SaaS: when to choose each: the parallel decision when there is a case.
• Migrating from Excel to custom software: if scenario 1 doesn’t apply to you and Excel is the bottleneck.
• Modernising a legacy ERP: when to migrate and when not to: for the cases in scenario 4.
• How to choose a custom software development partner: if after all this you decide to go ahead, how not to get the hiring wrong.
• Book a free diagnostic