When to Replace SaaS with Custom Software: A CTO's Decision Framework

Why do you need a framework?

The hardest part of replacing software-as-a-service (SaaS) with custom software is not the build. It is deciding which tools to replace in the first place.

Without a structured approach, the decision devolves into gut feel, vendor loyalty, or whoever argues loudest in the leadership meeting. One team insists the CRM is broken. Another team defends it because they have invested years in customising it. Neither side has data.

This guide gives you a repeatable scorecard. Apply it to any SaaS tool in your stack, and you get a clear signal: replace, evaluate further, or keep. The framework does not make the decision for you, but it ensures the decision is grounded in evidence rather than opinion.

For the broader strategic context, including the economics and legal boundaries of SaaS replacement, see the full SaaS replacement playbook.

What are the six criteria?

Score each SaaS tool against six criteria. For each, assign a colour: green (no action needed), amber (worth monitoring), or red (replacement signal). The criteria cover both tangible costs and strategic risks.

1. Feature utilisation

How much of the platform does your team actually use?

• Red (below 30%). You are paying for a broad platform and using a narrow slice. This is the single strongest signal that a custom build could deliver the same value at lower cost. Most mid-market SaaS subscriptions fall into this category.
• Amber (30-70%). You use a meaningful portion but still carry dead weight. Monitor costs, but this alone does not justify replacement.
• Green (above 70%). The vendor’s economies of scale are working in your favour. Keep the SaaS unless other criteria score red.

Feature utilisation is harder to measure than it sounds. Do not rely on the vendor’s usage dashboard, which typically measures logins, not feature engagement. Instead, survey your team. Ask which features they use weekly, which they use monthly, and which they have never touched.

2. Integration pain

How much effort does it take to keep this tool connected to your other systems?

• Red (chronic sync failures). You maintain custom middleware, manual exports, or spreadsheet workarounds. Data discrepancies between systems cause support tickets, reporting errors, or duplicated effort. Your team spends hours each week on integration maintenance.
• Amber (occasional issues). Integrations mostly work but require periodic attention. API changes from the vendor occasionally break connections.
• Green (seamless). The tool integrates cleanly via standard APIs or native connectors. No ongoing maintenance required.

Integration pain compounds over time. A tool that requires two hours of manual data reconciliation per week costs over 100 hours per year, before accounting for the errors that slip through.

3. Compliance gaps

Does the tool meet your regulatory obligations, or do you work around them?

• Red (regulatory workarounds required). The tool’s data residency, access controls, audit logging, or retention policies do not satisfy your compliance requirements. You have built manual processes to compensate, or you accept residual risk.
• Amber (minor gaps). The tool mostly meets requirements but lacks specific controls that your compliance team has flagged. Workarounds are manageable.
• Green (fully compliant). The tool meets all regulatory requirements without workarounds.

Compliance gaps carry risk beyond operational cost. If an audit reveals that your workaround failed, the consequences are not measured in developer hours. For organisations in regulated sectors (financial services, healthcare, education), this criterion often carries disproportionate weight.

4. Workflow fit

Does the tool fit your process, or does your team adapt their process to fit the tool?

• Red (team adapts to the tool). Your team has changed how they work to accommodate the software’s limitations. Steps are added, skipped, or performed in a different order because the tool requires it. New starters are told “we do it this way because that is how the system works.”
• Amber (some compromises). The tool handles most workflows well but forces compromises in specific areas.
• Green (tool fits the process). The tool supports your team’s natural workflow without significant adaptation.

Workflow compromises are invisible in most cost analyses. They show up as lower productivity, longer onboarding times, and accumulated frustration that erodes team morale.

5. Cost trajectory

Is the tool getting more expensive faster than the value it delivers?

• Red (costs rising faster than value). Per-seat pricing scales with headcount. Per-contact pricing scales with database size. Annual renewals include above-inflation increases. You are paying more each year for the same (or diminishing) value.
• Amber (stable). Costs are predictable and in line with the value delivered.
• Green (decreasing per-unit cost). The vendor’s pricing model rewards growth, or you have negotiated volume discounts that keep per-unit costs flat or declining.

Cost trajectory matters more than current cost. A tool that costs £500 per month today but grows at 15% per year will cost over £1,000 per month within five years. Custom software has a fixed build cost and predictable hosting fees.

6. Strategic importance

Is this tool core to your competitive advantage, or is it a supporting function?

• Red (core to competitive advantage). The tool supports a workflow that differentiates your business. You need full control over the roadmap, the data model, and the integration points. Depending on a third-party vendor for a core capability is a strategic risk.
• Amber (supporting function). The tool supports important but non-differentiating work. Control is desirable but not critical.
• Green (commodity). The tool handles a generic function (email, calendaring, document storage) that does not differentiate your business. Keep the SaaS.

