In production · Baytown Metro Health District
Internal toolInspection backlog dashboard built with an AI coding assistant
Result in one line: Built in three weeks against a four-month estimate; replaced four hand-merged spreadsheets
A nightly operations dashboard for environmental health backlogs, built in three weeks by one developer working with an AI coding assistant.
Published July 21, 2026 Verified August 1, 2026
- Skills needed to set it up
- Developer
- Readiness
- Needs customization
- Data it touches
- Internal, non-public data
- Who sees the output
- Internal staff
- License
- Not open source — available on request
- Cost to stand up
- Not disclosed
- Portable to other platforms
- Yes — platform-agnostic
- Use case category
- Coding & brainstorming
- Reviews it went through
- Security review or authority to operate Labor or workforce consultation
What do these mean?
- Developer
- A software developer to deploy or adapt it.
- Needs customization
- Your team will need to adapt it before use.
- Internal, non-public data
- Non-public operational data without personal identifiers.
- Internal staff
- Used only inside the organization.
- Not open source — available on request
- Peer jurisdictions can ask; say how in the access terms below.
- Not disclosed
- The submitter cannot share cost publicly. Ask the contact.
- Yes — platform-agnostic
- Runs on any comparable stack with configuration changes only.
- Coding & brainstorming
- Writing or reviewing code, analysis, and idea generation.
- Security review or authority to operate
- A security assessment, ATO or equivalent sign-off.
- Labor or workforce consultation
- Discussed with the union or the affected staff before rollout.
Problem
Every Monday, a supervisor exported four reports from the inspections system, merged them in a spreadsheet, and produced the backlog picture for the operations meeting. It took most of a morning, the numbers occasionally disagreed with each other, and nobody could look at the backlog between meetings. Our internal estimate for building a proper dashboard was four months of a developer’s time, which meant it was never going to be scheduled.
What we built
An ordinary internal dashboard: a nightly job that reads the inspections database, a set of SQL views, and a Dash application on a server we already run. It shows open and past-due counts, breakdowns by district and inspection type, and a filterable list supervisors use to reassign work.
There is no model in the running system. The dashboard does arithmetic and draws bars. What is worth sharing is how it got built.
How it works
One developer built it in three weeks using an AI coding assistant for most of the code: the SQL views, the chart components, the layout, and the test fixtures. The developer wrote the data dictionary and the definition of “past due” by hand, in a meeting with the supervisors, before any code existed. That definition turned out to be the hard part of the project — three teams had three different ideas of when an inspection is late.
Every generated change went through the same review as any other code: a pull request, a human read of the diff, and a test run against a copy of production data. The build notes linked above describe what we let the assistant do unsupervised (component scaffolding, tests, refactors) and what we did not (schema changes, anything touching the write path, access rules).
Results
Three weeks against a four-month estimate, with the caveat that the estimate was made for a team that would have designed a data warehouse first. The dashboard replaced four spreadsheets and the Monday morning merge.
Backlog is now reviewed weekly instead of monthly, and past-due work in the worst district dropped by about a fifth over the first quarter as supervisors reassigned it earlier.
Lessons learned
The assistant was fastest at exactly the code we would have found tedious and slowest to be trusted with anything requiring institutional knowledge. It confidently produced a “days past due” calculation that ignored the statutory grace period, which a reviewer caught because the definition had been written down first.
Write the definitions before you write the prompts.
How to reuse
The code is specific to our schema and is not published, but the build notes are the reusable part: what to review, what to hand over, and the argument we used to get an AI-assisted build approved by our IT governance group.
About
- Area of work
- IT & operations
- Environmental health
- Leadership & administration
- Review status
- Reviewed & approved
How it's built
- How AI is involved
- AI was used to build it
- Types of AI
- Rules-based (no ML)
- AI tools & models
- Claude Code
- GitHub Copilot
- Python
- Dash
- PostgreSQL
- Where it runs
- On-premises
Sharing & licensing
- Access terms
- The dashboard SQL and the notes on how the coding assistant was used are shared with other departments on request.
- Portability notes
- Plain SQL views and a Power BI file; the views port to any warehouse and the visuals rebuild in any BI tool.
What it took
- Cost to keep running
- Not disclosed
- How it was bought
- Existing enterprise licence
- Who it affects
- The backlog it surfaces is not evenly distributed: the two districts with the oldest housing stock carry most of it, and making that visible was the point. We watch the reverse risk too — a dashboard that ranks inspectors by closure rate would push them toward the quick inspections, so it reports by district and never by individual.
Data & access
- No PII/PHI in the shared material
- Yes
- Data sources
- Inspections database
- Staff assignment roster
- Data-governance caveats
- The inspections database holds establishment records, not personal data; addresses of home-based establishments are excluded from the dashboard extract.