This is the question that every technology decision eventually comes down to: do we buy an existing SaaS product, or do we build something ourselves?

We build custom applications for a living — 500+ built over 23 years, including our own SaaS products. And we regularly tell prospective clients that they don't need a custom application. They need Zoho, or Salesforce, or a purpose-built SaaS tool that already exists and already does what they need.

When we say that, we lose the project. And it's still the right thing to say.

✦ Our honest position on this
We have a commercial interest in recommending custom development — it's what we build and sell. That means you should weigh our recommendation to build custom with appropriate scepticism. What we can offer that most custom dev agencies can't is this: we've also implemented Zoho for 1,000+ clients, built our own SaaS products, and seen the full lifecycle of both decisions across 23 years. When we recommend building custom, it's because the situation genuinely warrants it — not because we need the project.

Start with the honest case for SaaS

SaaS tools exist because most business problems aren't unique. CRM, accounting, project management, HR, customer support — these problems have been solved. Solved well, with teams of hundreds of engineers, with enterprise security, with integrations to everything, with support contracts and uptime guarantees. Solved in ways that a custom build for a single client cannot match on budget.

The case for SaaS is strong:

  • Immediate capability.

    A SaaS tool is live in days or weeks. A custom application takes months. The time value of getting a working system now vs in six months is real and often underestimated.

  • Ongoing improvement without ongoing cost.

    When Salesforce releases a new feature, you get it. When your custom application needs a new feature, you pay to build it. SaaS platforms improve continuously — your investment in the platform compounds.

  • Proven at scale.

    A SaaS tool handling 50,000 customers has been stress-tested in ways a custom build for 200 users hasn't. The edge cases, the performance bottlenecks, the security vulnerabilities — they've already been found and fixed.

  • Ecosystem integrations.

    Salesforce integrates with 4,000+ tools. Your custom CRM integrates with whatever you built integrations for. The ecosystem that surrounds a major SaaS platform has compounding value.

  • No maintenance burden.

    When a custom application is built, someone owns it forever — updates, bug fixes, security patches, compatibility with new operating systems and browsers. SaaS removes that burden entirely

    .
The most expensive custom application is one that replaced a SaaS tool that would have done the job — because you pay the build cost, the maintenance cost, and the opportunity cost, every year.

When SaaS genuinely doesn't work

The case for custom is real — but it requires honest scrutiny. Here are the situations where custom is genuinely the right answer, with the distinction between genuine and rationalised versions of each.

Your workflow is genuinely unique — not just different in preference
Rationalised version
"We work differently from other companies, so off-the-shelf won't fit." This is almost always untrue. Most companies claiming uniqueness are doing the same things as their competitors with different terminology.
Genuine version
Your workflow involves technical, regulatory, or operational constraints that no existing SaaS product accommodates — and adapting to the SaaS workflow would materially harm how your business operates.
The workflow is your competitive advantage
Rationalised version
"We've built our process around how we work and don't want to change it." That's preference, not competitive advantage. If a competitor using Salesforce would perform equally well, your CRM process isn't your moat.
Genuine version
Your operational process is the reason customers choose you over competitors — and that process depends on software doing something specific that no SaaS product does. PrintPlanr exists because print production workflow genuinely required custom software to support it well.
The data ownership or integration requirements are incompatible with SaaS
Rationalised version
"We want our data on our own servers." This preference exists for valid reasons, but most SaaS platforms offer data residency options. It's worth checking before building.
Genuine version
Regulatory requirements mandate data residency that no SaaS vendor can accommodate. Or the integration complexity between your existing systems and any SaaS tool is so high that the integration cost exceeds the build cost.
The scale creates unit economics that make SaaS prohibitively expensive
Rationalised version
"SaaS is expensive." At small scale, per-seat SaaS pricing is almost always cheaper than build cost + maintenance. The maths only changes at significant scale.
Genuine version
At your scale, the annual SaaS cost exceeds the amortised cost of a custom build within 3 years. This is genuinely true at enterprise scale — but requires an honest total cost of ownership calculation including maintenance.

The hidden costs of building custom that most people miss