Strategic importance is the criterion that most often surprises CTOs. A CRM might seem like a commodity, but if your sales process is a competitive differentiator, the CRM is strategic. An HR system might seem strategic, but if your HR processes are standard, it is a commodity.

How does the scorecard work in practice?

A framework is only useful if you can apply it. Here is a worked example using HubSpot, the most common SaaS replacement candidate we see.

Worked example: scoring HubSpot for a mid-market company

Consider a 50-person company using HubSpot Sales Professional. They signed up for deal tracking and contact management. Over two years, they accumulated marketing hub features they do not use and per-contact pricing that scales with their growing database.

Feature utilisation: Red. The team uses deals, contacts, and email sequences. They have never configured the marketing automation, the service hub, or the CMS. Estimated utilisation is 15-20% of the platform.

Integration pain: Red. A custom middleware layer syncs HubSpot data with the company’s core platform. The sync breaks roughly once a month, requiring manual data reconciliation. Two developers spend approximately four hours per week on integration maintenance.

Compliance gaps: Amber. Data residency is acceptable (EU hosting available), but audit logging does not meet the company’s internal governance requirements. A manual export process compensates.

Workflow fit: Red. The sales team has adapted their process to match HubSpot’s deal stages rather than their actual sales process. New starters are trained on “how HubSpot works” rather than “how we sell.”

Cost trajectory: Red. Per-contact pricing means costs have increased 40% over two years as the database has grown. The next tier upgrade would add features nobody has requested.

Strategic importance: Amber. The sales process is important but not a core differentiator. The company competes on product quality, not sales methodology.

The verdict

Four criteria score red, one scores amber, and one scores amber. The scorecard says: evaluate for replacement. Because strategic importance is amber (not red), the replacement is driven by clear ROI rather than strategic control.

This is exactly the profile described in our detailed walkthrough of replacing HubSpot with a custom AI-built CRM.

What does “replace” actually mean?

Replace does not mean rebuilding the entire SaaS product. That would be expensive, slow, and pointless. The whole reason for replacing is that you use a fraction of the platform.

Replacement means three things:

• Build the 20% of workflows you use. A HubSpot replacement might cover deals, contacts, and email sequences. A BambooHR replacement might cover employee records, leave requests, and onboarding checklists. Nothing more.
• Integrate specialist APIs for commodity capabilities. Email delivery through Postmark. Payment processing through Stripe. Document generation through a specialist API. Do not rebuild infrastructure that already exists as a focused, affordable service.
• Design for your specific data model and compliance requirements. This is where custom software earns its cost. The data model matches your business, not a generic platform’s assumptions. Compliance controls are built in, not bolted on.

The scope discipline is the hardest part of any replacement project. The temptation to add “one more feature” is constant. Resist it. Build what your team uses weekly. Everything else is scope creep.

For a deeper treatment of the feature utilisation gap and why most organisations use far less than they pay for, see The SaaS 20% Problem.

Why should you replace one tool at a time?

The scorecard might reveal three or four tools that score poorly. The temptation is to replace them all at once. Do not do this.

Start with the worst-scoring tool

Pick the tool with the most red scores and the clearest return on investment (ROI) case. This is your first replacement project. It should be the tool where the pain is most visible, the costs are easiest to quantify, and the scope is most contained.

Build confidence

A successful first project does more than replace one tool. It builds organisational confidence in the approach. Stakeholders see that custom software can be delivered quickly, that the transition can be managed without disruption, and that the resulting system genuinely fits better.

This confidence is the prerequisite for the second project. Without it, every subsequent replacement faces the same internal resistance.

Refine the approach

Every replacement project teaches you something. The first project reveals how your team handles data migration, parallel running, and change management. Apply those lessons to the next project.

Then evaluate the next candidate

Once the first replacement is stable, return to the scorecard. Re-score the remaining tools. Some scores may have changed: perhaps an integration pain point was reduced because the first replacement removed a dependency. Evaluate honestly and pick the next candidate on its merits.

For a detailed migration plan covering workstream breakdowns, parallel running, and cutover checklists, see the SaaS to custom software migration guide.

What about the legal side?

Replacing SaaS functionality is legal in almost all cases. UK copyright law protects how software is written (the code), not what it does (the functionality). Two landmark cases confirm this: Navitaire v easyJet (2004) and SAS Institute v World Programming Ltd (2013).

The practical safeguards are clean-room implementation and terms of service review. For the full legal analysis, including data portability rights and intellectual property (IP) considerations for AI-generated code, see our legal guide to replacing SaaS with custom software.

For IP questions specific to AI-assisted development, see who owns AI-written code.

Book a free SaaS replacement assessment

We offer a free 30-minute SaaS replacement assessment. Bring a SaaS tool you are questioning, and we will apply the scorecard together. You will leave with a clear signal: replace, evaluate further, or keep.

No pitch, no obligation. If SaaS is the right answer, we will tell you.

Book a consultation