MockForge

Inspiration

Every frontend team knows this pain: the backend isn't ready yet, but the UI needs to move forward. The usual workarounds are all broken in their own way — waiting on the backend kills momentum, hand-writing fake data is tedious and never scales past a few fields, and existing mock tools spit out lazy placeholders like "name": "string" that don't resemble anything real. That gap between "we need to build now" and "the real API doesn't exist yet" was the spark for MockForge.

What it does

MockForge is a CLI tool that takes your API spec and instantly spins up a working fake API server — one that returns data that actually looks real. Instead of generic placeholder junk, it uses AI to generate realistic emails, names, addresses, and even matching relational data (like an order with items that make sense together). One command, and you have a fake backend that behaves like the real thing.

How we built it

The core is a CLI that parses an API spec file and maps each field to a generation strategy. Rather than static fixtures or dumb string templates, MockForge calls an AI model to generate context-aware sample data per field and per endpoint, so the output stays consistent (e.g., an order's items and totals actually line up). The generated data is then served through a lightweight local server that mimics the real endpoints defined in the spec, so frontend code can hit it exactly like a live backend.

Challenges we ran into

Keeping generated data consistent across related fields (e.g., a user's name matching their email format) instead of generating each field in isolation.
Making sure AI-generated responses stayed fast enough for a smooth local dev loop, not something that felt like waiting on a real network call.
Handling messy or incomplete API specs gracefully instead of crashing or falling back to junk data.
Designing the CLI to be a true one-command experience — no config files to hand-write, no setup ceremony.

Accomplishments that we're proud of

Getting from "here's a spec file" to "here's a running fake backend with data that looks real" in a single command, with no manual data-writing step required. The realism of the generated data was the part we cared about most, and seeing it actually catch UI issues (like long names breaking layouts) that generic mocks never would have caught felt like validation the idea worked.

What we learned

We learned a lot about the tradeoffs between speed and realism in data generation, how to structure prompts so AI output stays schema-accurate instead of drifting, and how much smoother a frontend workflow becomes when the fake backend actually feels real instead of obviously fake.

What's next for MockForge

Support for more spec formats (OpenAPI/Swagger, GraphQL schemas) out of the box.
Stateful mocking, so the fake server remembers changes (e.g., a POST actually affects a later GET).
A shareable config so teams can standardize their mock data style across projects.
Plugin support for custom data generation rules per field.