How AI Consultants Scope an In-House SaaS Replacement

Any consultant worth their day rate scopes an in-house SaaS replacement the same way: split each tool into the parts you can see and the parts that must be correct every time. SaaS (software you rent by the month) is mostly screens, workflows, and reports sitting on a smaller core of record-keeping. AI has made the first half cheap to rebuild. The second half is where replacement projects die, and a good scope exists to measure how much of your subscription bill actually lives there.

Here is how an in-house SaaS replacement scope comes together, step by step, and the one question that decides most of it. (Vendor names and survey figures below are accurate as of publication; treat the specifics as a snapshot.)

What does a SaaS replacement scope actually contain?

A jobs inventory, not a feature list. The consultant lists every job the tool performs, who touches each one, and what happens when its output is wrong. Approval chains, dashboards, and forms go in one column. Money movement, stock counts, tax, and employee records go in another. The deliverable is that map, a risk grade per job, and a list of every system the tool is quietly wired into.

The grading question is the whole game: if this output were wrong, how would you find out, and what would it cost? A stale dashboard gets caught at a glance and costs nothing. A wrong payout total gets caught at tax time and costs real money.

Why split the product into two layers?

Because AI collapsed the cost of one layer and left the other alone. The interface layer (forms, dashboards, internal tools, approval workflows) is now fast to rebuild; current models generate working web apps in hours, which is exactly what we found when we asked whether GPT-5.6 could build a working POS. The infrastructure layer is different: payment processing, PCI compliance (the card-security rules processors enforce), inventory under concurrency (two tills selling the same last unit), and reports that reconcile (totals that match your bank deposit). That layer is not hard because the code is long. It is hard because almost right is worth nothing there, and proving correctness costs more than generating the code.

Better models do not remove that constraint, either. The bottleneck is verification and liability, not code generation, so an honest scope prices the verification. Generation is the demo. Verification is the invoice.

What did Klarna's SaaS replacement actually prove?

The loudest "we replaced our SaaS with AI" story is really a scoping lesson. In late 2024, Klarna's CEO announced the company was dropping Salesforce and Workday as part of an AI overhaul, and headlines reported that AI was replacing SaaS outright. Follow-up reporting found something narrower: Klarna moved HR to another vendor and covered its CRM needs with a mix of alternative tools and in-house glue, with AI layered on top¹. A licensed bank running one of the most aggressive AI programs in fintech still kept its systems of record (the authoritative copy of your business data) on proven platforms and rebuilt around the edges.

That was not a failure of nerve. That was the scope working.

Which numbers justify a replacement project?

Waste first, build second. Zylo's 2026 SaaS Management Index, drawn from more than 40 million licenses under management, puts median SaaS spend at $9,455 per employee per year, finds an average of 36% of licenses sitting unused, and shows business units controlling 81% of SaaS spend while IT directly manages 15%². A consultant ranks your stack against those numbers before proposing anything: cancel the unused seats, consolidate the overlapping tools, and only then shortlist rebuild candidates.

The tools that make the shortlist share a profile: high recurring cost, jobs that live mostly in the interface layer, and a small blast radius when something breaks. The project gets approved when the subscription line grows faster than the cost to build and maintain, and every must-be-correct job can stay on infrastructure someone else already operates.

Where does a POS land in this scoping?

At the unforgiving end of the spectrum. A point of sale looks like an interface project, a grid of buttons and a cart, so owners assume it scopes like a dashboard. The ratio is inverted. The checkout screen is a small slice of the product; the rest is payments, certified card-present hardware, inventory that survives two registers selling at once, tax rules, and end-of-day reports that reconcile. When a POS is wrong, it is wrong about money, daily.

So consultants scope a POS rebuild the way Klarna scoped its ledger: custom interface, proven infrastructure. That split used to require a dev team. It is now a product category: Final's Build turns a plain-language prompt into a checkout flow you can preview and deploy, and you can connect your own AI over MCP to build against the same commerce infrastructure. The payments, inventory, reporting, and hardware stay on the layer that is already verified.

So how should you scope an in-house SaaS replacement?

Split every tool into its two layers, grade each job by the cost of an undetected wrong output, and price the verification rather than the code. Rebuild interfaces and workflows freely; leave systems of record on infrastructure that someone else keeps correct. Before you rebuild any tool in-house, ask: if its output were wrong, how fast would I know? If the answer is "not fast," that job stays on proven rails.

And if the commerce end of your stack is the part you want to rebuild, start with an honest look at what today's models can and cannot build on their own: Claude vs ChatGPT vs Gemini on a real POS build, or the two no-code routes in how to use Gemini 3.6 Flash to build a custom POS.