The request was reasonable. A directory where businesses could list themselves and be found — profiles, categories, search, the ability to get in touch.
Priced conventionally, that is a real project. You need somewhere to store the listings, a way for people to manage their own, a system to track enquiries, and accounts and permissions around all of it. Months of work before anyone sees anything.
We did not do that. We built the screens first, with nothing behind them.
What “fake the backend” actually means
Every screen looks and behaves like the real thing. You can browse listings, filter them, open a profile, and click through the enquiry flow. It feels like a working product.
Behind it, the listings are a file we edit by hand. There is no database, no login system, no CRM. When something needs to persist, a human does it.
That sounds like a cheat, and in a sense it is. It is also the fastest way to find out whether the thing is worth building properly. The expensive parts of software are almost never the screens; they are the invisible machinery underneath. Building the visible layer first means you spend a small amount to learn whether the large amount is justified.
This works because the volume is small. Hand-editing listings is fine at twenty and impossible at two thousand. The approach is a way to learn, not a way to run a business indefinitely — and being clear about which one you are doing is the whole discipline.
What it taught us that a spec would not have
Within days of people actually clicking around, several things became obvious that no planning document would have surfaced.
The categories were wrong. Not slightly — structurally. The way we had grouped businesses made sense on a whiteboard and made no sense to someone trying to find one. We would have built a database schema around those categories and then paid to change it.
The profile pages had the wrong things at the top. We led with information that the business wanted to say and buried what a visitor was actually looking for. Easy to see on a real screen, invisible in a requirements list.
And the feature everyone assumed was essential — letting businesses manage their own listings — turned out not to matter yet. At this size, people are happy to email a change. That single realisation removed accounts, permissions, and password resets from the build. That is not a small saving.
Why this is not just a tech story
The general principle applies well beyond software: build the smallest version that produces a real reaction, before you build the version that is expensive to change.
A restaurant tests a dish as a special before it goes on the menu. A contractor mocks up a small section before committing to the whole job. Nobody thinks that is cutting corners; it is how you avoid an expensive mistake.
Software gets treated differently, usually because the people paying for it cannot picture the intermediate step. So they are handed a document to approve, they approve it because it sounds right, and everyone discovers the problems after the costly parts are built.
How to know when to build it properly
The signals are not subtle when they arrive.
- The manual work stops being trivial. When updating listings by hand becomes a real chore, that chore is telling you the volume now justifies a database.
- People ask for the same thing repeatedly. Three unprompted requests for the same feature is better evidence than any amount of speculation.
- Mistakes start to cost something. A typo in a file is an annoyance at small scale and a problem when people are relying on it.
Until one of those happens, the machinery is a bet on a future that may not arrive. I have written about the related idea of prototyping before you hire engineers, which covers the handoff side of this.
The point is not that backends are unnecessary. It is that you should earn the right to build one by first proving somebody wants the thing at all. Get in touch if you have an idea you would rather test than specify.