Picture an accounting firm in Kuopio. The owner is at the desk, staring at the SaaS platform the business cannot operate without. Around it sits a heap of Excel files that someone on the team opens every morning, because they hold the logic the platform doesn't do. The owner knows that the other accounting firm across the street does the same work on the same platform, paying the same monthly fee.

Where does the difference between these two firms come from? Mostly from price. Going downward.

This is a short article about why I don't sell my partners off-the-shelf SaaS, even though there's more of it on offer than ever. And about why the answer in 2026 is different from what it was five years ago.

The problem nobody says out loud

When you buy off the shelf, you get what's on the shelf. There's a standard SaaS for accounting firms, law firms, architecture and engineering practices, logistics companies. Well built, modern interfaces, updates handled without any work from your team.

Your competitor uses the same standard SaaS.

Same software means the same processes. The same report templates. The same CRM structures. The same constraints. The same way to price, the same way to communicate, the same way to scale. If standard SaaS made you better than your competitor, your competitor would have switched away by now.

Excel fills the gaps. In every accounting firm, every law firm, every logistics company, there's that one spreadsheet someone opens every morning. That spreadsheet is the company's actual competitive edge, and it lives without backups, without version control, and without anyone whose job is to look after it. One retiring employee's brain.

The off-the-shelf vendor knows this. The sales rep knows you can't actually run your operation on the software alone. They invoice anyway.

What changed in five years

Five years ago, building your own application was a big-company option only. Estimates ran in the hundreds of thousands of euros. Year-long timeline, not months. Team, project manager, sprints, governance board, rollout plan. Completely out of reach for a small business.

AI-assisted coding broke that economics.

I'm not saying AI writes the logic for me. I still sit at the machine and solve the problems. But what took a week in 2021 takes a day today. The consequence: one person can deliver today what a ten-person team was needed for back then. And when a quote drops from tens of thousands of euros into the low thousands, the whole conversation changes.

The choice between standard SaaS and your own application is no longer an either-or where one is reachable and the other isn't. It's a question of whether to buy a ready-made answer to a standard problem, or to build your own answer to whatever is specifically yours.

What "your own" means in practice

You don't throw out the ERP. You don't throw out your accounting system. You don't throw out Office. Standard systems do what they were built to do: run the basic plumbing everyone else runs too.

On top of that, you build a thin custom layer. An application that sits on top of the existing systems, reads their data, writes back to them, and implements the logic that's specifically yours. The spreadsheet someone opens every morning, but as a proper application. Versioned. Backed up. Stored in more than one person's head.

This isn't a monolith. It's a one-problem solution that plugs into what's already there. Timelines measured in weeks, not months. The price a fraction of what a brand-new off-the-shelf product would cost in licenses over a five-year horizon.

Concrete: two numbers, two decades apart

2018. IBM quoted 150 hours for an email migration for a Finnish partner. Every sending system and printer would have had to be reconfigured. The alternative was one Postfix relay I built in 15 hours. No changes to any sending system, same outcome, 135 fewer billable hours for the partner. (Read the full story.)

2026. I'm currently building a custom logistics application for one partner, because no off-the-shelf product fits their delivery process. Their shipping workflow doesn't fit any vendor's mold. React, Vite, Supabase, one-person delivery. The application sits on top of accounting; it doesn't replace it. Timeline: weeks, not years.

Same logic in both: the standard route would have been the heavier path. Custom was lighter. In 2018, custom meant a cheap Postfix relay. In 2026, custom means an entire application.

Counter-arguments and their limits

This thesis has its limits. It would be dishonest not to name them.

Scale. If your application processes millions of transactions per second, building your own is still a much bigger commitment. In SMB territory, this isn't the problem being solved.

Regulation. If your industry is governed by national or EU-level obligations (NIS2, GDPR, accounting law, KYC requirements), a domain expert has to sit either with you or with whoever is building. Standard SaaS comes with the upside that compliance is tracked from outside. You don't get that for free when you build it yourself.

Optimization. If your problem is mathematically heavy (inventory routing, dispatch optimization across thousands of stops, large-scale forecasting), a standard product refined over decades is rarely a bad choice.

But these are exceptions, not the rule. Most of what an SMB actually does day to day is simpler than what standard SaaS was built around. Simpler and more specific. That's exactly why Excel is so common.

Last word

I don't resell anything and I don't represent any software vendor. I recommend what actually works. Sometimes that's standard SaaS. Sometimes it's a custom layer on top. Sometimes it's a very boring Postfix relay. Depends on what's in front of you.

But if you ask me in 2026, the answer more and more often is: build your own. Not because it's cool. Because it became more cost-effective.

Is your operation one where Excel fills the gaps SaaS can't reach? You can explore that at no cost. Either through an Automation Kickstart assessment (2–3 hours, walking through what's not flowing in your day-to-day) or a PoC (I build a small working trial — you only pay if we move to full implementation). An independent take on whether a custom layer is worth it, before a single line of code is written.