The Screens Were Ready Before the Server Was
How I keep a frontend moving when the server side is still being built, without faking anything users will see.
- Published
- Read time
- 6 min read
On team projects, the frontend and the backend rarely finish at the same time. The usual result is that someone waits, or someone builds screens against guesses that break later. I have found a better way to work.
Agree on the shape first
Before I build a screen that needs data, I write down exactly what I will ask the server for and exactly what I expect back. That written agreement, a contract, is shared with whoever builds the backend. Now we can both work at the same time, and we both know when something is finished.
Hide what is not ready
Screens whose backend is not live yet sit behind a switch. Real visitors never see a page that cannot work. When the backend ships a feature, one line changes and the screen appears.
Show it with sample data
For development only, I add a demo mode that fills every screen with realistic sample data. That means I can design every state properly, including empty lists, errors and slow loading, and show the whole product to a client long before it is live. None of it reaches the real website.
- A written contract for every screen that needs data
- A switch for every unfinished feature, so nothing broken goes live
- A demo mode for designing and testing every state
- A plain list of what the backend still needs, kept next to the code
Never let users meet a screen that cannot work yet.
The side effect I like most is honesty. When a client asks "is it ready?", I can point to the list and say exactly what is done, what is waiting, and on whom.