🔧 Maintenance — forever
A custom application doesn't maintain itself. Security patches, browser compatibility, OS updates, dependency upgrades, bug fixes — someone pays for all of this, every year, indefinitely. Most build cost estimates don't include year 2, 3, and 4 maintenance.
📋 Features you assumed were included
SaaS tools come with audit logging, role-based access, SSO, mobile apps, API access, and reporting out of the box. In a custom build, every one of those is a feature you pay to build. The feature list grows during development.
🐌 Time to value
A custom build takes 3–9 months to deliver an MVP. During that time, your team is working with whatever they have now. The productivity gap between "what we have" and "what we're building" has a real cost that rarely appears in project budgets.
🔒 Key person dependency
If the team that built your custom application becomes unavailable, the software becomes a liability rather than an asset. We've rescued several of these situations — including Crystal Networks where the previous team was entirely unreachable. SaaS doesn't have this risk.
📈 Scaling complexity
When your business grows, a SaaS tool scales with it — that's what you're paying for. A custom application needs to be architected to scale, and then maintained and upgraded as it does. Scaling a bespoke system is often the most expensive development phase.
🌐 Integration lag
When a new tool becomes important to your stack — a new payment processor, a new accounting platform, a new AI capability — SaaS vendors typically build the integration. With custom software, you build every integration yourself, on your own timeline and budget.

The signals that custom is genuinely warranted

Signal What it means in practice
You've tried two or more SaaS tools and both required painful workarounds for core workflows If the workarounds are for peripheral features, adapt. If they're for the core of what you do — the thing you do every day — the tool probably genuinely doesn't fit.
The software is the product you sell If you're building a SaaS business — PrintPlanr, Quickzy, FieldPlanr — custom is the only path. You can't build a differentiated product on someone else's platform.
Your workflow requires integration between three or more systems that no single SaaS covers Sometimes the gap isn't that no SaaS does X — it's that no SaaS does X, Y, and Z together. When the integration cost between multiple SaaS tools exceeds the build cost of one system, custom may win.
Industry-specific requirements that generic SaaS doesn't accommodate ElementIQ exists because field service for companies managing 7-Eleven and Walmart accounts has operational complexity that generic field service SaaS doesn't handle. Domain depth creates genuine software gaps.
You're a large enough organisation that per-seat SaaS costs compound significantly At 200+ seats, the annual SaaS licensing cost for enterprise software starts to approach the amortised cost of a well-built custom system over 5 years. Run the full TCO calculation.
The process you're automating is the source of your competitive moat If the way you manage logistics, or service customers, or manufacture products is genuinely better than competitors — and the software is what enables it — custom protects that advantage. Shared SaaS platforms share capability equally.

From our own experience

✦ Real examples from 23 years — both directions
When we recommended SaaS and the client took it: A professional services firm came to us wanting a custom CRM. After a discovery session mapping their actual requirements, we recommended Zoho CRM with customisation. Zoho implementation at £12,000 vs custom build at £85,000+, delivered in 6 weeks vs 6 months, with the full Zoho ecosystem included. They're on Zoho today and growing.

When custom was genuinely right — PrintPlanr: We spotted the gap in print MIS software ourselves — desktop-bound, fragile, with no cloud alternative. The industry's workflow requirements are specific enough that a generic project management tool can't substitute. We built PrintPlanr. It's now top 10 globally. A SaaS alternative wasn't an option because the right one didn't exist.

When custom was right — ElementIQ: Field service management for a company whose clients are 7-Eleven, JC Penney, and Walmart. The workflow complexity — multi-client, multi-location, specific SLA requirements, inventory across distributed technicians — exceeded what any off-the-shelf field service SaaS handled correctly at the time. 20 years later, the client attributes their company's growth to the software.

When custom was right — Quickzy: No lending SaaS platform automated the specific bank verification and credit score API flow that Quickzy needed. The product differentiation depended entirely on the automation. Custom was the only path to the competitive advantage they needed.

The honest framework

Ask these questions in order. Stop when you have a clear answer.

  • Does a SaaS tool exist that does this well? If yes, and you haven't tried it seriously — try it seriously before budgeting a custom build.
  • Have you tried the leading SaaS options and found genuine gaps? Preference gaps don't count. Core workflow gaps — things you do every day that the SaaS can't accommodate — count.
  • Is the software the product, or the process the competitive moat? If yes to either — custom is the right answer.
  • Have you run the 5-year total cost of ownership including maintenance? Include: build cost, annual maintenance (typically 15–20% of build cost), feature additions, and compare against cumulative SaaS licensing.
  • Can your business absorb the time-to-value gap? 3–6 months to an MVP is real. If that gap causes material business harm, factor it in.

If you reach the end of this framework and custom is still the answer — it probably genuinely is. Build it with a team that will still be there in five years when it needs maintaining, with architecture designed to scale, and with the AI layer designed in from day one rather than bolted on later.

If SaaS emerged as the answer — and you want someone to implement it properly rather than just hand it to your team and hope — that's a conversation we have regularly too.

Not sure which direction is right for you?
Free consultation — we map your requirements, assess the SaaS landscape honestly, and give you a recommendation that isn't influenced by which path we'd rather sell you.
— Related Reading
Service
SaaS Product Development — When Building Is Right
Custom App
How to Scope an MVP Without Over-Building
Case Study
ElementIQ — When Custom Was Clearly Right