Patryk Korzeniowski
Every business reaches this point
There comes a moment in every company’s life when the number of tools in use crosses a reasonable limit. CRM here, invoicing there, a Google Sheet to bridge data between the two, another system for order management, and email for client communication.
And suddenly you realise your team is spending an hour a day manually copying data between applications. Or that you have no single place to see what’s happening across the business. Or that every new hire needs a week just to understand how everything fits together.
At that point the question arises: buy another SaaS tool? Or build something of your own?
The answer isn’t straightforward. And anyone who says otherwise is either selling something or hasn’t understood the problem.
When SaaS is the right choice
Before we get to custom systems, let me be honest: in most cases, SaaS is the right decision.
Why?
Ready-made software is tested, developed by large teams, and often comes with support, integrations, and documentation. You pay a monthly subscription and can get started immediately.
When SaaS works well:
- Your process is standard and similar to how thousands of other businesses operate
- You don’t need deep integration with other systems
- The scale of your operations doesn’t justify building something bespoke
- You want to move fast and test your assumptions
Example: a clinic starting to use an online appointment booking system. If a standard calendar tool meets the need — use it. There’s no reason to build your own.
When SaaS starts to become the problem
SaaS becomes a constraint in specific situations. And usually, a company feels it before it can name it.
Warning signs:
Manual data copying. If your team regularly copies data from one system to another — that is a cost. Real, measurable, and often invisible in the budget.
Paying for what you don’t use. You buy a SaaS plan because you need three features. The rest you ignore. But you pay for everything — and get an interface designed for someone else.
The tool doesn’t fit your process. You start working around the system’s limitations. You create workarounds. You have extra spreadsheets. That’s a sign the tool doesn’t match your reality.
No integration. A system that doesn’t talk to other systems is an island. And islands generate information chaos.
Data is everywhere and nowhere. You have no single view of the business. You need to collect data from five sources just to answer one question.
Examples where a custom system or automation makes sense
I’m not talking about large projects costing hundreds of thousands. I’m talking about concrete solutions to concrete problems.
Example 1: A service company with manual job management
A company handles several dozen jobs per month. Each job involves: intake, quote, contract, delivery, invoice, settlement. Everything runs through Excel and email.
The concrete problem: 3 hours per week on manually creating documents and quotes. Errors from retyping data. No visibility into which stage each job is at.
The solution: a simple job management panel with automatic document generation and status views. No bells and whistles. No ERP. One screen that replaces 5 files.
Example 2: E-commerce and warehouse integration
An online store uses an e-commerce platform, a warehouse management system, and a separate invoicing tool. Data doesn’t flow between them automatically.
The concrete problem: a staff member manually updates stock levels and issues invoices. One hour a day, five days a week.
The solution: integration between the three systems (via API or n8n). Data flows automatically. The staff member does other things.
Example 3: A clinic and patient management
A clinic has a booking system but no automatic reminders, no single view of patient history, and must manually generate monthly reports.
The solution: automated reminders (SMS/email), a simple dashboard with key data, and a report generator. Not a new system from scratch — an extension of what’s already working.
Costs and risks — straight talk
Building a custom system is an investment. And like any investment, it may or may not pay off.
What can go wrong:
- Wrong scope. You commission too much at once. The system grows, costs grow, deadlines slip.
- Wrong partner. Someone promises a lot, delivers little. The code exists but nobody knows how to maintain it.
- Unvalidated assumptions. You build a system for a process that actually needs an organisational change, not a technical tool.
- Maintenance. A custom system requires upkeep. Someone must update it, handle bugs, develop it further.
What helps minimise risk:
- Start with a small scope
- Choose a partner who asks business questions, not just technical ones
- Plan for maintenance before the project starts
- Measure results after deployment
MVP — don’t build everything at once
The most common mistake I see: a company wants to build a system that handles everything. Jobs, invoices, CRM, reports, integrations, a mobile app.
A year later they have half the features, a budget twice over, and a system that only works in theory.
The mature approach looks different:
Step 1: Identify one bottleneck. Where is the company losing the most time or money? One specific process.
Step 2: Build the minimum viable solution. Not everything. Just enough to stop that one problem from being a problem.
Step 3: Evaluate the results. How much time did you save? Is the team actually using the system? Did the problem really go away?
Step 4: Develop further, if you see results. Only then.
This isn’t a compromise. It’s simply a smart approach to technology investment.
A practical decision checklist
If you’re wondering whether it’s time for a custom system or automation — answer these questions:
- Does your team regularly copy data between systems?
- Are you paying for SaaS features you don’t use?
- Do you have processes that run mainly through email or spreadsheets?
- Do you lack a single place to see the state of the business?
- Does onboarding new employees take a long time because the process isn’t standardised?
- Are errors occurring as a result of manual work?
- Are you using more than five tools to manage one process?
If you answered yes to three or more — it’s worth having a conversation about what can be changed.
Summary
A custom system or automation isn’t the answer to every problem. But in many companies, it is the answer to specific, measurable operational costs.
The key is the approach: understand the problem first, then look for a solution. Not the other way around.
And rather than building a large system straight away — start with something small that you can test in practice.
If these questions resonate with your situation, we’d be happy to talk. No commitment, no pitch at the first meeting. Just a conversation about what’s working and what isn’t.
