With interviews complete, we moved to process mining and data audit. The client gave us 6 months of historical records — spreadsheets, email trails, and scanned documents — to analyze.

What the numbers revealed:

• 38 staff-hours per week were being spent purely on compliance-related data entry, cross-checking, and report formatting
• ~120 data entry errors per month were detected post-hoc during internal audits, of which 17% required partial re-testing — a direct cost to the lab
• An average heat batch took 4.6 hours from test completion to compliance report sign-off
• During 3 external audits in the prior year, the team spent a combined 14 working days just retrieving and organizing documentation
• 0% of their process was auditable in real-time — every answer to an auditor's question required manual search

The Cost Model we built:

We built a simple cost model based on their own data:

38 hrs/week × ₹X avg. blended hourly cost × 52 weeks
= Significant annual operational overhead in compliance admin alone

(Exact figures withheld at client's request)

The model also quantified re-testing costs and audit preparation overhead, both of which were invisible line items the leadership hadn't previously tracked. This data didn't just justify the project — it created urgency and executive buy-in overnight.

We ran a 4-week agile build cycle with the following approach:

• Week 1–2: Core authentication, role system, database schema, and chemical lab upload pipeline
• Week 3: Mechanical lab workflow, pending heat queue, physical test submission
• Week 4: Report engine, certificate generation, QA manager dashboard, audit archive

Key technical decisions:

• FastAPI backend for high-performance async processing of large CSV batches
• AES-256-GCM encryption for all archived data (regulatory requirement)
• PostgreSQL on cloud — structured, relational, reliable for compliance-grade data
• React frontend — fast, role-aware, with zero page-reload workflows for lab technicians

We ran two UAT (User Acceptance Testing) rounds with actual lab technicians — not managers pretending to be technicians. This was critical. The system shipped with zero critical bugs at go-live.

This project succeeded not because of the technology — the technology was straightforward. It succeeded because of how we approached the problem:

1. We interviewed the people who actually do the work, not just the decision-makers
2. We quantified the cost of the status quo before pitching any solution
3. We designed for the hardest user first — the lab technician, not the manager
4. We iterated with real users, not assumptions
5. We measured outcomes, not outputs — the goal was never "deliver software," it was "reduce compliance overhead"

If your team is still running quality compliance on spreadsheets, email threads, and institutional memory — you're not just losing time. You're accumulating invisible risk every single day.