Behind the Curtain: Why ProxyCeptor Is Built the Way It Is
The unpolished version.
The decisions we made on purpose, the constraints that forced our hand, and why one small JSON shape ended up running everywhere.
Arun Gupta29 Sep 2026 · 8 min read
Stop Waiting for the Backend. Mock It and Ship the UI.
Someone had to say it.
The backend is "two more days" away. It has been two more days for a while. Here is a spicy position: the UI should never wait for it.
The spicy version
- A front-end blocked on the backend is a scheduling bug, not a fact of life.
- Agree the response shape first, mock it in the browser, build the UI against the mock.
- Mocked failures (500, timeout, empty list) are the best thing you get from this, not the happy path.
The "two more days" problem
Every team has met it. The design is approved, the UI is ready to start, and the endpoint returns 404 because it does not exist yet. So the front-end waits, or worse, hardcodes fake data inside components and forgets to delete it.
Waiting is expensive in a quiet way. Nobody files a ticket called "lost three days". The work just lands late and gets tested in a hurry.
A UI that only works when the backend is up has not been tested. It has been lucky.
The alternative: agree the shape, mock the rest
Write down the JSON the endpoint will return. Then intercept the request in the browser and answer it with that JSON. With ProxyCeptor that is one rule: match the URL, choose a mock response mode such as replace-whole, paste the body. The page cannot tell the difference.
When the real endpoint lands, disable the rule. If the shapes really matched, nothing changes. If they did not, you found out on day one of integration instead of day nine.
Agree the shapeOne JSON example per endpoint
Mock itA rule answers the request
Build the UIAgainst realistic data
Swap in the real APIDisable the rule
Where mocking pays off most: the ugly cases
The happy path is easy to see. The interesting part is what your UI does when the API returns a 500, takes ten seconds, or sends an empty list. A real backend rarely fails on demand. A mock fails whenever you ask.
- Return a 500 and check the error message a user would see.
- Add a delay to the rule and look at your loading state for real.
- Return an empty array and see whether the empty state exists at all.
Hot take, restated: if your first look at the error state is in production, you shipped the error state untested.
What this is not
Mocks do not replace contract tests or an integration environment. They replace waiting. Keep the mock honest by generating it from the same example the backend team signs off on, and delete rules that outlive their purpose.
Frequently asked questions
Will mocks hide real integration bugs?
Only if the agreed shape drifts. Keep one shared example per endpoint and disable the mock the day the real one lands, then compare.
Do I need to change my code to mock?
No. Rules intercept the request in the browser, so the app code stays exactly as it will ship.
Read next
Intercept your first request in under a minute
Create a free ProxyCeptor account to mock, delay, block and rewrite API traffic, then share the same rules with your team.