What’s the simplest way to mock APIs while the backend is delayed?

If backend work is genuinely blocking a shared sprint, it should be tracked as a dependency and surfaced to the lead. But that doesn’t help much when you’re responsible for shipping the frontend yourself, so I’d still use a small contract-based mock rather than waiting or scattering hardcoded JSON through the application.

For a quick freelance project, I’d create a tiny disposable mock layer with just the states needed for the UI: success, empty, loading, validation failure, and server error. You can also mock the controller on the backend if you have access to it, which lets the frontend integrate against a realistic URL while the real business logic is still being built. Storybook is useful too when you need to review the frontend independently with mock data.

Keep the mock at the network boundary instead of putting fake data directly in components. A small handler or fixture layer can define the routes, response shapes, delays, and error toggles in one place. When the real API is ready, you replace the handlers without rewriting the UI.

The most important step is agreeing on the API contract before implementation starts. Once the request and response shapes are clear, the frontend can use fixtures or a tool such as Prism to mock the server until the real implementation exists. That prevents random temporary endpoints from becoming another source of confusion.

MSW is usually lighter than it first appears once the initial setup is done. You define the endpoint handlers once, then can simulate successful responses, 500 errors, and slow requests without changing fetch or component code. For changing schemas, agree on an OpenAPI contract early and generate client types from it so unexpected backend changes fail during development instead of QA.