Planning the modernisation of a safety-critical SaaS product

How an advisory engagement took a long-established, safety-critical B2B SaaS product from a vague need to modernise to an evidence-led delivery plan.

---

Overview

The client builds safety-critical field operations software, a long-established B2B SaaS product used out on site every day. The front end is classic ASP.NET Web Forms, built for desktop browsers, and it works poorly on the phones and tablets people actually carry. The development team is small, and the people who know the system best are approaching retirement. Over the years, each customer has accumulated their own variation of the product.

The engagement started small, with onboarding onto the system and some customer configuration work, a couple of days a week. It widened almost immediately. Proof-of-concept work led to questions about infrastructure and resilience, then to what a responsive version of the app might look like. Within a month it had become a full product and technology strategy engagement, and it ran full-time for a few months after that.

The output is a delivery plan the business can act on. It sets out the case for change, the target state, the decisions made and still open, the risks, and a phased route from here to there.

Building the picture

The early work was learning the product, the business and the codebase well enough to give advice worth taking.

• Product walkthroughs and hands-on use, including the customer configuration work that started the engagement.
• AI agents analysing the two-decade-old codebase, mapping features and surfacing how things actually work.
• Calls and messages with the retiring developers, capturing the gotchas and history that lived only in their heads.
• A sprawling developer wiki, parsed, summarised and reorganised.

All of it landed in a markdown knowledge system, so every later analysis, prototype and plan draft could draw on the same context. The AI agents worked from that context too. Knowledge that was about to retire with the team became a durable asset.

Discovery also produced the real problem list, from resilience worries on a single shared server to manual deployments and testing, an awkward translation workflow and slow developer onboarding. The biggest item by far was the cost of per-customer configuration.

Product or platform

Years of saying yes to configuration requests had gradually turned the product into something closer to a platform. It was flexible and powerful, and increasingly expensive to run. Seeing that clearly was the turning point of the engagement. We compared the two models dimension by dimension.

Dimension	Product	Platform
Value proposition	Best-practice solution	Tailored solution
Customer choice	Opinionated	Highly configurable
User experience	Consistent	Variable
Implementation	Fast	Often lengthy
Upgrades	Straightforward	Complex
Testing	Small regression surface	Large regression surface
Support	Predictable	Customer-specific
Documentation	One set	Multiple variants
Development	Feature-focused	Framework-focused
Architecture	Simpler	More abstract
Technical debt	Lower	Higher
Maintenance cost	Lower	Higher
Release frequency	Faster	Slower
Deployment	Standard	Often bespoke
Scalability	High	Lower operational scalability
Onboarding	Easier	Requires product knowledge
Sales	Sell capabilities	Sell flexibility
Customer expectations	Fit the product	Product fits the customer
Competitive advantage	Domain expertise	Adaptability

Configurability had always been part of the sales story, so standardisation was an uncomfortable direction to consider. The comparison made the costs visible. Every variation adds implementation, testing, support and upgrade effort, and together they cap how many customers the team can serve. I’ve also over-invested in configurability on my own products, and know first-hand how those costs compound.

The direction that emerged was one standard baseline, owned by the product team, with a small, deliberate set of configuration points for genuine variation.

Proving the route with prototypes

Several of the plan’s big questions were settled by building rather than debating.

• A prototype of critical parts of the new UI running against the existing backend, testing authentication and performance. It worked, and it flagged the real challenge early. Business logic sits buried inside legacy page code, and the UI layer is tightly coupled to its data. That produced a firm rule for the rebuild. The new front end owns layout and styling, and the API returns pure data.
• Translation experiments comparing several LLM techniques, benchmarked against a golden dataset. The hard part was building context for each term so it translates correctly.
• A viewer for large schematics, with hotspots and entity overlays.
• A documentation tool that extracts every image from the existing Word manuals and uses an LLM, reading the surrounding text and the image itself, to propose labels and types, with a human validating each one.

Each prototype de-risked a decision before it was written into the plan.

The plan

The strategy work converged into a single delivery plan, built around a handful of commitments.

• A responsive single-page app, delivered as a progressive web app, backed by the existing .NET backend through a new API layer. The backend upgrade follows later, behind that API.
• The new system runs on its own database, on modern cloud infrastructure defined as code.
• An MVP release whose scope covers at least one user’s complete use case, so the first people to move do their whole job in the new app.
• One migration per customer. The standardised configuration and the new UI arrive together, so each customer absorbs a single change.
• Legacy runs business as usual during the build, with production deployments kept to a minimum, then moves into archive mode, where existing work finishes on the old system and anything new starts in the new one.
• A modern operating model from day one, with an automated delivery pipeline, infrastructure as code, database migrations, automated testing and static analysis.

Much of the plan’s value is in what it makes visible. Decisions are recorded with their context, options, rationale and consequences, and the decider named. Risks are scored before and after mitigation, with owners. Open decisions are listed just as plainly, including the ones that gate the critical path. Dates stay marked as placeholders until estimates exist to back them. A plan that admits what it doesn’t yet know is one a board can actually govern.

Where AI fitted

AI carried a large share of the analytical load. Agents walked the legacy source and catalogued 16 screens and 205 distinct UI actions, checking each against the existing API to size the gap between old and new. Prototypes came together in days. The knowledge system meant the agents worked from the same context as the humans, from the codebase to the reorganised wiki and the captured developer knowledge. Across discovery, analysis and prototyping, the saving amounts to months of effort.

The build phase is set up the same way, with an agentic development harness, guardrails, and humans reviewing everything until confidence is earned. The approach is tracked as a risk in its own right.

Outcome

Implementation starts shortly. The company goes into the build with a shared picture of where it is, an agreed destination, and a sequenced, de-risked route between the two. Value lands in front of users early, support effort converges on a single product, and the team’s capacity is no longer capped by per-customer variation. The general argument for staging modernisation this way is set out in Modernising legacy SaaS without a big-bang rewrite.

Delivery

I was responsible for the discovery and analysis, the proofs of concept, the product and technology strategy, and the delivery plan itself, working as an embedded independent advisor alongside the client’s domain experts. The engagement grew from a couple of days a week into the long-term shape described on the partnership page. For a long-standing product approaching the same decisions, that’s a sensible place to start.