What AI changes about delivering production software in complex and regulated domains

The Law Centres Network is a small charity coordinating centres which provide legal aid work across England and Wales. Their messaging platform was eight years old, running on unsupported technologies, and failing a security audit with some enthusiasm. The replacement is a multi-tenant SaaS with full GDPR tooling and a complete redesign. It took around twenty days. A scope of work that would normally take several months.

AI handled a significant share of the planning and implementation. A human who's shipped this kind of thing before defined the specification, made every architectural decision, and reviewed everything that mattered. The platform is the easy part to describe; the product lifecycle behind it is worth exploring.

Declarative vs imperative gap

That product lifecycle lives or dies in the prompt, and most prompts fail in the same way, by declaratively asking "Build me a secure messaging platform for communication between legal aid clients and law centres." That works for demos. It produces something that looks plausible in a screenshot and falls apart the moment real people try to use it with real data, on a real network, under real compliance pressure.

A more useful approach is to prompt imperatively. "Build a multi-tenant SMS platform where centres are isolated by row-level scoping, contacts have soft-delete with cascading retention policies, broadcasts go through a queued delivery worker with per-message Twilio status tracking, and every authentication event lands in an immutable audit log."

The second approach means the AI is not guessing at every decision: it is implementing a specification. The person directing it needs to know which edge cases exist before they bite, which compliance requirements apply, and how to constrain the problem so the AI delivers to a spec rather than improvising.

What a product lifecycle looks like with AI

A lot of what we see from AI evangelists are greenfield projects, not those rooted in the reality of existing systems and politics.

As shiny as those demos are, where AI can really accelerate the process is in helping navigate the complexity of existing systems. In this case, the existing technology was eight years old, running on technologies that were no longer supported. A security audit surfaced sixteen known CVEs and five end-of-life packages. Rolling out the platform across the wider Law Centres Network was blocked: GDPR-required tooling for retention, deletion, and Subject Access Requests didn't exist.

The Network is a small charity. No internal engineering team, limited budget, and a full caseload of legal aid work to keep moving while any modernisation happened in the background.

Phase 1: Generate Proposals

The first phase used AI to compress what's normally weeks of discovery and synthesis into a few days, with client-ready artefacts at every step.

Research synthesis with Claude

Conversations with LCN staff and centre users were transcribed, summarised, and clustered with Claude. Themes, priority rankings, and a list of features actually used in anger came out the other side. Equally useful was the list of features nobody used, which fed directly into scope reduction.

Concept design in v0.dev

This was a total redesign of the product, not a re-skin. On a traditional engagement, the budget would have forced a like-for-like rebuild and pushed any real design work to a future phase that rarely arrives. But with implementation time compressed by AI, more of the engagement could go into discovery and design, where the real product decisions get made.

A working messaging UI prototype came out of v0.dev in hours. Something the client could click through and react to before any planning began. Early feedback shaped the product plan rather than the other way around.

Security audit, combining industry-standard tools with AI analysis

The legacy Gemfile, dependency tree, and Ruby and Rails versions went into Claude alongside current advisory data. The output was a full vulnerability and lifecycle audit: sixteen CVEs across high, medium, and low severity, five end-of-life components, with patched versions and severity scores along with actions for each. The audit was the basis for the security section of the proposal, and the CVE data fed directly into the project backlog as tickets to update or replace vulnerable dependencies.

Shaping multiple proposals in conversation with AI

The research, audit findings, and concept work all went into a working session with Claude, which shaped the expected proposal: patch the existing app, address the compliance gaps, and establish ongoing maintenance.

What the conversation also produced was a fifth option nobody had asked for: a complete rebuild on simpler, modern infrastructure, with no Redis, no Sidekiq, and no WebSockets. By any traditional measure, it was scope creep of the worst kind. But with delivery compressed by AI, a full rebuild came in only fractionally more expensive than patching the existing app, with a multi-year runway, lower hosting costs, and a stack a small charity can actually maintain. Both SOWs went to the client side by side. The rebuild won.

