The GRC Vibe Coding Recipe Book · Lesson 01 of 07
Foundations: From a GRC Problem to a Web Stack
Understand browsers, servers, GitHub, and why a fictional vendor review fits HTML, CSS, and JavaScript.
All 7 Lessons · Jump to a Lesson
Recipe 01 · At a glance
HTML + CSS + JavaScript
GRC use case: Browser-only vendor review
Ingredients: HTML structures the questions · CSS styles the page · JavaScript applies the review rules
Know the boundary: Runs in the browser; use fictional data, with no accounts or shared records.
Start with the foundations
What actually makes a web application work?
When someone says they built a website, a dashboard, or an internal tool, they may be describing very different systems. Some are collections of pages that a browser can open directly. Others accept information, apply business rules, save records, and coordinate work between people. Understanding the difference helps you make sense of unfamiliar technology names instead of treating them as interchangeable ingredients.
A technology stack is the collection of technologies used together to deliver an application. Think about four jobs: presenting information, applying rules, keeping information, and making the application available. A project may use separate technologies for every job, or handle several jobs in one place.
| Job | What it means | Examples |
|---|---|---|
| Interface | What people see, read, click, and type into | HTML, CSS, JavaScript; React for more elaborate interfaces |
| Application logic | The rules that turn input into a result | JavaScript in the browser; Python or PHP on a server |
| Storage | Where information is kept when it needs to survive or be shared | Files, JSON, SQLite, PostgreSQL |
| Hosting | How other people can access the application | GitHub Pages for static sites; cloud services for applications that need a server |
Important distinction: JavaScript, Python, and PHP are programming languages. React is a JavaScript library for interfaces. Laravel is a PHP framework that provides conventions and tools for web applications. GitHub is primarily a place to manage source code and collaboration; GitHub Pages is a separate feature for publishing suitable static sites. These names describe different kinds of things.
Client-side and server-side
Where does the work happen?
Your browser is an application on your computer or phone that reads web pages and runs client-side JavaScript. A server is another computer or managed service that can respond to requests, enforce permissions, and work with protected resources. Not every website needs a custom application server.
In the browser
A fictional questionnaire can display questions, check whether an answer is missing, and show a result immediately. HTML, CSS, and JavaScript can handle the entire experience.
On a trusted server
If reviewers must sign in, approve confidential assessments, or save shared records, server-side rules may be needed to verify identity and permissions. Hiding a button in the browser is not access control.
It is useful to ask, “Where does this rule run?” A browser-only result is fine for a learning example. A sensitive authorization decision belongs on a trusted service, not in code that every visitor can inspect and modify.
The GRC problem
A vendor questionnaire does not always need a platform
Imagine a GRC analyst reviewing a short vendor-security questionnaire. For each question, the vendor can answer Yes, No, or Unknown. The analyst wants a consistent explanation of which answers need attention. Manually interpreting every response is repetitive, and different reviewers may use different wording.
One possible solution is a small browser-based review page. It would present the questions, apply a clearly stated interpretation to each answer, and show the resulting explanations.
A vendor answers Yes, No, or Unknown to three fictional security questions.
Yes: no issue identified by this question. No: negative answer requiring review. Unknown: information missing.
The page displays a clear explanation for each answer so the analyst can decide what needs follow-up.
Notice the distinction between applying a simple rule and making a security judgment. A Yes answer is not proof that a vendor is secure. The page is organizing responses, not performing a complete risk assessment.
Recipe 01 · The default browser stack
Why HTML, CSS, and JavaScript fit
For this example, the information is fictional, the rules are simple, and there is no requirement to save confidential records or coordinate multiple reviewers. That makes the basic browser stack a sensible starting point. It is often called a static website, even though JavaScript can make the page interactive.
These are complementary jobs. HTML is not a substitute for JavaScript; CSS does not decide whether an answer needs follow-up; and GitHub is not the code that applies the rules. Seeing those boundaries makes the next stack easier to understand.
What happens when someone uses the page?
All of this can happen locally in the browser. There is no need to send answers to a custom server for this illustrative use case. A more elaborate framework such as React might also produce the interface, but it would introduce concepts that this simple example does not require.
Understand the limits
What would change the stack?
The stack should follow the requirements, not the other way around. If a team later wants named reviewer accounts, restricted access to confidential assessments, shared records, or a trustworthy approval history, browser-only code is no longer enough on its own. Those requirements introduce server-side authorization and a storage design.
More questions or a more attractive interface, however, do not automatically require a database. The key questions are who needs access, what information must be protected, and where decisions must be enforced.
Takeaway: HTML, CSS, and JavaScript are a strong default for understanding interactive web pages. GitHub helps manage the project, and hosting makes it available. A backend becomes relevant when the problem calls for trusted operations or shared protected data—not merely because a project is called an app.
In the next lesson, we will consider a different GRC problem: making a larger set of control records easier to explore. That is where React, Next.js, and TypeScript begin to make more sense.