5 ways to unblock yourself when the backend API isn't ready

You're mid-feature. You know exactly what the UI needs to do. The Figma file is open. You're ready.
And then you hit it — the backend endpoint doesn't exist yet.
You could wait. Or you could keep moving. Here are 5 ways developers actually handle this, from the quick-and-dirty to the more structured.

1. Hardcode the JSON directly in your component Yeah, it's ugly. But don't pretend you haven't done it.

const products = [
  { id: 1, name: "Wireless Headphones", price: 149.99, in_stock: true },
  { id: 2, name: "Mechanical Keyboard", price: 89.99, in_stock: false },
];

When to use it: You need to unblock yourself for the next 30 minutes and you'll throw this away by end of day.
When NOT to use it: When your teammate also needs the same data. When you need to test loading states. When you forget to remove it before pushing to main (we've all been there).

1. Run json-server locally json-server is a classic. You create a db.json file, run one command, and you have a full fake REST API running on localhost.

npm install -g json-server
json-server --watch db.json --port 3001

Your db.json:

{
  "products": [
    { "id": 1, "name": "Wireless Headphones", "price": 149.99 },
    { "id": 2, "name": "Mechanical Keyboard", "price": 89.99 }
  ]
}

Now GET /products and GET /products/1 both work out of the box.
When to use it: You want a persistent fake API that supports GET, POST, PUT, DELETE without writing any code.
When NOT to use it: When your teammate on a different machine needs the same endpoint. It runs locally — nobody else can hit it unless you do extra networking setup.

1. Mock Service Worker (MSW) MSW intercepts requests at the network level inside your browser using a service worker. Your app thinks it's hitting a real API. It isn't.

import { rest } from 'msw';
import { setupWorker } from 'msw';

const worker = setupWorker(
  rest.get('/api/products', (req, res, ctx) => {
    return res(
      ctx.json([
        { id: 1, name: 'Wireless Headphones', price: 149.99 }
      ])
    );
  })
);

worker.start();

When to use it: You want mocking baked into your codebase, colocated with your tests, and you're comfortable with some initial setup overhead.
When NOT to use it: You just need a URL to paste into Postman or share with a mobile dev. MSW lives inside your frontend — it's not a real URL anyone else can call.

1. Postman Mock Servers
   If your team is already using Postman, their mock server feature is solid. You define a collection, add example responses to each request, and Postman gives you a real hosted URL.
   The URL looks like https://abc123.mock.pstmn.io/products and anyone on your team can hit it.
   When to use it: Your team already lives in Postman and you want mocks that match your existing API documentation.
   When NOT to use it: You're working solo and don't want to context-switch into Postman just to create one quick mock. The setup flow is not fast.

2. An online mock tool — instant URL, no setup
   Sometimes you just need a live URL in under a minute. No install, no config, no service worker, no Postman collection.
   This is what tools like mockserver.in are built for. You describe your endpoint — or paste a schema — and it gives you a live URL immediately. The AI generation feature is genuinely useful here: type "return a list of 5 products with name, price, and stock status" and it writes the JSON for you.
   What makes this approach different from the others:

The URL is publicly accessible — your mobile teammate can hit the same endpoint
Real-time traffic logs show every incoming request with headers and body, which is useful when you're not sure what your app is actually sending
You can simulate delay and intermittent failures — so you can test what your UI does when the API takes 3 seconds, or fails 20% of the time

When to use it: You need a shareable URL fast, you're testing across platforms (web + iOS + Android), or you want to test your error handling without touching the backend.
When NOT to use it: If your mocks need to live inside your codebase and run as part of your test suite, MSW is the better fit.

Which one should you use?
Honestly, it depends on the situation:

30-second fix, throw away later → hardcode it
Local development with full CRUD → json-server
Mocking inside your test suite → MSW
Team already on Postman → Postman mock servers
Need a shareable URL fast, cross-platform, with traffic logs → online mock tool

Most developers I've talked to end up using 2-3 of these depending on the context. The key is knowing which tool fits which situation instead of defaulting to the same approach every time.
What's your go-to when the backend isn't ready? Drop it in the comments.