1
3 Comments

Indie Hacker Frontend devs: How do you handle backend mocking during development?

Hey everyone,

I'm a developer exploring a problem I've run into myself: mocking backends while building frontend applications.

I'm curious about your experiences and would love to have some deeper conversations about this.

Specifically:

  • Your current workflow: How do you mock APIs/backends during frontend development? Walk me through what a typical day looks like when you're waiting on backend work.
  • Tools and frustrations: What tools have you tried? (MSW, JSON Server, custom scripts, etc.) What works well, and more importantly—what drives you crazy about your current setup?
  • Time and money: How much time do you spend setting up and maintaining mocks? Have you paid for any tools to solve this? What made a paid solution worth it (or not)?
  • Workarounds: If you don't mock backends, what do you do instead? How does that affect your development speed and workflow?

If you have strong opinions on this, I'd love to talk in more detail. Please consider taking 2 minutes to fill this in: https://forms.gle/Xxi6fnNwKFGjy4Dz7

Thanks!

on December 3, 2025
  1. 1

    Hey Luke!

    It is an interesting question. If I share my experience, I usually rely on Back4app (https://www.back4app.com/) as a real backend while building frontend apps. This BaaS platform lets you focus entirely on client-side activities while handling all your backend tasks, from database management to push notifications. Hereof, I set up my data models, seeded some records, and just hit the endpoints directly, without waiting on a backend team. For tricky edge cases or offline testing, I will use MSW to mock a few responses, but most of the time I work with live data.

    On the other hand, JSON Server or custom scripts work, but keeping them in sync with the real backend logic is a headache. Withal, paid mock tools are fine, but Back4app gives me realistic responses for free, speeds up development, and reduces bugs. Yes, it offers a free tier for beginning-level projects. It means frontend work becomes much smoother here.

  2. 1

    Great question—this is always a pain point. I usually start with lightweight mocks (JSON files or MSW) to move fast on the UI, then gradually swap in real APIs once contracts stabilize. Curious whether people here prefer local mocks or shared staging endpoints as projects grow.

  3. 1

    Current workflow:

    When backend work isn’t ready, I usually mock APIs using a mix of static JSON responses and lightweight mock layers. On Shopify or frontend-heavy projects, I often create temporary data structures that mirror the expected API shape so I can continue building UI, state handling, and edge cases without blocking. A typical day is switching between UI work, refining component logic, and updating mocks as backend contracts become clearer.

    Tools & frustrations:

    I’ve used tools like JSON Server, simple custom mock scripts, and occasionally MSW for more complex cases. MSW works well for realistic request handling, but setup and maintenance can be overkill for smaller projects. The biggest frustration is keeping mocks in sync when APIs evolve — especially when endpoints or response structures change late.

    Time & money:

    I try to keep mock setup lightweight. Still, it’s not uncommon to spend a few hours per project setting things up and maintaining them. I haven’t paid much for dedicated mocking tools so far — most paid solutions feel heavy unless you’re working on large-scale apps with many developers and long-lived APIs.

    Workarounds:

    If mocking isn’t practical, I sometimes work against staging endpoints, feature-flag incomplete flows, or build UI with defensive logic (empty states, loading/error handling first). This keeps progress moving but definitely slows things down and increases rework later.

    Overall, good mocking speeds up frontend work significantly — the challenge is finding a balance between realism and setup overhead.