CML Dashboard
The operations dashboard backend for LetsCML — reporting and admin tooling over the same data.
2026 · Solo build — effectively the entire service.
The problem
Operations needed reporting and admin tooling over the LetsCML data. The quick answer was a second service with its own database connection, which would have meant two codebases holding opinions about one schema.
What it does
A NestJS backend with role-based access, structured logging and rate limiting, which reads and writes entirely through authenticated endpoints on the main service rather than connecting to the database itself.
Engineering decisions
No direct database connection, on purpose
The dashboard has no database credentials at all. Every read and write goes through signed endpoints on the service that owns the schema, including a transaction endpoint for multi-step workflows. It costs a network hop, and it buys one place where access rules and schema knowledge live — so a migration can't silently break a second service that nobody remembered was reading that table.
Strict TypeScript from the first commit
Strict mode is close to free at the start of a project and expensive to adopt later. Turning it on before there was any code to fix meant the service has never had a nullable-field surprise in production.
Where it landed
- Operations reporting and admin tooling for a 300,000+ user platform
- Zero database credentials in the service
- Role-based access control with correlation-ID logging throughout