What You Will Build
In this tutorial you will build a working SaaS dashboard — a sidebar, KPI cards, a chart, and a customers table — by describing it to an AI coding agent, then publish it to a live Vercel URL. The whole thing happens in one browser tab. You will not install Node, configure a bundler, or create a Vercel account.
We will use CloudCode, a browser-based AI app builder and cloud IDE where the Claude Code Agent writes and fixes your code next to a live preview. The steps below follow the real product flow, so you can follow along click by click.
By the end you will have:
- A React + TypeScript dashboard with client-side routing
- KPI cards and a weekly signups chart driven by mock data
- A sortable customers table
- A staging deployment and a production deployment on Vercel
- The code pushed to your own GitHub repository (optional, but recommended)
Step 1 — Create a Project From the Dashboard Template
Sign in to CloudCode and click New Project. Give the project a name — something like 'acme-dashboard' — and continue to the template step. Under Web, choose the API Dashboard template.
The template is deliberately small. It contains an 'App.tsx' with a two-column layout: a bordered sidebar on the left and an Overview area on the right, plus a 'package.json' with React. That is the point. You are not inheriting someone else's opinions about state management or folder structure; you are giving the agent a clean shell to build on. You can see exactly what is in each starter on the dashboard template page.
Because the template includes a 'package.json', there is nothing to install: the dev preview reads your dependencies from it and fetches the packages for you.
Step 2 — Describe the Dashboard to the Agent
Open the agent chat and describe what you want. Good prompts for this kind of work are specific about structure and loose about styling. Here is one that works well:
"Turn this into a SaaS admin dashboard. Add sidebar navigation for Overview, Customers, and Settings using React Router. On Overview, add four KPI cards (MRR, active customers, churn rate, new signups this week) and a line chart of weekly signups for the last 12 weeks. Use mock data in a separate file so we can swap in a real API later. Keep components small and put them in src/components."
The agent does not just stream code into the chat. It reads the existing files, plans the change, and writes to multiple files in one turn — the router setup in 'App.tsx', a 'Sidebar' component, a 'KpiCard' component, a chart component, and a 'mockData.ts' file. If it needs a charting library, it can add the package to 'package.json' itself rather than asking you to do it, and the preview picks it up.
While it works you will see each step: which files it read, which it changed, and why. For larger changes, ask it to propose a plan first; the agent can lay out a numbered plan of steps before it starts editing, which makes it easy to redirect early.
Step 3 — Check the Agent's Work
The difference between an AI that writes code and code you can ship is verification. The agent can't run commands, but it does see recent console errors from the preview, and it has quick static checks for things like missing imports and environment variables your code references. Ask it to use them:
"Check the files you changed for missing imports, then look at the preview console errors and fix anything you find."
This catches the boring failures — a missing import, a chart component that throws because the data shape is wrong — before you go looking for them. If something still breaks, the preview shows an error overlay with an Auto-Fix button. Treat the agent's checks as a first pass, not a build: the real type-check, lint and tests run on your machine or in CI once you push to GitHub (Step 9).
Step 4 — Iterate in the Live Preview
The preview pane runs your app in the browser and recompiles about half a second after a file changes, so every change the agent makes shows up within moments. Three preview features matter for dashboards specifically:
- Viewport switching. Toggle between desktop, tablet (768 × 1024), and mobile sizes. Dashboards are where responsive layouts break first, usually in the sidebar and in wide tables.
- Console and network drawers. The Console drawer shows logs and errors from the preview. When you later swap mock data for real API calls, the Live preview's Network drawer records each fetch request with its status and duration, so you can confirm the calls your deployed app makes.
- Inspector. Point at an element in the preview to see its tag, classes, and size — handy when you want to tell the agent exactly which card needs more padding.
Now add the customers view:
"On the Customers page, add a table of 50 mock customers with name, plan, MRR, and signup date. Make columns sortable, add a search box that filters by name, and paginate at 10 rows."
Then check it in the mobile viewport. If the table overflows, ask the agent to make it horizontally scrollable on small screens or to collapse it into cards below the tablet breakpoint.
Step 5 — Edit Code Yourself When It's Faster
Not every change should be a prompt. If you want to rename a label or nudge a colour, open the file in the code editor and change it directly — the preview updates the same way. CloudCode keeps a version history for each file, so you can browse earlier versions and restore one if an edit (yours or the agent's) goes sideways.
This mix of prompting and direct editing is the workflow that scales. Use the agent for anything that touches several files or needs research, and use the editor for one-line changes.
Step 6 — Plan for Real Data
Mock data is fine for building the UI, but a SaaS dashboard eventually needs a backend. Because the agent put the mock data behind a separate module, swapping it out is a contained change. The most common choice is Supabase: Postgres, auth, and row-level security with a JavaScript client that works in any React app.
We cover that step in detail in How to add a Supabase backend to an AI-generated React app. The short version: create a Supabase project, have the agent install the Supabase client and write the queries, and let it generate the SQL migration files for your tables.
Step 7 — Deploy to Staging First
Open the Deploy panel. CloudCode supports three environments — Development, Staging, and Production — and you choose one before deploying. Pick Staging and click Deploy.
Here is what happens next:
- CloudCode fetches the latest version of every file in your project, so whatever you see in the editor is what ships.
- It sends the files to the Vercel deployments API. For non-production environments, the Vercel project name is suffixed with the environment (for example 'acme-dashboard-staging'), so staging and production never overwrite each other.
- CloudCode adds a routing config that serves 'index.html' for any non-asset path. That means deep links like '/customers' work on refresh, which matters for any app using client-side routing.
- It polls Vercel until the deployment is ready, then shows the live URL. A progress log shows each step as the deploy runs, and if Vercel reports a failure, the last lines of the error output are surfaced in CloudCode so you don't have to go to another dashboard to read them.
When the deploy finishes, switch the preview pane to its Live mode, which loads the deployed URL in an embedded frame with its own console and network capture, so you can inspect the deployment without leaving the IDE.
Step 8 — Promote to Production and Keep a Way Back
When staging looks right, switch the environment to Production and deploy again (CloudCode asks you to confirm production deploys). Every deployment is recorded in the deployment history with its status, URL, and timestamp. If a later change introduces a regression, restore the earlier files — from each file's version history or with a pull from GitHub — and deploy again.
Step 9 — Push the Code to GitHub
Finally, connect GitHub from the GitHub panel and push the project to a repository you own. When you push, CloudCode can generate a '.gitignore' that excludes '.env' files and a '.env.example' listing the variable names you have configured (secret values are left as placeholders). From there you can create branches, open pull requests, review diffs, and merge without leaving the browser — and you can always take the repository elsewhere. If you prefer a fully git-driven pipeline, you can also connect that repository to your own Vercel project.
Common Problems and Fixes
The chart renders blank. Usually the data shape doesn't match what the chart expects. Ask the agent to log the data in the preview console and compare it to the chart props.
A route 404s on the deployed site but works in preview. Check that the route is defined in the router and that the link uses the router's link component rather than a raw anchor with a full page reload.
The deploy fails. Read the error surfaced in the deploy panel, paste it to the agent, and ask it to fix the cause. If the repository is on GitHub, a CI run gives you a real type-check and build to compare against, and the CI tab's AI Fix can read a failed job's log for you.
Wrapping Up
You went from an empty dashboard shell to a multi-page SaaS dashboard with staging and production deployments, a deploy history, and a GitHub repository — all from a browser tab. The pattern generalises: start from a minimal template, describe structure to the agent, check its work, iterate in the live preview, deploy to staging, then promote.
Ready to try it? Start a project in CloudCode and pick the API Dashboard template, or browse all templates.