Phase 2: Plan the Product

This phase is where AI assistance had its highest leverage: making irreversible architectural decisions cheaply, by exploring options in conversation rather than by spiking code.

Technical spikes in conversation, not code

Each key architectural choice was treated as a technical spike: Supabase versus Heroku Postgres, polling versus WebSockets, custom MFA versus the available gem options, SolidQueue versus Sidekiq and Redis. The difference was running those spikes in conversation with Claude rather than in code. Trade-offs, failure modes, and operational implications were all explored against a single constraint: small charity, no full-time engineer, must be cheap and dull to maintain. Analysis that would normally occupy a sprint was done in an afternoon.

An eleven-phase migration plan, with code-level detail before any code

Claude produced a full migration plan covering database schema decisions, gem selections, controller patterns, GraphQL conventions, deployment topology, and a validation rake task for the data migration. Written before either repository was created. Most architectural surprises were therefore handled on paper.

Creating a product backlog with Claude and Linear MCP

The plan went straight from the project's PROJECT_PLAN.md file into Linear via the Linear MCP. No manual transcription, no copy-paste, no losing detail in translation. Claude read the migration plan and created the tickets directly, structured by phase. Linear handled progress tracking; the planning docs stayed the source of truth.

Live design iteration in code, with the client in the room

Once the project was underway, design iteration moved out of v0.dev and into the running application. Working sessions with LCN staff happened against a local development environment with Claude in the loop, making changes directly in code as the conversation went. Copy tweaks, layout adjustments, missing states, and the sort of edge cases nobody thinks of until they're looking at the real thing were handled in the same session. An improvement on two weeks of email threads.

Mid-delivery: MFA in a day

Halfway through delivery, the client asked for multi-factor authentication. A typical response would be a change request, a separate quote, and a return visit in a few weeks. Instead: Claude evaluated four MFA gems against the project requirements, ruled all four out, and proposed a custom email OTP implementation with bcrypt-hashed codes, session-bound tokens, tiered rate limits, and full audit logging. Plan reviewed with the client in the morning, designed and built the same day, in production the next.

Phase 3: Deliver and Handover

Each deliverable was produced alongside the code, not bolted on after launch.

The product itself

Production SaaS for the Law Centres Network: contact management, individual and broadcast messaging, message templates, three-role RBAC, audit trail, retention automation, multi-tenant Twilio provisioning, and mandatory MFA for every user.

Compliance layer

Retention policies, automated deletion, full Subject Access Request exports, right-to-erasure tooling, and an immutable audit log. The full treatment lives in a companion case study; this work is what made network-wide rollout viable.

User documentation

Generated by Claude alongside the codebase, with a custom screenshot tool that pulls live UI directly into the docs. Screenshots stay current as the interface evolves rather than slowly getting outdated.

Security report

Drafted by Claude post-launch from the codebase itself. MFA design, rate limit tiers, encryption at rest and in transit, GDPR feature mapping, audit logging coverage. The format an LCN board can hand to a regulator without translation.

Technical handover

Architecture overview, deployment runbooks, and the planning documents themselves left in-repo as ongoing reference. Anyone picking the project up later inherits the reasoning, not just the code.

What this changes

A charity-friendly budget now buys work that would have needed an agency a year ago. Every artefact in this project, from the security audit through the product itself to the post-launch compliance documentation, was shaped by working with Claude or v0.dev. The product is the proof point; the way it was built is the change.

None of this means anyone can vibe their way to a production messaging platform for legal aid. The declarative versus imperative gap is real, and it doesn't go away because the tooling is impressive. AI in the right hands is genuinely powerful. AI in the wrong hands produces convincing demos that fail the moment real users, real data, and real regulators show up. The shape of consulting this enables is worth naming directly: a senior practitioner working closely with AI can credibly take on end-to-end production delivery in a regulated domain. Not as a sole-trader compromise, but as a different operating model with its own strengths.

If you're thinking about what a project like this could look like for your organisation, get in touch at andrew@flett.cc.