How to Build a Simple Dashboard with Plain-Language Prompts

The dashboard opportunity

Dashboards used to be a backend discipline. You needed a database, an API layer, authentication middleware, and a frontend framework wired together with routing and state management. For a hobbyist or side-project builder, that stack was enough friction to kill the idea before it started.

Plain-language AI prompts change the equation. Describe the dashboard you want — “a table of recent orders with a filter box and a summary bar at the top” — and the model produces a working HTML file in under a minute. Tools like ChatGPT, Claude, and Cursor have steadily improved at generating structured frontend code from natural language descriptions, and the gap between “I have an idea” and “I have a page” has never been smaller.

This article walks through building a simple admin dashboard with nothing more than a sequence of plain-language prompts. By the end of the weekend you will have a functional data dashboard you can populate with your own records, filter, sort, and share.

What you are building

The dashboard in this guide is an order management panel for a small online shop. It displays a table of recent orders with customer names, items, totals, and status badges. A summary bar across the top shows total revenue, pending orders, and shipment counts — exactly the kind of admin panel you would use to run a weekend store without signing up for a SaaS tool.

The entire thing lives in a single HTML file with embedded CSS and JavaScript. No build step, no server, no database to provision. The data starts as hard-coded JSON inside the script so you can test immediately in the browser. Replacing it with a live API is a later prompt.

The skipped column is not a permanent exclusion — it is a postponement. Once the core dashboard works, each skipped feature becomes a separate prompt session you can tackle one at a time.

The starter prompt

Open your AI assistant — ChatGPT, Claude, Cursor, or any tool that accepts natural language instructions. Paste this to generate the first full version:

Build a single-page admin dashboard in one HTML file with embedded CSS and JavaScript.

The dashboard is for a small online shop and must include:

1. A summary bar across the top showing:
   - Total revenue (£12,450)
   - Pending orders (23)
   - Items shipped today (87)

2. A data table below the summary bar with these columns:
   - Order ID
   - Customer name
   - Item
   - Total
   - Status (Pending, Shipped, Delivered, Cancelled)
   - Date

3. Each status should be a coloured badge:
   - Pending = amber
   - Shipped = blue
   - Delivered = green
   - Cancelled = red

4. A text filter input above the table that filters rows by customer name or item in real time as the user types.

5. A sortable table: clicking any column header toggles ascending/descending sort for that column.

6. A "Download CSV" button that exports the currently visible (filtered) rows as a CSV file.

Use 12 sample rows of data hard-coded in the JavaScript. Make the page look professional with a dark sidebar, a light content area, clean typography, and a responsive layout. Use CSS grid or flexbox. No external libraries, frameworks, or CDN links.

This prompt follows the outcome-based pattern described in The AI Coding Prompt Playbook: it names the format (single HTML file), lists concrete features, defines visual constraints, and sets hard limits. The model will produce a complete working file on the first pass.

Anatomy of a dashboard

The generated file contains the same structural layers every dashboard uses, whether built by hand or by AI. Understanding these layers helps you write better prompts for the next iteration:

When you iterate, target one layer at a time. Does the table need pagination? That is a data-layer prompt. Does the sidebar need navigation links? That is a layout prompt. Breaking the dashboard into these conceptual layers prevents the model from regressing features you already like.

The OpenAI prompt engineering guide recommends the same principle for complex tasks: start broad, then narrow. Each follow-up prompt should modify one layer without contradicting the previous instructions.

Adding your own data

Once the sample dashboard works, replace the hard-coded sample records with your own data. The file stores data in an array near the top of the script:

const orders = [
  { id: "ORD-001", customer: "Alice Chen", item: "Wireless Mouse", total: 29.99, status: "Delivered", date: "2026-06-01" },
  { id: "ORD-002", customer: "Bob Davies", item: "USB-C Hub", total: 45.00, status: "Shipped", date: "2026-06-02" },
  { id: "ORD-003", customer: "Carol Singh", item: "Mechanical Keyboard", total: 120.00, status: "Pending", date: "2026-06-03" },
];

Swap the sample rows with your own records, keeping the same field names so the rendering code still works. If your data has different fields — say, email or quantity — prompt the model to update the columns:

I replaced the sample order data with my own records. My data includes an "email" field and a "quantity" field. Update the table to show these two new columns between "Item" and "Total". Keep all existing sort, filter, and CSV export behaviour working.

The model adjusts the column headers and cell renderers without touching the layout or filter logic. This is the “data hand-off” pattern — show the model the existing structure, supply your real data in the same shape, then prompt for schema changes as separate steps.

Iterating with follow-up prompts

The first generated version is a strong foundation, but you will want refinements. The key to productive iteration is changing one thing at a time:

Each prompt targets a single layer. The model preserves everything else because nothing in the new instruction contradicts the existing code. If a follow-up breaks something, undo the change in your editor and rephrase the prompt with more context about what to preserve.

Connecting to a live data source

When you are ready to swap hard-coded JSON for a live API, the prompt shifts from “build this” to “refactor this”:

Replace the hard-coded orders array in my dashboard with a fetch call to this API endpoint: https://api.example.com/orders

Requirements:
- Show a loading spinner while the data loads
- Handle HTTP errors with a friendly message in the content area
- Keep all existing features: sort, filter, CSV export, and pagination
- The API returns the same field names as the current orders array

The model replaces the data layer without touching the rendering code. If your API returns different field names, include a sample response object in the prompt so the model can map fields correctly. The layout, the table component, and the filter logic remain unchanged.

For hobbyists running a small shop or side project, you can host a simple JSON endpoint on a free tier of Supabase, PocketBase, or even a static JSON file on GitHub Pages. The dashboard does not know the difference.

What a weekend of prompting produces

After two focused sessions you will have:

• A working admin dashboard populated with your own records
• Sort, filter, pagination, and CSV export
• A responsive layout that works on mobile and desktop
• A clear path to add authentication, a real backend, or additional views

Every feature came from a plain-language prompt. You did not write framework boilerplate, configure a build tool, or debug a bundler configuration. The model handled implementation; you handled intent.

For deeper walkthroughs on multi-feature projects built entirely through prompts, see Vibe Coding Pro and Vibe Coding Extra, which cover full dashboard builds from the first prompt to a production-ready deployment.