Developer Tools · 2024 · Beta
DevDash
Unified engineering intelligence dashboard for modern development teams.
- Role
- Full-Stack Engineer
- Duration
- 4 months
- Team size
- 2 people
Project overview
What this product is
DevDash is a unified developer dashboard: repositories, pull requests, CI pipelines and deployment health aggregated into one honest view that teams actually check in the morning.
Built with one other engineer over four months, it started as an internal tool at Spurvance Labs and grew into a product when client teams started asking for their own instance.
The problem
Why it existed
Engineering status lives in six places: the repo, the CI system, the project tracker, the deploy dashboard, the alerting tool and someone's memory. Standups burn time reconstructing what one screen could say.
Who experienced it
Engineering teams of 3–20 who live in GitHub but juggle several CI/CD and deployment tools.
Why current solutions weren't enough
Aggregators exist but drown teams in vanity metrics. What teams need is boring truth: what's blocked, what's failing, what shipped — without dashboards that need a curator.
The idea
Vision and constraints
Original vision
One screen, three questions answered: what's in flight, what's broken, what shipped today. Everything else is noise and stays out.
Integrations read-only wherever possible. DevDash observes; it never becomes another system of record that teams must feed.
Development process
01
Research
Shadowed three teams' standups and counted how long 'what's the status' actually took to answer.
02
Architecture
Webhook-first ingestion with hourly reconciliation; a strict event schema made new integrations cheap.
03
Development
GitHub integration first, then the aggregation rules, then the dashboard itself.
04
Testing
Replayed months of real webhook traffic to verify aggregation under out-of-order and duplicate events.
05
Launch
Rolled out to client teams one at a time; each onboarding tightened a rule in the aggregation logic.
My role
Exactly what I worked on
Full-stack engineer on a two-person team — I owned the data layer, integrations and the API.
Data Layer
PostgreSQL schema with tRPC API — typed end-to-end, cached aggressively, hourly reconciliation.
Integrations
GitHub App for repos, PRs and checks; webhook ingestion normalised into one event stream.
Aggregation Logic
The 'honest view' rules: staleness detection, blocked-PR inference and deploy health scoring.
Frontend Charts
Recharts-based visualisations tuned for density — dashboards that fit a laptop screen, not a control room.
Tech stack
The tools that shipped it
Key features
What makes it useful
Unified Status Wall
PRs, checks and deploys on one wall, ordered by what needs a human — not by recency.
- Blocked-PR inference from review state
- Staleness badges after a configurable age
- One-click jump to the source system
Deploy Health
Pipeline runs and deployments scored into a single health signal per service, with history.
- Flaky-test detection across runs
- Deploy frequency and lead time, honestly computed
- Incident markers on the timeline
Team Rituals
A morning digest and a standup mode that turns the wall into a five-minute script for the meeting.
- Per-team digest schedule
- Standup mode with walkthrough order
- Slack webhooks for the too-busy days
Design & UX
How it feels to use
Information density was the design challenge: maximum truth per pixel without visual stress.
Monospace data
Numbers, hashes and durations render in mono — scan-ability comes from alignment, not decoration.
Colour = severity
Only severity gets colour; everything else stays neutral so failures are unmissable.
No vanity panels
Every widget had to answer 'what action does this cause?' or it was cut.
Technical challenges
And how they were solved
Out-of-order event reality
Webhooks arrive late, duplicated and out of order. The event stream is idempotent and reconciled hourly against the source API — the wall stays truthful even when the pipes misbehave.
Aggregation honesty
Every rule (what counts as 'blocked', what counts as 'deployed') was contested. We made rules configurable per team with sensible defaults, and showed the rule beside the number.
What I learned
Honest takeaways
DevDash taught me that product trust comes from boring correctness.
- Idempotent ingestion is the whole game with event data.
- Show the rule beside the metric — numbers without context invite distrust.
- Cutting vanity features was the best design decision we made.
Results
Outcomes where available
DevDash runs for internal and client teams. Team counts are disclosed; user analytics are not tracked.
3
Teams in daily use
Internal plus client instances
5 min
Standup answer time
Down from ~15 minutes of status reconstruction
100%
Read-only integrations
DevDash never writes to source systems
4 mo
Build duration
Two engineers, side-project pace
Final takeaway
Building DevDash taught me…
DevDash taught me that the most valuable dashboard is the boring one — and that data correctness is a design decision you make long before the first pixel.
Gallery
Status wall — what needs a human first
Deploy health — severity colour only
Standup mode — the meeting script
Mobile — truth in your pocket
Keep exploring
