Project case study · Design, development, and deployment
Aude Diagnostics – Internal Data-Integrity Dashboard
An internal diagnostics web app, built as a Next.js monolith, that reads straight from the database, verifies the main product is producing correct data for every client, and puts the health of all of them on one screen built for troubleshooting.
What it is
Aude's main application generates data for many clients, and the team had no single place to confirm that data was correct for all of them at once.
I built a separate internal web application — a Next.js monolith — that talks directly to the database, checks the main app's output per client, and surfaces the results in one dashboard aimed squarely at the engineers who debug it.
Problem and approach
Problem
There was no fast way to tell whether the main application was generating correct data across every client, so verifying an issue meant checking clients one at a time.
Solution
A dedicated diagnostics dashboard that reads from the database directly, evaluates per-client data integrity, and presents the whole picture in a layout designed for troubleshooting rather than for general reporting.
How it works
Direct database checks
The app queries the database directly and evaluates whether the main application is producing correct data for each client.
One-glance dashboard
Results for every client are laid out so an engineer can see what is not working without drilling in first. The UI is designed for troubleshooting, not general reporting.
Shareable deep links
Engineers can explore down to a cause and share a URL that reopens exactly the view they were looking at, so a finding travels with a link instead of a screenshot.
User's-eye view
A view that shows the UI as the end user sees it alongside the API response behind it, so a visual symptom can be traced to the payload that caused it.
How I built it
- 1.
Learning the existing product
Spent the first month working in the existing Aude product, a Next.js frontend with a Node and Express backend using Redis, fixing bugs across it and mostly on the UI. That built up the understanding of the data flows the diagnostics tool would later have to verify, and led to being given the diagnostics project.
- 2.
Building the diagnostics app
Built the dashboard as a separate Next.js monolith talking directly to the database, and shaped the interface around how engineers actually debug: broad status first, then drill-down, then a shareable link.
- 3.
Deploying behind the existing authentication
Containerised the app with Docker, deployed it to AWS, and served it from the same origin as the main application so it could reuse the existing single sign-on instead of introducing a second authentication system.
Challenges and decisions
Reusing the main product's existing authentication for a second, separately deployed internal application.
Approach: Deployed the diagnostics app on AWS and served it from the same origin as the main application, so a signed-in engineer carries straight over and is sent to the existing login when they are not.
Lesson: Deployment topology can answer an authentication constraint that would otherwise call for a whole second identity system.
The dashboard exposes internal data, so being signed in is not by itself sufficient authorization.
Approach: Layered an authorization check on top of the session so the app only serves authorized members of the engineering team.
Lesson: Authentication and authorization are separate problems, and internal tooling needs both.
Skills and technologies
What I learned
- How to design an interface around a debugging workflow instead of around the data model.
- That deep-linkable state turns an investigation into something a team can share and reproduce.
- How deployment topology can resolve an authentication constraint without adding a second identity system.