Should You Rebuild Rented SaaS as a Custom Agentic System? A Decision Framework for CTOs and Heads of Product

Should You Rebuild Rented SaaS as a Custom Agentic System? A Decision Framework for CTOs and Heads of Product

Buyers are now being invited to stop renting software and build it instead. The pitch has a recognisable shape: replace a SaaS product with a custom agentic system, keep the intellectual property and the codebase, pay no recurring licence, and see working software within weeks. Some of that is attractive and some of it is a claim waiting to be tested. For a CTO or Head of Product, the useful question is not whether the pitch is persuasive. It is under what conditions a rebuild beats renting, and what evidence would show that a fast start proves anything. This article offers a framework for both, built on five dimensions: ownership, integration, run cost, control and governance.

What is being offered, and what is not yet evidenced

Our market intelligence shows that at least one provider has begun to market exactly this proposition. The offer invites buyers to rebuild rented SaaS as custom agentic systems, with the client keeping the IP and codebase and paying no recurring licence. It describes a funded first period, then outcome-based pricing, delivery from an onshore team and a small senior team. The provider also publishes percentage claims about time and cost saved. Those are self-reported, and we do not repeat them here.

We have not named the provider, and the framework below applies to any offer of this kind. Competitor positioning is useful as a prompt for buyers to ask better questions, and nothing in this article depends on any one vendor's claims being true or false.

There is a wider pattern behind the pitch, though it is thinner than the headlines suggest.

• Investors are funding modernisation that avoids replacement. A London-based company has reportedly raised £19.5m at a £195m valuation to help banks modernise without replacing their core systems, according to a Finextra report. We have read only the headline and standfirst, so treat it as a signal of investor appetite and nothing more.
• A US community bank has announced a core rebuild built around agents, according to Financial IT and FF News. We have seen the headline-level reporting only.
• UK banks are putting agents into regulated core operations. Starling has deployed an agentic financial-crime investigator inside its core and trains a transactional model on UK sovereign cloud, with data ownership and hosting as stated design principles. Its figure for how quickly the investigator works is Starling's own claim.

None of this says that custom beats rented. It says the option is being taken seriously, which is a reason to decide on evidence.

The decision is not rent or rebuild

Framing the choice as a binary is the first mistake. For most mid to large businesses, there are four realistic options for any given SaaS product:

1. Renew. Keep the product as it is. Appropriate for commodity functions where the vendor's roadmap serves you well enough.
2. Wrap. Keep the product as the system of record and add agentic capability around it through its interfaces. Appropriate where the data model is sound and the pain is in workflow.
3. Replace a module. Rebuild one function that is distinctive to you, and leave the rest.
4. Rebuild. Replace the product with a custom system.

The framework below helps you place each product on that ladder. Most will not need option four, and you should expect the outcome to differ product by product.

Dimension one: ownership

Ownership is the headline attraction, so test it carefully. "You keep the IP and the codebase" sounds clear and covers less than it appears to.

What to ask

• Which assets do you own at the end: the source code, the prompts and instructions, the evaluation sets, the data pipelines, the infrastructure accounts and the documentation?
• Which parts depend on third-party models, libraries or platforms whose licences you do not control?
• Can your own team, or a different supplier, maintain the system without the original builder?

What favours rebuilding: the function is part of your competitive advantage, you want to change it often, and you can staff or contract its maintenance.

What favours renting: the function is commodity, the vendor's cost is spread across many customers, and owning the code would mean inheriting work you have no reason to want.

Ownership transfers capability and also responsibility. A codebase you own is a codebase you must keep secure, patched and understood.

Dimension two: integration

Rented SaaS often sits at the centre of a web of connections: identity, data, finance, reporting and other tools. A rebuild must either reproduce those connections or replace them.

What to ask

• How many systems does the product exchange data with, and who owns each connection?
• What undocumented behaviour has accumulated, such as exports that another team depends on or rules baked into configuration?
• Can the new system run alongside the old one while you migrate, or does it require a cut-over?

What favours rebuilding: integration is already painful, the product forces workarounds, and a custom system would simplify the architecture.

What favours renting or wrapping: the product is deeply embedded and its edges are poorly understood. In that case, an agent layer that works through existing interfaces is often a lower-risk way to gain the benefit without taking on the migration.

Dimension three: run cost

"No recurring licence" is true and incomplete. A custom agentic system replaces a licence fee with other costs, and it is worth listing them before comparing totals.

What to ask

• What will inference cost at your expected volumes, and how does that change if usage grows? Vendors report falling unit costs for small and mid-tier models, which could change the economics of high-volume workloads, but those are vendor claims and you should model your own volumes.
• What are hosting, monitoring, evaluation and support costs once the funded period ends?
• Who pays for change: new features, model upgrades, security fixes and regulatory updates?
• How does outcome-based pricing work after the start, and who measures the outcome?

What favours rebuilding: your licence cost scales with seats or usage in a way that does not match the value you get, and your run costs are predictable.

What favours renting: your usage is low or unpredictable and the vendor's pricing absorbs that variability for you.

Compare total cost over a realistic period, including the people who will run the system. Do not compare a licence against a build price alone.

Dimension four: control

Control is the other attraction of owning, and it cuts both ways.

What to ask

