The Problem

Test results live in silos. CI logs scroll past. Failures get buried. Teams spend hours hunting for patterns that should be obvious. TestDino changes that. It aggregates test data from every pipeline, every framework, every build, and turns it into intelligence. Flaky tests surface automatically. Failure trends become visible. Debugging time drops.

My Role

I joined as a forward deployed engineer when TestDino was an idea on a whiteboard. Embedded with the product from day one - building the backend from scratch, designing every API contract, choosing every database, and shipping to production. This is platform engineering at its core: owning the full stack, making architectural decisions that scale, and staying close to real user problems. As the platform grew, so did the team. I went from the only engineer on it to leading the backend group, writing most of the platform in the first four months and then shifting to architecture, review, and written decision records as others took delivery.

Architecture

API Layer
Nine services across three runtimes, chosen per workload rather than per preference. Go for event ingestion and the realtime analytics plane, Node.js and Express for tenant, billing, and integration services, Python and FastAPI for the ML service. Authentication, analytics, reporting, and integrations each in their own domain. Every endpoint documented. Every contract versioned. Shared concerns - auth, logging, deletion cascade - are implemented once per runtime and linted in CI so the two never drift. Data Layer
The right database for the right job. PostgreSQL 17 holds tenant and billing state, where transactional guarantees matter. TimescaleDB, still PostgreSQL, holds the test-event stream as hypertables partitioned by time, so analytics reads touch only the chunks they need and whole runs are deleted by dropping chunks rather than scanning for rows. MongoDB Atlas backs the configuration and integration services, where the schema genuinely varies. Redis Streams carry realtime fan-out to WebSocket replicas. Infrastructure
Azure cloud from the start. Docker containers for consistency. GitHub Actions for CI/CD. Terraform for infrastructure-as-code. Blue-green deployments for zero-downtime releases. Security
JWT-based authentication. Role-based access control. API rate limiting. Secrets managed through Azure Key Vault. Built secure by design, not as an afterthought.

The Library

Engineers shouldn't change how they work to use TestDino. So we built tdpw - the TestDino Playwright test data collector. One npm install. One line of config. The library reads Playwright's JSON reports, extracts test results, captures git context, pulls CI/CD environment variables, and ships everything to TestDino automatically. No manual uploads. No extra scripts. Tests run, data flows. This approach reflects the forward deployed engineering philosophy I bring to every project - making tools that work seamlessly with existing workflows.

Challenges Solved

Scale
Test data grows fast. A single organization can generate millions of test results per month. Designed the data pipeline to ingest, process, and query at scale without choking. Speed
Dashboards need to load instantly. Test events land in TimescaleDB hypertables partitioned by run start time, so a time-range query touches only the relevant chunks instead of scanning history. Redis Streams carry live run progress out to every WebSocket replica, so a running suite updates in the browser without polling. Reliability
Test infrastructure can't be flaky. Implemented health checks, graceful degradation, and automated alerting. The result: 99.95%+ uptime across all services over the trailing 90 days, publicly monitored. These architectural decisions showcase the platform engineering approach I use to build systems that scale reliably.

Impact

80+ organizations trust TestDino with their test data.
130+ engineers and QAs use the platform daily.
2M+ test executions recorded and analyzed.
99.95%+ uptime across all services, trailing 90 days.

Choosing the Event Store

The hardest decision on the platform was where test events live. ClickHouse looks right for a workload shaped like this, and I turned it down. Our writes are UPSERTs rather than appends, since a test is stored once when it starts and rewritten when it finishes, and runs get deleted often enough that segment rewrites would dominate the cost. TimescaleDB won because it is still PostgreSQL, so chunk drops handle deletion and there is no second dialect to carry. The price was recorded at the time: hypertables rule out foreign keys between tables, so keeping the run hierarchy consistent became the application's job. The same record also predicted compression savings that never arrived, and that plan was reverted in full. The full decision, the cost accepted, and the part that turned out wrong are in Choosing the Event Store, and Reverting Half of It.

AI-Powered Intelligence

TestDino isn't just dashboards - it's intelligent analysis: Pattern Detection
Automatically identifies recurring failure patterns across test suites. No manual tagging required. Flaky Test Detection
ML-based detection surfaces tests that pass and fail inconsistently, helping teams prioritize fixes that matter. Anomaly Alerts
Flags unusual spikes in failure rates or execution times before they become production issues. AI-Assisted Debugging
Correlates failures with code changes, environment variables, and historical patterns to suggest root causes.

Technologies

Go · Node.js · Express · TypeScript · Python · FastAPI · PostgreSQL 17 · TimescaleDB · MongoDB Atlas · Redis Streams · Kafka · Next.js · Azure · Docker · Terraform · GitHub Actions