I Shipped a Full Dashboard UI Before the Backend Existed. Here's Exactly How.

The message came in at 4 PM on a Thursday: "Can you demo the dashboard to the client tomorrow at 10 AM?"

The designs were approved. The OpenAPI spec was written. But the backend engineer was three days into a complicated auth refactor and wasn't available until the following week. We had designs, a spec, and zero working endpoints.

By 8 AM the next morning I had a fully interactive dashboard — data tables, charts, form submissions, loading states, error states — ready to demo. The backend didn't exist. The demo looked completely real.

Here's the exact approach, step by step.

The Premise: Specs Are Enough

An OpenAPI spec contains everything you need to build a frontend: every route, every request parameter, every response shape. If you have a spec, you have a contract. And a contract is enough to build against — you just need something that honours the contract on the server side.

That's exactly what mock API platforms do. I used moqapi.dev because it imports the spec directly and generates live endpoints that return schema-accurate data.

Step 1: Import the Spec (8 minutes)

I uploaded our openapi.yaml to moqapi.dev. 23 endpoints across 6 resources: users, projects, tasks, comments, notifications, analytics. Every endpoint became live immediately:

GET  /users              → returns array of user objects
GET  /users/:id          → returns single user
POST /projects           → accepts { name, description }, returns 201
GET  /analytics/summary  → returns { totalUsers, activeProjects, ... }
...

Step 2: Configure the Frontend (3 minutes)

One environment variable:

# .env.local
NEXT_PUBLIC_API_BASE=https://moqapi.dev/api/invoke/mock/[api-id]

All my API calls already used this variable. Next.js environment variables make this pattern seamless — swap one line to point at the real backend later.

Step 3: Build the Data Table (45 minutes)

The projects list page fetched GET /projects. moqapi.dev returned a realistic array of project objects — each with an id, name, status, createdAt, memberCount. Values that felt real: project names like "Q4 Migration", statuses of "active" / "paused" / "completed", dates that were recent.

I built the table with sorting, search filtering, and pagination. The mock returned the right structure so the component logic was correct from the first render.

Step 4: Build the Analytics Chart (30 minutes)

The analytics endpoint returned a nested object with time-series data. Our spec defined it as an array of { date, value } pairs. The mock returned exactly that shape with plausible values. The chart rendered correctly on first try.

Step 5: Form Submissions (20 minutes)

Creating a new project hit POST /projects. The mock returned the spec-defined 201 response with a newly created project object. My optimistic UI update added the item to the list. The form reset. Validation errors hit the 422 schema. Everything worked.

Step 6: Error States (25 minutes) — The Part Most Devs Skip

I enabled chaos testing in moqapi.dev — 20% error injection rate across 500, 404, and 422 codes. This forced me to actually implement:

• A skeleton loader for the data table
• An error banner with retry button
• A "nothing here yet" empty state for the projects list

These are the states that make a UI feel production-grade. I wouldn't have built them without the mock forcing errors at random intervals.

The Demo

The client saw a fully interactive dashboard. Data loaded. Forms submitted. Charts updated. They couldn't tell the backend didn't exist. We got sign-off on the design and scope that morning.

Three days later the backend was ready. I changed one environment variable. Integration took 2 hours — mostly fixing minor shape differences where the spec had been updated without me knowing. No architectural changes. No component rewrites.

When to Use This Approach

• Parallel development: frontend and backend building at the same time.
• Client demos: you need something visual before the real system exists.
• Design validation: test information architecture against real(ish) data before committing to an implementation.
• Onboarding: new frontend engineers can build against the mock without needing the backend stack running locally.

The full workflow is documented in the frontend without backend article on this blog if you want more depth on the technical patterns.