An entrepreneurial project I co-founded, from November 2021 to September 2023, discontinued since. The challenge: making rules about money and confidentiality hold between strangers.
Sector: real estate
Period: November 2021 – September 2023
Role: co-founder, design and development of the system
Status: service discontinued
The context
Two strangers, a room, money. One lends a desk at home or on their premises, the other comes to work there for a day. The platform stands between the two, and it is the platform that must answer for what happens.
That setting has a consequence which governs everything else: neither party can be assumed by the system to be acting in good faith. Not because they would be malicious — the vast majority are not — but because a platform that works only if its users behave well is not a platform, it is a bet. The question is never “how do we verify what we are sent”, it is “what do we refuse to receive”.
That is why the three decisions below all concern what the server refuses to send or accept, and none concerns what the interface displays. A protection that lives in the screen protects you from the distracted user; it protects you from nobody else.
The scope, stated precisely
A co-founded project: I did not found it alone, and writing it otherwise would be false. What this page describes is the building of the system — design and development — of which the repositories establish me as the author, apart from the dependency-update bots.
The product and business development belonged to my co-founders. I confine myself here to what I answer for.
The decisions
Send only what is public, rather than filtering out what is not.
A listing contains the exact address of the room, the full name of its owner, their contact details. A visitor who has not yet booked has no business knowing any of that — the neighbourhood is enough for them to decide.
The option set aside was to filter field by field at send time: you take the complete object and remove what must not go out. It works, and it fails the day someone adds a field to the object without thinking of the filter. On that day, nothing breaks and nothing warns: the address simply leaves.
The server therefore composes a public response from nothing, putting into it only the fields it has explicitly named. Adding a field to the listing no longer has any effect on what goes out: for it to go out, it must be written into the public response, which is to say decided.
Refuse to receive a price, rather than verifying it.
At payment time, the interface knows the amount: it has just displayed it. The reflex is to send it to the server, which compares it with the one in the database and refuses if they differ.
That verification works. Its flaw is to make the received amount a legitimate piece of data, which a developer in a hurry may one day use “since it is there”. The payment request therefore accepts no amount at all: it receives only a booking number, and the price is read back from the database.
A price that passes through the customer’s screen can be forged — not with difficulty, using the tools every browser ships with. Rather than verify it, we refuse to receive it: there is then nothing left to verify, and therefore nothing left to forget to verify.
Send nothing you would have to hide at display time.
The symmetrical temptation to the first decision: send the complete object and hide on screen what must not be seen. It is the most ordinary fault in the trade, and the easiest to commit because it produces exactly the right visual result.
What is sent to the browser is readable by whoever asks for it, whatever the styling. Data hidden by CSS is published data.
The rule that follows fits in one sentence and holds well beyond this project: if you have to hide something at display time, it should not have been sent.
What this project did not prove
The service is discontinued, and it never carried significant load. The three decisions above are sound by design; they were not tested by years of operation, nor by the volume that brings out the defects no review can see. I present them for what they are: choices I would make again, rather than guarantees validated by use.
THE GUIDING PRINCIPLE
A protection that lives in the screen protects you from the distracted user. What matters is refused at the server, where forgetting has no effect.
This is the case that shows most directly what it means to move a protection from the screen to the server. If your rules hold today because nobody has tried to cross them, it is the guardrails that make them unbreachable.
Putting the guardrails in: code, deployment, AI agents — 5 days, €4,000 excl. VAT
We use cookies solely for the site to work properly. With your agreement, we also enable the Calendly scheduling module, which sets its own cookies. You can change your mind at any time from the footer. Learn more
