BNBConnect: the locks, written down.
CASE REPORT — 2026 · PREMIERE
A two-sided marketplace for Airbnb hosts and the trades that keep their flats guest-ready — nine service categories, nine per cent each way, and an authorisation layer that lives in a file you can diff, because neither the build nor the linter can see it.
Two sides, and no reason to step outside
Premiere. BNBConnect has not been published yet. Everything below is the finished build, photographed before launch, with the client's own records in it. The live URL goes in as soon as they switch it on.
A host with a flat on Airbnb has a recurring problem and an occasional emergency: the turnover clean between guests, and the boiler that fails at ten on a Saturday night. A locksmith, a cleaner or an electrician has the opposite problem — the work exists, but finding it costs more than doing it.
A marketplace only survives if neither side has a reason to take the second job off the platform. That single sentence decided most of what follows: the fee had to be small enough to be worth paying, the payment had to protect both parties, and contact details could not be handed over before there was a booking to protect.
Navy, coral, and a calm that has to be earned
Sora for the headlines, Inter for the rest. A deep navy carries the brand, a single coral accent carries every action, and the ground is a cool off-white rather than a flat one. Corners at twelve pixels — soft enough to feel domestic, square enough to look like software that handles money.
The restraint is deliberate. A host arriving at ten on a Saturday night with water coming through a ceiling is not in the mood to be sold to.
Four steps, and the money moves last
Post a request. Compare the bids. Pay — into escrow, not to the provider. Confirm the work, and only then is the money released.
That last step is the whole product. The host is protected because the money has not moved; the provider is protected because it has already been collected. Neither side is asked to trust the other, which is the only arrangement that scales past the first bad experience.
A calculator instead of a promise
The pricing page does not describe the fee, it computes it. Type what a provider quotes and the page shows all three numbers at once: what the host pays, what the platform keeps, what the provider receives.
The model is nine per cent each way. A provider sets their own price; the host pays that plus a nine per cent service fee; the provider has nine per cent withheld at payout. On a €100 job the host pays €109, the platform keeps €18 and the provider receives €91 — and the page says so in a table, with worked examples at €50, €100 and €250. No subscription, nothing charged until a job is done.
Eighteen per cent is a real number to defend, so it is stated as a real number rather than buried behind "competitive rates".
Verified means somebody looked
Four promises sit on the landing page, and each one is a feature rather than a sentiment: every provider is checked by hand before they may bid; the payment is held and released on the host's confirmation; messages, including photographs of the problem, stay inside the app and stay documented; and when it goes wrong a human mediates.
That third one does more work than it looks. Keeping the conversation inside the app is what makes the dispute record exist at all — and it is why contact fields are masked until there is a booking to attach them to.
Meet Ben
A host in trouble does not write a good brief. Ben, the assistant on the landing page, asks what is wrong in ordinary language and turns the answer into a maintenance request a tradesman can actually price — the category, the symptom, the access, the urgency.
It is the difference between "shower broken" and a request that gets three comparable bids instead of three questions.
The locks, written down
This is the part worth reading twice.
On a Base44 app the authorisation rules do not live in the code. They live in the entity schemas, as row-level security. Which means npm run build and npm run lint cannot see them, cannot check them, and will pass a build in which every one of them has been removed.
That is not hypothetical. Rewrite an entity schema without carrying its rls block across and every rule on it is gone, silently: nothing fails, the build is green, and the only way to find out is to look. What sits behind those rules is not decorative — the commission, the privacy of every message, the payment step, provider verification, and IBAN and KYC data.
The fix is not cleverness, it is bookkeeping. Every security-critical entity has its required rules declared in base44/rls-baseline.jsonc, each with a written reason and the server functions that enforce it. npm run check:rls dumps the live schemas, compares them against that file and exits non-zero on any deviation, printing expected against actual per entity. The rule for anyone touching the project is one line long: fix every deviation before starting other work.
Authorisation you cannot diff is authorisation you are guessing at.
Every write goes through the back door
Follow the baseline and one design decision falls out of it: for the entities that carry money, status or personal data, the browser cannot write at all.
Writes go through server functions instead — createServiceBid, selectServiceBid, advanceServiceRequest, saveOperatorProfile, sendMessage, markMessagesRead — each running with service-role rights and doing its own authorisation check first. Making any of those entities directly writable from a browser would defeat three things at once: the fee calculation, the state machine that stops a host skipping payment, and the contact masking.
So the rule is stated in the repository rather than remembered: never loosen a rule without changing the function that enforces it.
Six ways to write an article
The content side is a small factory. Six generators produce a different article shape — listicle, comparison, news-jack, intent piece, authority piece, and a general daily article — against a taxonomy of categories and tags, with scheduling, a log of every run, an editor and an archive.
Six pieces are published so far, between 915 and 1,045 words, each on a job a host actually has: deep clean versus standard clean, preventive maintenance versus reactive repair, local locksmith versus national chain at eleven at night.
Under the hood
Four products, one login. A host dashboard, a client area for requests and bookings, an operator side with bids, jobs, earnings and a profile, and an admin back office covering requests, operators, clients, disputes, support, retention and the whole editorial desk.
Thirty-two entities, twenty-five server functions. Including the money path — bids, payouts, withdrawal requests, disputes — and a retention sweep that ages data out rather than keeping it forever.
Personal data treated as personal data. IBAN and KYC fields are readable by their owner and an admin, and by nobody else; the rule is in the baseline with that reason written beside it.
Dutch, and written like it. Not translated. The copy is the sort a Flemish host would actually use — "gastklaar", "wissel-schoonmaak" — which matters more on this product than on most, because the audience is local by definition.
Want the same thing, before it goes live?
BNBConnect goes public shortly. We build the product, the payment path and the authorisation around it — and we write the rules down where the next person can check them.