• Which decisions do you want to control that you cannot control today: data model, roadmap, release timing, behaviour of the agent?
• What happens to your operations if the underlying model or platform changes behaviour? A system you own still depends on components you may not.
• Where does your data sit, and who can access it? The Starling example shows data ownership and hosting being treated as design principles for a regulated core, which is a useful prompt for your own requirements.

What favours rebuilding: you need behaviour that the vendor will not build, or you need to constrain where data goes.

What favours renting: you value the vendor's responsibility for uptime, security patching and compliance updates more than the flexibility to change the product.

Dimension five: governance

For a regulated or regulation-adjacent business, governance often decides the question, and it is the dimension most often skipped in a sales conversation.

What to ask

• Who is accountable for the agent's behaviour once it is yours? Rented software puts some of that burden on the vendor. A custom system puts it on you.
• What evidence do you hold for testing, change control and oversight? The FCA's 19 October speech set out good and poor practice for AI and, according to the reporting we use, signalled that existing frameworks such as Consumer Duty and senior-manager accountability apply. We have not read beyond that summary, and a regulated firm should take its own advice.
• Who can explain a decision the agent made to a customer, an auditor or a regulator?

What favours rebuilding: you can design controls into the system from the start and you have the team to operate them.

What favours renting or wrapping: the vendor already holds certifications and controls you would otherwise have to build and evidence yourself.

How to test a "working software in weeks" claim

A fast start is valuable if it is real, because it reduces the cost of finding out whether a rebuild is viable. It proves much less than it appears to. These tests separate a convincing demonstration from evidence that a rebuild will work. We treat any claim of speed as a claim, not a fact, until it passes them.

1. Define "working". Does it mean a demonstration with sample data, a pilot with real users or a production system handling live transactions? Ask for the definition in writing.
2. Check whose data and environment. Working software on clean data in a supplier's environment says little about working software on your data in yours.
3. List what is excluded. Security review, access control, audit logging, integrations, data migration, accessibility and resilience are the items most often deferred. Ask what is not in the first period.
4. Ask what comes after. If the first period is funded, what happens in the second? What is the price basis, and what would you owe if you stopped?
5. Probe the savings. Percentage claims about engineering time or delivery cost need a method and a comparable. Ask what was measured, against what and for whom.
6. Test the handover. Ask the provider to show how your team would run the system without them: documentation, tests, evaluation sets and a named route to support.
7. Ask for evidence, not references alone. Look for sourced case evidence that is relevant to your function, scale and regulatory position.

If a provider cannot answer these, the fast start may still be a useful, cheap experiment. Treat it as one, and do not read it as proof.

A short decision sequence

Put these together and a product-by-product sequence emerges.

• Start with the function, not the vendor. Is it distinctive to your business?
• If not distinctive, renew or wrap unless run cost or lock-in is a real problem.
• If distinctive, assess integration. Where the product is deeply embedded, wrap first.
• Model run cost over a realistic period, including people, inference and change.
• Decide who is accountable and what evidence you would hold, before you commit.
• Prove the case with a bounded experiment on a real workflow, with an agreed definition of success, before you replace anything.

What we do not know

The market evidence is thin. We have one provider's self-reported offer, one headline about investor funding and a small number of bank announcements. We have no independent measurement of how often rebuilds beat renting, how long they take or what they cost in the UK. Treat the framework as a structure for your own evidence, not as a verdict.

Where Innovify fits

Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We help mid to large businesses build AI-native products, modernise their technology stack and launch fintech products, and the decision in this article sits at the centre of that work. Our approach to AI and ML development starts from the function and the evidence, and recognises that renting, wrapping or replacing may each be the right answer for different products.

We design compliance in from day one, so governance questions are part of the design rather than a late review. Where a decision is still open, Innovify AI Labs lets enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding. That is the kind of bounded, evidence-first experiment this framework recommends before any SaaS is replaced.

Frequently asked questions

When should a business rebuild SaaS as a custom system?

Rebuild when the function is distinctive to your business, you want to change it often, you can own its maintenance and governance, and total run cost over a realistic period compares well with renting. For commodity functions, renewing or wrapping the existing product is usually lower risk.

Does owning the IP and codebase mean no ongoing cost?

No. Owning the code removes a licence fee, but you take on hosting, inference, monitoring, security, change and support costs. Model those over a realistic period, including the people who will run the system, before comparing the total with the licence you pay today.

What does "working software in weeks" prove?

On its own, very little. It shows that something can be built quickly, not that it handles your data, integrations, security and governance requirements at production scale. Ask how "working" is defined, what is excluded and what happens after the first period.

Is wrapping a SaaS product with an agent better than replacing it?

Often, yes, as a first step. An agent layer that works through the product's existing interfaces captures workflow benefits without taking on migration risk. Replacement makes sense once the case for owning that function is clear and tested.

Which governance questions matter most for a regulated firm?

Who is accountable for the agent's behaviour, what testing and change-control evidence you hold, and who can explain a decision to a customer or regulator. The FCA has said, according to reporting, that existing frameworks apply to AI, so involve your compliance advisers early.

Conclusion

Rebuilding rented SaaS as a custom agentic system can be the right decision for functions that are distinctive to your business and that you can own responsibly. It is rarely the right decision for every product, and a fast start is not evidence that it is. Weigh ownership, integration, run cost, control and governance for each product, treat speed and savings claims as claims until they pass the tests above, and prove the case with a bounded experiment on a real workflow before you replace anything.