Next.js 14
App Router application layer, deployed on Vercel.
Case study · Independent product
DoraIncident
AI-native incident management and DORA compliance platform for regulated European payment firms.
The problem
Fix the incident—or feed the reporting clock?
The idea came directly from a pain point I experience firsthand in pan-European payments. When a live payment incident hits, the Incident Manager must manage the incident and manually enter data into a ticketing system at the same time, while a regulatory clock is already running.
Under DORA, a major ICT incident must be classified and notified within tightly controlled timelines, followed by intermediate and final reports. In the middle of an active incident, that paperwork competes directly with restoring the service.
DoraIncident closes that gap: declaration, response and regulatory reporting become one connected flow instead of three disconnected ones.
Product approach
Built solo, end to end.
The product began as a weekend MVP and evolved around a focused operational loop: alert ingestion, AI-assisted triage, human declaration, automatic ticket creation, a live DORA countdown and AI-drafted root cause analysis.
01Alert ingestion & triage→
02Human declaration & response→
03DORA reporting & RCA
A purpose-built ticketing core
Instead of adapting an external help-desk product, I built a lightweight internal ticketing system with structured references, automatic creation on incident declaration, enforced status-transition rules and file attachments. The resulting data model is shaped around incident classification and regulatory reporting—not generic support queues.
Architecture & key decisions
Every choice was a build-versus-buy decision.
Supabase
Postgres, Realtime, Auth and Storage under one platform, with Row Level Security enforcing organization-level data isolation.
Groq · Llama 3.3 70B
Open-weight inference for triage and RCA drafting, preserving a credible future self-hosting path for regulated clients.
Tailwind · shadcn/ui
A consistent, accessible interface system that supports rapid solo product development.
Why Supabase over a custom AWS backend?
For a solo build, Supabase combines four backend capabilities that would otherwise need to be assembled and wired separately. More importantly, its database-level Row Level Security is a natural fit for multi-tenant isolation between regulated customer organizations.
Why an open-weight model?
Using Llama 3.3 70B through Groq was a deliberate regulated-client decision. An open-weight model provides a credible self-hosting route that can address data-residency and vendor-procurement concerns in a way a proprietary black-box API cannot.
Current extension
MCP server for agent-native operations.
The API surface is being extended with a Model Context Protocol server so customer AI agents can query incidents, retrieve DORA reports and manage the ICT third-party vendor register without relying on the web interface alone.
Supabase’s RLS-based tenant isolation carries through to MCP tool calls, so agents respect the same per-customer data boundaries as the application.
Customer AI agent→DoraIncident MCP→Tenant-scoped data
Why it matters
Domain expertise translated into shipped software.
DoraIncident is both a live product and evidence that I can take a regulatory-domain problem, make every technical decision personally and ship a working system—not simply sponsor or oversee one.
It connects directly to my day-to-day leadership of incident management and DORA-aligned reporting at enterprise scale, showing the same operational thinking at both individual-builder and organizational level.