Getting an individual engineer to change a workflow is easy. Getting a team to adopt a new tool is harder, mostly because of the transition cost: everyone has to learn something new at the same time productivity is expected to stay high.
Here's how our team adopted mock APIs as a standard part of the development workflow, and the specific things that made it stick.
The entry point: one painful demo
I demoed what happened when I updated an OpenAPI spec, re-imported it to our mock server, and the frontend immediately got the new field without anyone updating a fixture file. That took 20 seconds. The comparison: updating fixture files manually had taken me 40 minutes that morning.
Concrete comparisons work. Abstract arguments about "better tooling" don't.
The rule we established
Any new feature that involves an API contract gets a spec written first. The mock is created from the spec. Frontend development starts against the mock on the same day the spec is approved in code review.
No exceptions. No "we'll add the spec later." Later never comes.
The onboarding improvement
Our previous onboarding for new engineers included: install Docker, run docker-compose up for the backend, set up local database, seed it with test data, configure environment variables. Half a day minimum, often longer.
Now: copy two lines into .env.local. The mock URL is already running. The new engineer is making API calls in 5 minutes.
The tool we standardized on
moqapi.dev because the mock URL is shared — everyone on the team hits the same endpoint. There's nothing to install locally. New specs deploy instantly. The free tier has been sufficient.
What still requires attention
Mocks are not a replacement for end-to-end tests. At some point in the CI pipeline, you need to test against the real API with a real database. We run a nightly integration test suite against staging for this. The mock handles daily development; staging handles pre-release confidence.
Top comments (0)