The GRC Vibe Coding Recipe Book · Lesson 02 of 07
Turn a Spreadsheet into a Dashboard
Explore React, Next.js and TypeScript through a control-status dashboard.
All 7 Lessons · Jump to a Lesson
Recipe 02 · At a glance
Next.js + React + TypeScript
GRC use case: Interactive control-status dashboard
Ingredients: React builds the interface · TypeScript describes the data · Next.js organizes the application
Know the boundary: Start with sample records; add protected services only when requirements justify them.
The GRC problem
Why would a team need this?
A compliance team tracks dozens of control statuses in a spreadsheet, making it difficult to see what is overdue or open.
A filterable dashboard that shows fictional controls by status, owner, and due date. This gives us a useful way to understand the technologies involved: start with the work people need to accomplish, then consider what the application must do to support them.
The underlying concepts
What changes from the previous lesson?
A spreadsheet can hold the same information, but a dashboard makes relationships and status changes easier to see. React becomes useful when several parts of a screen respond to the same filters. Next.js adds a consistent application structure; neither one automatically requires a database.
Remember the four responsibilities from Lesson 01: interface, application logic, storage, and hosting. As requirements become more demanding, those responsibilities may need different technologies. More sophisticated does not automatically mean better.
Meet the stack
What does each technology contribute?
React builds reusable interface components. TypeScript helps describe each control record. Next.js organizes pages and can support server features later, although the first version can be static.
React components written in TypeScript, organized with Next.js
Next.js server functions or API routes when needed
Start with versioned JSON or Markdown for reference data; PostgreSQL for shared records
GitHub
These ingredients have distinct responsibilities. Understanding those boundaries is more useful than memorizing a list of popular tools, because it helps you recognize when a project needs something different.
Under the hood
How would the information move?
Follow a single piece of information through the example. The input starts with a person or an existing record, a rule transforms or validates it, and the interface or report presents the result.
Five fictional controls in a local JSON file.
React renders control cards and updates the visible cards when a filter changes.
A dashboard with Open and Complete views, plus an empty state.
The location of the rule matters. A browser can update its own display, but decisions about access to protected records must be enforced by a trusted service. A database stores information; it does not, by itself, make the surrounding application secure.
Understand the limits
What would change the stack?
Add protected server features and shared storage only if authorized people must edit the same records.
There is also a reason not to add more technology yet: If you only need a public calculator, read-only guide, or three-question assessment, HTML, CSS and JavaScript are likely enough.
What to remember: Never treat a hidden React button as access control. Enforce authorization in trusted server code and protect database credentials. A good stack is one whose responsibilities and tradeoffs you can explain, not necessarily one with the most features.