How I built an internal compliance tracking tool?

I didn’t build our internal compliance tracking tool the traditional way.

I vibecoded it.

Instead of long PRDs, heavy sprint planning, and weeks of back-and-forth, I stayed close to the problem and built in tight feedback loops — shipping small, observing behavior, and iterating fast.

The flow was simple:

→ Map the real compliance pain points
→ Ship a scrappy internal version
→ Watch how teams actually used (or ignored) it
→ Remove friction aggressively
→ Repeat

Vibecoding worked especially well here because compliance problems are rarely solved by perfect architecture upfront — they’re solved by deeply understanding workflow friction.

A few things that made the difference:

• Started ugly, but started fast
• Optimized for internal adoption over feature completeness
• Automated evidence collection early
• Kept the data model flexible (compliance always evolves)
• Treated every manual step as a bug

The biggest learning: speed of learning mattered more than speed of coding.

The tool is still evolving — but the team behavior shift is already visible.

If you’re building internal tools, try vibecoding closer to the workflow instead of over-planning from a distance.

Curious — are you still doing heavy upfront specs, or have you started vibecoding parts of your stack?


I used @Antigravity for Raycast to get this done. Model I used was @Gemini 3.1 Pro and @Claude by Anthropic