The GRC Vibe Coding Recipe Book · Lesson 07 of 07
Choose Your Stack and AI Workflow
Compare the projects, test your AI tools, and write a practical build blueprint.
All 7 Lessons · Jump to a Lesson
Recipe 07 · At a glance
Choose the simplest fitting stack
GRC use case: Architecture and tool selection
Ingredients: Start with the GRC problem · Identify users and data · Compare responsibilities and tradeoffs
Know the boundary: The StackFinder is educational guidance, not a security approval.
The final lesson
You've made it to the last lesson.
Think about where you started. HTML, CSS, JavaScript, React, Python, Laravel, and APIs may once have sounded like an unfamiliar collection of technologies. You've now seen what each contributes, how different GRC problems lead to different designs, and how separate pieces can work together.
There's one more skill: deciding which ingredients belong in your solution. You don't need to memorize every framework or become a professional developer to ask informed questions about the tradeoffs.
Start with the problem, not the technology.
Review the journey
Five starting points, one decision framework
Lesson 01 used a browser-only vendor review; Lesson 02 introduced a reusable dashboard; Lesson 03 examined server-enforced approvals; Lesson 04 explained evidence automation; Lesson 05 explored a lightweight cloud backend. Lesson 06 showed how these pieces can connect. The comparison chart there is a reference, not a ladder you must climb.
Choosing a stack means choosing technologies. Choosing an architecture means deciding which responsibilities live where and how they interact. Some technologies complement each other rather than compete.
Five questions before choosing
- What problem needs solving? Describe the manual process and the first useful outcome.
- Who uses it? One person, a team, or an organization?
- What information is involved? Fictional, public, internal, or regulated data?
- What must happen? Display, rules, storage, approvals, automation, or integrations?
- Who maintains it? Consider hosting, costs, updates, tests, access, and incident response.
Know your capabilities
Your vibe coding level is part of the decision
The GRC Vibe Coder's Playbook defines four levels by demonstrated habits, not credentials. They describe your ability to review and operate AI-assisted work, not your worth as a developer.
More components mean more to deploy, maintain, debug, update, and secure. Your experience affects what you can responsibly operate. It does not reduce the security requirements of sensitive data: sometimes the right decision is to narrow the scope or involve experienced support.
Explore the decision
StackFinder: from a suggestion to a reasoned choice
Try different requirements below. Notice not only the recommended stack but also the operational responsibilities and simpler alternative. The finder is an educational starting point, not a security approval or a substitute for architecture review.
Interactive starting point
Find your stack
What does your first useful version need to do? Choose the closest match. This is a starting suggestion, not a final architecture decision.
HTML, CSS and JavaScript
The browser can display questions and calculate results without a server or database.
Operational responsibility: Keep the first version small; document ownership, testing, and where data lives.
Experience fit: Use a small, reviewable version to understand each component before expanding.
Simpler alternative: Avoid shared storage and a running API unless a specific requirement justifies them.
Before you build: Start with the beginner recipe below.
Take this suggestion to a colleague or your AI coding assistant. Ask it to explain a simpler alternative, which parts could be combined, hosting costs, security boundaries, and what would make you change stacks. Bring your Playbook blueprint.
One problem, several answers
The same audit-evidence problem can justify three architectures
A small browser dashboard reads a periodic fictional report. Useful when results are fixed and no protected shared edits are needed.
React filters and explores records. Useful when interface complexity grows; a database is not automatically required.
React requests results from Python through FastAPI. Useful when live checks or multiple consumers justify a maintained service.
New requirements change the recommendation. Team access requires real authorization. Retention needs controlled storage. Scheduled refresh needs an execution schedule. Sensitive cloud evidence needs protected credentials. Each adds a responsibility, not just a feature.
Working with AI
Choose a workflow, not just a model
Chat assistants can explain unfamiliar concepts and challenge a plan. Editor-based assistants work with code and tests in a repository. Visual builders can quickly demonstrate an interface. Agentic tools may coordinate changes across files and commands. These are different workflows, not a ranking of intelligence.
Visual builders
Consider source access, export, hosting, and whether protected backend work is actually supported.
Code editors and agents
Consider repository context, testing, reviewable changes, deployment, and human approval.
Chat assistants
Ask for simpler alternatives, assumptions, risks, and explanations grounded in the actual project.
Challenge recommendations that sound impressive
Why add a database without a storage requirement? Why add login to a local fictional demonstration? Why run multiple overlapping frameworks? Who owns cloud costs, credentials, and security updates? An AI-generated demo is not proof of production readiness.
The GRC Vibe Coder's Playbook explains implementation and review workflows for readers who want to explore building further.