August 3, 2026 · Piyush Ranjan Mishra
Building a Manufacturing Compliance & Certification Tracker
I built ComplianceTrack Pro — a compliance dashboard for manufacturing floors that tracks certifications and required skills per employee, flags expired and soon-to-expire certifications by department, and generates renewal and audit reports. This is a smaller, more focused build than some of the other things I’ve written about here, and that’s exactly the point worth writing about: a genuinely useful internal tool doesn’t need to be architecturally ambitious to be valuable — it needs to replace a specific, painful spreadsheet correctly.
The spreadsheet it’s replacing, and why that matters for the design
Every plant I’ve talked to about compliance tracking has some version of the same spreadsheet: one row per employee, one column per required certification, manually updated whenever someone renews something, and manually scanned (usually monthly, usually by one specific person) for anything about to lapse. This works until that person is out sick the week a certification expires, or the spreadsheet has grown to the point where scanning it by eye reliably misses things. The design brief this implies isn’t “build a fancier data table” — it’s “make the thing that currently requires a human to notice happen automatically, and make the status of the whole operation visible at a glance without anyone having to go looking for it.”
Leading with status, not with data entry
The dashboard’s first screen is three numbers — expired certifications, certifications expiring in the next 30 days, and overall compliance percentage — before anything else. This ordering is deliberate: the question a safety lead actually has when they open this tool on a Monday morning is “is anything on fire,” not “let me browse the employee directory.” Burying that answer below a data-entry-focused UI (the more common default for internal tools, since data entry is usually built first and status reporting added later) means the most time-sensitive information competes with everything else for attention. Leading with it, and making the “10 expired” card impossible to miss with actual red styling, is a small design decision that determines whether the tool actually gets checked regularly or becomes another thing people mean to look at.
Per-department breakdown as the actual actionable view
A single overall compliance percentage is useful as a headline number and nearly useless for deciding what to do next. The department-by-department breakdown (Production, Quality Control, Maintenance, Shipping, each with its own compliance rate) is what turns “44% compliant” from an anxiety-inducing statistic into an actionable one — if Maintenance is visibly the worst-performing department, that’s where a safety lead’s next conversation needs to happen. This is a broader pattern worth naming: an aggregate metric on its own rarely tells you what to do; the useful version is almost always the aggregate broken down by whatever dimension maps to a real decision someone needs to make.
Certification status as a donut chart, deliberately
Active / Expiring Soon / Expired, shown as a donut chart rather than a bar chart or a plain table, was a specific choice for this specific data: these three categories are parts of a whole (every certification is in exactly one state), which is exactly the case a pie/donut chart is suited for and a bar chart usually isn’t. I’ve written separately about building pie/donut charts as a pure geometry function rather than reaching for a charting library — the same principle applied here: the chart is a direct, faithful representation of the underlying counts, not a decorative addition after the fact.
Reports and exports as a first-class feature, not an afterthought
A compliance dashboard that only lives on screen is missing half its actual use case — audits, board updates, and OSHA-style regulatory questions usually need a document, not a login to a dashboard. Building report generation and export options as a real, first-class part of the product (not a “we’ll add a PDF button later” afterthought) meant the tool covers the actual moment it needs to be useful most: someone asking “prove to me your certifications are current,” where a link to a dashboard is a worse answer than a generated report they can hand over directly.
What I’d tell someone building an internal ops tool like this
Find the specific spreadsheet or manual process being replaced and design around exactly what makes that process fail (a person forgetting to check, information that’s technically present but not visibly surfaced) rather than building a generic, comprehensive data-management tool and hoping it covers the real pain point. Lead with status and exceptions, not with data entry — the tool needs to answer “what needs my attention right now” before it asks the user to browse anything. And treat export/reporting as core functionality if the tool’s real-world use case involves handing information to someone outside the tool itself, which for compliance and audit-adjacent tools, it almost always does.