Case Study - Incremental Frontend Rebuild of the IRIS DFIR Platform
Role: Sole frontend engineer - solo rebuild, architecture through delivery, with supporting backend changes.
Stack: SvelteKit / TypeScript on a Flask/Python backend.
Project: DFIR-IRIS (open source) - github.com/dfir-iris/iris-web. The 2.0 frontend is closed source until its public release.
Client: A European public-sector cybersecurity organisation.
Context
IRIS is an open-source digital forensics and incident response (DFIR) platform that security teams use to manage incident investigations. I was contracted to deliver a 2.0 rewrite of its frontend in SvelteKit.
The system is in active daily use by the client's cybersecurity analysts - this was not a greenfield build, but a replacement under live operation. That constraint extended beyond the frontend: the rewrite required minor backend changes as well, each of which had to land without compromising the stability or security of the production version analysts were depending on every day.
The problem
The existing 2.0 frontend effort I inherited was a vague, partial attempt at separating the frontend (Jinja templates) from the Flask backend. The initial recommendation - from the project's original author - was to scrap it entirely and start from scratch.
The decision - and why I disagreed
I assessed the codebase and chose the opposite approach: an incremental, section-by-section rebuild rather than a total rewrite. The reasoning:
- A working skeleton makes progress visible. Building on what existed meant stakeholders could see functioning sections early, rather than waiting months for a big-bang reveal.
- Auth-first de-risked everything after it. By tackling the hardest problem - authentication - at the start, I had basic end-to-end functionality working at a very early stage, proving the approach before the bulk of the investment.
- A full restart discards working knowledge. An incremental rebuild forces each section to reach done before the next begins, keeping the platform shippable at every step.
I sequenced the rebuild starting with authentication - the riskiest and most foundational seam - supporting local auth (initially session-based, later token-based), LDAP, and combinations of both with MFA. Each subsequent section was then rebuilt to completion and integrated before the next began.
Outcome
Working solo over 8 months, I rebuilt the entire frontend while the old version remained in constant use and under maintenance. The new version is scheduled for release by the end of this year, at which point it becomes publicly available - and publicly showable.
The approach the original author advised against turned out to be the one that delivered.
What I'd do differently
To support session and token-based auth simultaneously during the transition, I built a proxy layer - which introduced errors and slowdowns that cost real debugging time. Starting over, I'd drop the dual support entirely and commit to token-based auth from day one.