Three Weeks to Three Hours: Building the Internal Tool Nobody Asked For
This is the longform companion to a piece I posted on LinkedIn this week. The numbers below are real. The names aren’t. Read this as a case study, not a brag.
the meeting
Our VP of compliance is not the kind of person who shows excitement. She’s measured. She runs the audit cycle the way you’d want a compliance VP to run it — careful, thorough, no surprises. So when she raved about an internal tool I’d built at last week’s steering committee, in front of the whole leadership team, the room noticed.
She was talking about a periodic user-access review we run across our properties. The kind of work every regulated industry does on a schedule. Required for audit, has to ship every cycle, and historically — one coordinator at one of our properties spent roughly three weeks on it. Pulling reports, sending emails to chase approvals, wrangling spreadsheets, following up on the follow-ups. Cycle after cycle.
I built an internal tool last year that replaced that workflow.
The last cycle ran in three hours.
Not for the whole company. That’s one coordinator at one property. We have six.
what the tool actually does
The “three hours” number gets the LinkedIn engagement. The deeper interesting bit, for anyone thinking about building something similar, is what the tool does well enough that the VP raved. Because the time saved is the easy headline. The thing she actually pulled me aside about — separately, after the steering committee — was that her team isn’t dreading the cycle anymore. That’s a different metric. It’s the one that matters more.
Here’s the actual scope of the tool, end to end:
SSO and identity
Single sign-on against our existing Entra identity provider. Nobody has to remember a new password or get provisioned into a new directory. The reviewers and coordinators and auditors all hit the same login they already use for everything else internal. This sounds obvious. It is not the default. A lot of compliance tools want their own user database. That alone keeps people from using them.
Role-based permissions, scoped per reviewer
Three role tiers — reviewer, coordinator, auditor. A reviewer sees only the access lines assigned to them, ticks approve or revoke, optionally adds a comment. A coordinator sees the whole cycle’s state — who’s reviewed, who hasn’t, what’s blocking. An auditor sees the read-only evidence record. Each role surface is purpose-built. The coordinator doesn’t have to wade through every reviewer’s queue to figure out who’s behind.
Teams bot integration
The cycle pings approvers in the Teams channel they already work in, with a direct deep link to their assigned review queue. Not a generic “please complete your review” email — a targeted message in the room where the person already has notifications turned on. The Teams bot also responds in-channel when reviews are completed, so coordinators get an organic feel for the cycle’s progress without having to log into the tool.
Scheduled reminders
Built-in cadence: gentle nudge after N days, more pointed nudge after N+M days, urgent nudge at deadline-minus-48-hours. The coordinator used to be the human cron job for this — sending the reminders by hand on a spreadsheet schedule. Now the tool does it. The coordinator’s job becomes handling the actual blockers instead of being the reminder service.
Approval tracking + live dashboards
A real-time view of the cycle’s state: total assignments, completed, pending, overdue, in-review. Aggregated per property, per reviewer, per access type. The coordinator can answer “where are we?” in seconds instead of opening four spreadsheets and doing math.
Auto-upload to the GRC platform
When a cycle closes, the tool packages the evidence (PDF report, CSV of all decisions, signed manifest) and pushes it to our GRC platform where the auditors expect it to live. No human handoff. The cycle’s record lands in the GRC system the same business day the cycle closes, ready for review.
Cryptographically-signed records
End-to-end. Every decision (approve / revoke) is timestamped and signed into a manifest that’s HMAC-signed on close. If an auditor wants to verify the cycle wasn’t tampered with after the fact, they can. We haven’t been audited yet with this tool — but when we are, the integrity of the evidence is mechanically verifiable, not just procedurally trusted.
why three weeks before
Before this tool, the cycle was a coordination problem disguised as a compliance task. The actual review work was small per reviewer — twenty access lines, fifteen minutes each, decide approve or revoke. But the coordinator was the entire system: making sure the right reviewers got the right rows, chasing every one of them by name, collecting the spreadsheets, normalizing the data, generating the report, signing the PDFs, sending the package to the auditor.
Three weeks of one full-time person’s attention, spread across the cycle window. Not because the work was complex — because the work was distributed across thirty different humans on different schedules and the coordinator was the only thing holding it together.
That’s the pattern I want to point at. The work itself was small. The coordination overhead made it three weeks.
The tool didn’t remove the work. It removed the coordination overhead.
build philosophy
I’ll be honest about what I think the success of this build came from, because it’s repeatable.
It solved a real problem that nobody was building a product for. The big GRC platforms have access-review modules. They’re either too generic to fit our specific workflow, or they cost six figures a year in licensing. The small specialty access-review tools we evaluated were single-purpose enough that integrating them into our existing identity stack and Teams stack would have meant duplicating half our environment. So the gap was: workflow specific enough that we couldn’t buy it, but not technically hard enough that we couldn’t build it.
It was built for the actual people doing the work. I sat with the compliance coordinators and watched them run a cycle the old way before I wrote a line of design. The Teams bot integration came directly out of that — they had Teams open all day anyway. The scheduled reminders came out of watching the coordinator type the same email twenty-seven times. The role-based dashboards came out of watching her open four spreadsheets and try to figure out who was holding things up.
It runs on infrastructure we already had. No new SaaS contract. The tool deploys to our existing Coolify environment. The database lives on a Postgres instance we already operate. The Teams bot uses the same Graph API our other internal tools use. The GRC push uses the existing API our compliance team already integrates against. Total cost to the company: my time. Ongoing cost: still my time, plus whatever the infrastructure already costs.
It was built to outlast me. Code is documented, the data model is clean, the deploy process is reproducible. If I leave the company tomorrow, the next person can pick this up. That part matters more than most internal-tool builders admit. There’s no point shipping the heroic build if it dies when the builder leaves.
the gap thesis
I think there’s a category of internal work that sits in a weird gap:
- Too important to skip
- Too unprofitable for a SaaS vendor to chase at the scale you need it
- Too tedious for engineers at your company to want to volunteer for
- Too organization-specific to outsource cleanly
That gap is where the highest-ROI internal work in most organizations actually lives. It’s the workflows your team apologizes for. The cycles people quietly take PTO around. The processes that work, but only because someone is grinding through them.
If you’re an IT or ops leader, that gap is probably the next big win sitting in your org. You probably already know which one. It’s the thing you’ve been asked about three times this quarter and shrugged off because you don’t have the engineering bandwidth to commission a full build.
In 2026, that calculus has changed. The bottleneck isn’t engineering bandwidth anymore. The bottleneck is what you know about your org’s workflows and what you can describe well enough to direct an AI coding agent to ship.
The whole audit-review tool I described above took less than a sprint of my own time, spread across evenings and Saturday mornings over a couple of months. It would have been a multi-quarter engineering effort if I’d been writing it by hand. I wasn’t.
the dread number
The VP didn’t actually start with “three weeks to three hours” at the steering committee. She started by saying her team isn’t dreading the cycle anymore.
That sentence is the one that stuck with me longest. Not dreading the cycle. The cycle has run for years. Every property has done it every cycle. The work has always been finite — it just felt infinite because of the coordination burden. The tool removed the dread.
Time saved is the metric leadership understands. Dread removed is the metric that actually changes how people show up to work.
If you’re building internal tools and you’re looking for the next thing to ship: find the workflow your team dreads. Build the version of it that removes the dread. Watch them stop apologizing for the cycle.
That’s the work.
I’ll keep writing about the internal builds I’m shipping with this pattern. If you’re an IT or ops leader running into the same compounding-coordination-overhead problem on a workflow that “feels important but is mostly just annoying” — drop me a line. I’d love to compare notes on what you’ve been dreading.
