Building Your Own GRC Stack
A Practitioner's Revolt Against Vendor Lock-In
The Breaking Point
Every GRC professional knows the feeling. You’ve just finished a demo with yet another compliance platform vendor, nodding along as they walk you through their slick dashboards and “enterprise-grade” features. Then comes the pricing breakdown: base platform, per-control fees, evidence automation as an add-on, API access at a premium tier, and reporting locked behind an enterprise license. Basic functionality that should be table stakes—carved up into profit centers.
But the cost isn’t even the worst part. It’s the neutering.
Want to customize a workflow? Submit a feature request. Need to pull data via API for your own analysis? That’s an enterprise feature. Trying to integrate with your existing tooling? Here’s our marketplace of pre-approved connectors. The platforms designed to make GRC teams more effective end up constraining them to the lowest common denominator of capability.
After years of watching vendors monetize mediocrity, I decided to stop asking permission. I built my own.
The GRC Engineering Mindset
Somewhere along the way, I discovered I wasn’t alone. The GRC Engineering Manifesto gave language to frustrations I’d been experiencing for years—the screenshot-based evidence collection that doesn’t scale, the vendor tools built for GRC teams rather than the stakeholders who actually need to use them, the compliance automation that just produces low-value outcomes faster.
More importantly, it validated an idea I’d been circling: practitioners who live these problems daily are better positioned to solve them than vendors chasing market share. When you build something for yourself, you get immediate feedback on whether it actually works. When a vendor builds something, they optimize for demos and renewals.
That reframing—from consumer of GRC tools to builder of GRC solutions—changed how I approached the problem entirely.
What I Built
The final straw came when I realized our six-figure GRC platform was less capable than Google Apps Script, an Excel spreadsheet, and some dirty API calls. That’s not hyperbole—we were literally building workarounds in free tools because the paid platform couldn’t do basic things without tickets and false promises of “coming soon”.
So I built GigaChad GRC. A complete, modular, containerized GRC platform. From scratch. Fueled by caffeine, mass quantities of vibe coding with AI pair programming, aided by some nameless engineers loaned to me to repay a favor, and the very real pain of watching vendors charge extra for functionality that should be table stakes.
The platform is organized into specialized microservices, each handling a distinct domain: Controls and evidence management. Framework assessments with pre-loaded popular framework requirements. Policy lifecycle management with versioning and approval workflows. A full third-party risk management module covering vendors, assessments, and contracts. A trust center for security questionnaires and public-facing transparency pages. And a complete audit management system with an external auditor portal.
Risk management isn’t an afterthought bolted onto a compliance tracker—it’s a full lifecycle system. Risk identification, assessment, treatment, and monitoring with support for quantitative, qualitative, or hybrid scoring methodologies. Interactive heatmaps. Scenario modeling. Treatment tracking with accountability. The kind of risk program that actually informs decisions rather than just satisfying auditors.
Dashboards are fully customizable because I got tired of vendors telling me which metrics matter. You want to see control implementation by framework? Risk distribution by business unit? Evidence collection velocity? Build the view you need, not the view someone else decided was “best practice.”
The platform includes integrated security awareness training with pre-built SCORM packages—no separate LMS purchase required, no per-seat training vendor fees. A full employee compliance suite for policy acknowledgments, training completion tracking, and attestations. 208+ integrations out of the box because GRC doesn’t exist in isolation. Multiple language support for organizations that operate globally. And the most granular role-based access control I’ve encountered in any GRC tool—because “admin or viewer” isn’t a real permission model.
The architecture runs on NestJS microservices behind a Traefik gateway, with PostgreSQL for persistence, Redis for caching, Keycloak for authentication, and MinIO for S3-compatible evidence storage. Everything containerized. Everything designed to be self-hosted in customer infrastructure rather than locked into a vendor’s cloud.
For deployment, I built three paths: Terraform modules for AWS with proper VPC isolation, auto-scaling ECS services, encrypted RDS, and all the enterprise-grade infrastructure you’d expect—deployable in under 30 minutes. A production-hardened Docker Compose setup for teams who just need a single server running in 10 minutes. And a Supabase/Vercel configuration for teams who want managed infrastructure without the AWS complexity. Automated backup scripts, disaster recovery procedures, the works.
The total? Seven microservices—for now. Over 7,000 lines of infrastructure-as-code. Complete API documentation. Production-ready from day one.
Also light mode. Because some of us work near windows.
Could I have spent that time fighting with vendor support tickets and waiting for roadmap features? Sure. But I’d still be waiting.
Best part? If you don’t like it, you can change it. Any part of it. Why? Because there is no one size fits all and I believe that if you pay for something you should be able to do with it what you need. But I thought you said it was free. It is, but if you find create a high quality microservice that may benefit the community I just ask that you toss in a pull request to benefit the community.
Lessons Learned
Microservices aren’t overkill for GRC. The conventional wisdom says start monolithic, split later. But GRC domains are naturally bounded—controls, risks, vendors, audits—and keeping them separate from the start meant I could iterate on one module without touching the others. When I rebuilt the audit service to add the external portal, nothing else changed.
Vibe coding is a force multiplier, not a replacement. AI pair programming got me through the boilerplate faster than I ever could alone. But it couldn’t make architectural decisions or understand why a GRC practitioner needs the risk register to work a certain way. The domain expertise had to come from me. The velocity came from the collaboration.
Self-hosted is a feature, not a limitation. Every enterprise customer I’ve talked to has asked the same question: where does my data live? Building for self-hosted deployment from day one—with proper Terraform modules and production Docker Compose—means the answer is always “wherever you want it.”
Infrastructure-as-code eliminates support nightmares. When deployment is a terraform apply or docker compose up, there’s no ambiguity about configuration. The Terraform outputs tell you exactly what got created. The environment templates document every variable. Customers can deploy consistently without a professional services engagement.
The Tradeoffs
Building a platform is not the same as building automation scripts. This took real time—nights, weekends, the kind of effort that only makes sense if you’re genuinely fed up with the alternatives.
Maintenance is on me. When Keycloak releases a new version or PostgreSQL has a security patch, I’m the one updating the Docker images. There’s no vendor handling that. The same independence that freed me from vendor roadmaps means I own the roadmap.
And there’s no ecosystem. Commercial platforms have marketplace integrations, pre-built connectors, vendor partnerships. I have APIs and the willingness to write code. For some organizations, that’s a dealbreaker. For others, it’s the point.
But here’s the thing—it doesn’t have to be just me. The GRC Engineering community exists precisely because practitioners are tired of waiting for vendors to solve problems we understand better than they do. The innovation, the maintenance, the evolution of tools like this should come from us. Not from product managers optimizing for enterprise ARR. When a practitioner builds a better integration or identifies a gap, that knowledge can flow back to everyone building in this space. That’s the model. Vendors give you a support ticket queue. A community gives you collaborators.
Is This Path Right for You?
Not everyone needs to build a full platform. If your pain is evidence collection, start there—a few API scripts can transform audit prep from weeks to hours. If your pain is workflow rigidity, sometimes JIRA or Notion can do what your GRC tool can’t.
But if you’re staring at a vendor platform that charges extra for APIs, gates basic reporting behind enterprise tiers, and treats every feature request as a professional services opportunity—maybe it’s time to stop asking for permission.
The GRC Engineering community has a Discord and GitHub presence worth exploring. You’ll find practitioners sharing their own tools, comparing approaches, and demonstrating that the vendor monopoly on GRC tooling is entirely optional.
The compliance industry has spent years convincing us that GRC requires expensive, specialized platforms. It doesn’t. It requires clear thinking about risk, evidence of controls, and the discipline to maintain them. How you implement that is up to you.
The author is a GRC Engineering Manager who got tired of waiting for vendor roadmaps.
Fantastic piece on the hidden tax of vendor lock-in that most GRC teams just accept as normal. The point about vendors charging extra for APIs whiletreating basic customization as a professional services upsell realy captures how much control gets handed over for what should be baseline functionality. Building microservices from scratch might not be for everyone, but at minimum this should push teams to rethink whether they're buying a tool or renting limitations.