Three frontends rebuilt in three weeks, with AI agents doing the heavy lifting
August 6, 2026
From pentest to three renewed frontend applications
For a Belgian financial services provider in the automotive sector, the frontend rebuild of their dealer performance platform had been on the wish list for a while. The three web applications ran on Vue 2, a framework out of long-term support since the end of 2023, meaning no more security updates. Then an external penetration test flagged exactly that. Not a breach, not an incident: an unsupported framework, written up as a security finding. The wish became a project with a hard deadline, off the unsupported stack before the summer holidays.
Three weeks of work later, all three applications were rebuilt: modern, secure and mobile-friendly, running against the live backend ten days before that deadline. Not by a project team, but by one developer working with AI agents.
This is what AI-assisted development looks like when you take quality as seriously as speed. Here is what it delivered for the client, and how.
A business-critical platform on an unsupported framework
The platform is business-critical: dealers and salespeople use it daily to follow up objectives, commissions, contracts and invoices, and the client's admin team manages the entire commission engine behind it. The backend had been migrated to .NET 10 earlier in the year, but the three frontends still ran on Vue 2: end of life since 2023, meaning no more security fixes, whatever a scan turns up next.
An external penetration test made that concrete. Nothing had gone wrong, but the report flagged the outdated frontend components as a security finding, with a clear recommendation: get off the unsupported stack. The refactoring wish that had been quietly postponed suddenly had a hard deadline: finished before the summer holidays.
This is the kind of project organisations dread, and postpone, for a reason. The scope covered a management cockpit full of KPI dashboards, commission views and reports, a mobile app for salespeople, and an admin application with over 30 screens. The classic answer to a rebuild of that size is a team working for six months or more. The client got a different answer.
What the rebuild delivered
The deadline was met, and the pentest finding that started it all is closed. But the three weeks delivered more than a like-for-like copy on a newer framework.
Security patching that actually works
Vue 2 no longer receives security fixes, so patching the old stack was painting over a crack. The new frontend runs on current, maintained frameworks, and because the three applications share one repository and one set of dependencies, a vulnerable package is updated once and every app is fixed. The structured patch management the pentest recommended is now realistic instead of theoretical.
Mobile friendly by default
Every screen was rebuilt on responsive components, so dealers and salespeople can now check their objectives and commissions on a phone as comfortably as on a desktop. For the people in the field this was one of the most tangible wins of the project, and it came as part of the same rebuild rather than as a separate project to budget for. Dark mode came along in the same move.
Changes land faster, in all three apps at once
The three applications now share one component library: tables, filters, cards and forms are built once and reused everywhere. A new screen is largely assembled from existing parts, and an improvement to a shared component lands in all three apps at the same time, on this project and on every change after it. The demo week proved the point: over 30 change requests went live within days.
A smaller maintenance bill every year after
The legacy applications lived in separate codebases and carried years of accumulated packages, many no longer maintained. The rebuild started from a clean slate: one repository (with the old git history preserved), a deliberately small set of current libraries, and all three apps permanently on the same versions. An upgrade now happens once and is tested once, instead of three times: a smaller attack surface today, and a smaller upgrade bill every year.
Documented for whoever comes next
Every component has a written design spec and implementation plan in the repository. The next change starts from documentation instead of code archaeology, whether a human developer or an AI agent picks it up.
One developer, a fleet of agents
The agents produced the volume. The specs, gates and reviews kept it correct.
Speed from agents, quality from structure
Speed came from AI agents. Quality came from the structure we put around them.
We started with an inventory: every screen and component of the three legacy applications was catalogued, 46 components in total, and each one became a separate ticket. For every ticket, an AI agent first wrote a design spec, then an implementation plan, and only then the code. Every commit was reviewed against its task, and the branch as a whole got a final security review before merging. The same flow had proven itself a few weeks earlier, when we used it to remediate the penetration test findings in the backend.
The architecture did the rest. Instead of three separate codebases, the new frontend is one repository with a shared component library: a table, a filter or a form is built once and used by the cockpit, the salesperson app and the admin application alike. All screens were first built as clickable pages against mock data (in Storybook), so layout and behaviour could be checked early, and only then connected to the live .NET backend. Automated checks (type checks, linting and build verification) ran on every change, and a human developer reviewed and live-tested everything against the real system.
That combination let one developer orchestrate what is normally a team effort. The agents produced the volume; the specs, gates and reviews kept the volume correct.
Three weeks, measured
The project was planned from 10 to 30 July. The actual pace:
9 July
The shared foundation (navigation, filters, tables) and the full set of cockpit screens were built and connected, a day before the official start.
10 July
All six salesperson screens were finished and the entire admin application existed as clickable screens in Storybook.
20 July
All admin screens were connected to the live backend. Every screen of the three applications was built and working, ten days before the deadline.
27 July
Demo with the client.
30 July
Deadline. More than 30 feedback items from the demo rounds had been picked up and resolved, most within days of being raised. Because every component follows the same spec and plan structure, feedback lands in small, well-defined tickets that an agent can pick up immediately. The client saw the remarks from Monday's demo live on the test environment that same week.
The project in numbers
Quality is the honest concern, so we engineered for it
The honest concern with AI-generated code is quality, and it is a concern we share. That is exactly why every ticket gets a spec before a single line is written, why every commit is reviewed, and why the final branch went through a dedicated security review.
“This is the first AI-built project that doesn't look AI-built.”
What this means for your legacy frontend
Frameworks age faster than the applications built on them. If your frontend runs on Vue 2, AngularJS or another end-of-life stack (a framework that no longer receives security updates), you are carrying a growing security risk and maintenance bill. And the classic answer, a rebuild project of six months or more, is exactly why most companies keep postponing it.
Our experience with this project says the trade-off has changed. With AI agents inside a disciplined spec, review and verification process, a rebuild of this size fits in weeks, not months, without cutting corners on quality or security. If you have a modernisation that keeps sliding down the backlog, talk to us. We will gladly show you how we work, demo included.