Ship UI Before the API Exists: Browser-Native Mocking with Mockfill

The single most expensive minute in frontend work is the one you spend waiting on a backend endpoint that does not exist yet. Multiply that by a sprint and you get the pattern every frontend dev knows: tickets parked in "blocked," PRs that cannot be opened, designers asking why the screen still looks empty.

Mockfill's Mock API is built to delete that wait. It intercepts fetch and XMLHttpRequest directly in the browser, matches by method and URL, and returns whatever response you tell it to. No backend change. No proxy. No separate mock server.

Nano Banana prompt: "Flat vector tech diagram, indigo and cyan palette on a soft white background. A stylized browser window on the left fires a glowing 'fetch()' arrow to the right. The arrow is intercepted mid-air by a translucent rounded shield labeled 'Mockfill'. From the shield, a JSON-shaped packet (curly braces icon) returns back to the browser. Label arrows: 'request → intercept → mock response → UI'. Clean sans-serif typography, subtle dotted grid background, no photorealism."

The workflow in four steps

1. Trigger the request once. Open the screen that would call the missing endpoint and let it fail in the Network tab.
2. Copy as cURL. Right-click the failing request in DevTools → Copy → Copy as cURL.
3. Import into Mockfill. Paste the cURL into Mockfill's "Import from cURL" field. The method and URL pre-fill automatically.
4. Paste a response body and save. Set status 200, drop in a realistic JSON payload, and you are done.

Nano Banana prompt: "UI mockup screenshot of a browser extension panel called 'Mockfill', light theme with indigo accents. Shows a rule editor with a labeled 'Import from cURL' textarea pre-filled with a curl command, a 'Method' dropdown set to GET, a URL input field containing '/api/users/123', and a JSON code editor below showing a small user object. Rounded cards, soft shadows, modern SaaS aesthetic, crisp readable text."

The first time, this takes about a minute. After that, it takes seconds.

A concrete example

You are building a user profile screen against an endpoint that does not exist:

curl 'https://staging.example.com/api/users/123' \
  -H 'accept: application/json'

Paste it into Mockfill, then drop in the response shape you and the backend dev agreed on:

{
  "id": "123",
  "name": "Asha",
  "plan": "pro",
  "role": "admin"
}

Reload the page. Your UI now has a deterministic response to build against. When the backend ships, you delete the rule (or keep it as a regression preset).

Why this beats the alternatives

• Faster than spinning up a mock server. No json-server, no Express stub, no Docker container, no team-shared port collisions.
• Faster than feature-flagging fake data into the app. No code to write, no code to remove, no risk of fake data shipping to production.
• Scoped to your browser session. Your teammates are not affected by your local mocks unless you explicitly share the rule pack.

Nano Banana prompt: "Clean infographic comparison table, three columns labeled 'Mockfill', 'json-server', 'Hardcoded fake data'. Rows: 'Setup time', 'Code changes', 'Sharing model'. Mockfill column has green checkmarks and short positive labels; the others have warning icons and longer text. Indigo and cyan accents on white, modern flat design, sans-serif, no photorealism."

Sharing the rule with your team

Mockfill exports rule sets as JSON. Once you have a working mock for the missing endpoint, export it and commit it to your repo:

repo/
  tools/
    mockfill/
      users-endpoint.json

Any teammate can import the JSON and start building against the same response in under 30 seconds. This is how a team avoids the "works on my machine" version of mock drift, where every dev hand-rolls their own slightly different fake data.

When to graduate to automation

Mockfill is a human-in-the-loop tool. Once the response shape is stable and you want it enforced in CI, port the same body into a Playwright route.fulfill or a Cypress cy.intercept. The mock you designed interactively becomes the mock that runs in your test suite — same JSON, same status code, same headers.

Nano Banana prompt: "Horizontal flow diagram, three stages connected by glowing arrows. Stage 1: a browser window with a Mockfill rule card labeled 'Manual'. Stage 2: a JSON file icon labeled 'Exported rule pack'. Stage 3: a terminal window running a Playwright/Cypress test labeled 'Automated'. Indigo and cyan palette, soft shadows, flat vector style, sans-serif labels above each stage."

The honest limitation

Browser-level mocks only cover what runs in the browser. If your app uses server-side rendering or server components that fetch on the server, those calls happen outside Mockfill's reach. For SSR-heavy apps, pair Mockfill with a server-side mock for the SSR fetch path, and use Mockfill for everything that runs after hydration.

Try it

If you have a frontend ticket blocked on a missing endpoint right now, install Mockfill, copy the failing request as cURL, and have a working UI in under five minutes. That is the entire pitch.