Bizleen × Bizleen Orbit
Online · bizleen.com + app.bizleen.comOne product, served by two repositories. Bizleen, the public site, sells: digital card, catalogue, opening hours, reservations, in nine languages. Bizleen Orbit, the connected workspace, executes: hours, tips, leave, rota, estimated payroll, on the shared tablet and on every employee’s phone. The two databases stay separate. Four shared surfaces are delivered and served: the public card displayed full screen inside the tablet, the daily special translated in batches, the Orbit header on bizleen.com and the reservation widget protected by Turnstile. The four pieces of the bridge (pairing, an eleven-method service contract, the catalogue bridge, provisioning) are built and tested on both sides; their commercial rollout is in progress.
One product, two repositories
Bizleen was born on 23 May 2026 as a digital business card: a public page, a handle, a QR code, a vCard. Eleven days later, on 3 June 2026, a restaurant needed a tool to clock hours, split tips and estimate salaries: it was born StaffClock, and it became Bizleen Orbit. Through June and July the two repositories did not talk to each other. On 18 August 2026 I wrote the first of the 23 exchange documents, for a commercial reason before a technical one: the mini-site could display a grid of priced services, but it could not say whether Tuesday at 3 pm was free, and that information lived in the tool that already held the team’s rota. So I stopped talking about two products. The public site sells, the connected workspace executes, and I built the four pieces of the bridge in order: pairing, the eleven-method service contract, the catalogue bridge, provisioning. On 4 September 2026 the last exchange document concluded that the Bizleen side was finished. The bridge is built and tested on both sides; its commercial rollout is in progress. The appointment engine that will answer the time-slot question on the Orbit side is, for its part, under construction. The two databases stay separate: what crosses is named, and nothing else crosses.
Structural decisions
The permanent catalogue (services, variants, prices, allergens, pairings) is managed in Bizleen, because it is edited rarely and at length; Orbit keeps only a read-only projection of it. The daily special is entered in Orbit, because it is written every day in thirty seconds, inside the tool already open to prepare service. The manager does not switch applications at the moment they have the least time, and nobody types the same information twice.
Publishing the daily special is an outbound call from Orbit; fetching its translations is another. No inbound route was opened on Orbit to receive a callback from Bizleen, so there is no signature to verify and no replay to fear on the internet. When the bridge needed the opposite direction (a reservation to hold, a catalogue snapshot to publish), I did not open it to the web: it runs over a service binding inside the Cloudflare account, with no public HTTP surface.
Every method of the contract takes the venue’s secret as its first argument; none resolves a venue from a slug. Orbit keeps only the fingerprint of that secret; Bizleen stores it encrypted and bound to the row that carries it. A single live pairing at a time, a revocation that is dated rather than erased: the day you need to understand what happened, the history is still there.
Opening the customer record to whoever is working that day was tempting. It is a poor criterion: presence shifts all day long, and it turns an access right into a side effect of the schedule. Preferences and allergies therefore stay with managers and the host tablet, while floor staff receive information sized to their actual need: how many covers, how large is the biggest table.
The non-trivial challenge
When two repositories serve the same product, the temptation is to give them a common database, or to build a synchronisation layer between them that nobody really tests. I kept the opposite constraint: two databases, and everything that crosses carries a name, a version and an owner. The catalogue belongs to Bizleen; Orbit accepts a snapshot only when its revision is strictly increasing, and its triggers refuse to delete a row from it, so a withdrawn service stays readable in appointments already taken. Reservations cross in the other direction through the service contract, with the venue’s secret on every call and an idempotency registry that replays the original response when a call is repeated. The daily special, for its part, is saved locally first, then published; if Bizleen rejects the token or requires a higher plan, the screen says so in the language of the business instead of stacking a silent failure. Twenty-three exchange documents fixed these rules before the code enforced them.
Lesson learned
One product does not require one database. What connects two repositories must stay smaller than they are and fully named: four surfaces, eleven methods, one secret per venue, no intermediate storage beyond a read-only projection. That is what lets me deploy one without redeploying the other, and say precisely what is in service and what is not yet. The second lesson is about permissions: when deciding who sees what, anchor it to a stable property of the person, their role, and not to a moving one like being on shift today. An access right indexed on the schedule becomes impossible to audit the next day.
Features
The form is a Bizleen Orbit iframe embedded on bizleen.com, served with a CSP that lets only that domain frame it. The public route asks for no API key: it defends itself with Turnstile, a honeypot field, a rate limit and a per-venue opt-in. Bizleen therefore holds no access to the Orbit database.
The daily special is set in Bizleen Orbit, where the team is already preparing service, then sent to the Bizleen integration API with a bearer token unique to that venue. The token is a server-side secret: pasted once by the super-admin, it is never returned to the browser nor shown in the venue’s own settings.
Translation happens on the Bizleen side and takes 3 to 25 seconds, English landing before the other languages. Rather than opening an inbound route to defend, Bizleen Orbit never blocks the entry and comes back for the result on a decaying schedule (2.5 / 5 / 9 / 14 / 20 / 27 s), stopping as soon as the set of languages stabilises.
Reservations feed a durable customer profile: visits, no-shows, last seen, all recomputed from reservation history. Preferences and allergies stay a free-text field, a deliberate choice: the floor writes down what the guest actually said, not what a dropdown anticipated.
Reservations and customer records are restricted to managers and the host tablet; the employee role holds no global permission, and the code refuses even to push them a link to that screen. Floor staff receive an anonymised summary of their service (expected covers, largest table), never a name, never an allergy.
Every employee has a personal account and an installable app on their phone. Alongside it, a single tablet account per venue covers the host stand, with two separate codes (server, manager) and a traced elevation that expires after 15 minutes. The tablet never stores a password, hence a long sliding session instead of a re-login in the middle of service.
On the 1st of each month a scheduled job builds the detailed hours as a PDF and emails it to a designated administrator, accountant in copy (three recipients maximum). Off by default, enabled per venue. The send is claimed with a database lock before it happens, with catch-up until the 3rd: never twice, never zero times.
In tablet mode, the public Bizleen card opens full screen from inside Bizleen Orbit. The menu is therefore never copied into the internal tool: the guest at the table and the guest on their phone read the exact same page.
Orbit issues one secret per venue and keeps only its SHA-256 fingerprint; Bizleen stores it encrypted, with associated data bound to the row and the card that carry it, so an envelope copied from one venue to another fails to decrypt. A partial unique index guarantees a single live pairing; a revocation is dated, never deleted. Built and tested on both sides.
Service to service, inside the Cloudflare account, with no public HTTP surface: catalogue snapshot publication, revision check, capabilities, availability, hold placement, refresh and release, confirmation, move proposal and acceptance, cancellation. The secret is the first argument of every method, never a public identifier. Built and tested on both sides.
Bizleen publishes what it sells; Orbit keeps a read-only projection, accepted only when the revision is strictly increasing and protected by triggers that refuse any deletion. A withdrawn service stays readable in appointments already taken, and the bridge tells “not configured yet” apart from “deliberately withdrawn”. Built and tested on both sides.
Three methods (open a workspace, reissue a pairing, read the workspace state), guarded by a global secret distinct from the pairing secret and called from the Stripe webhook: paying for a subscription becomes the event that creates the account on the other side. Wired and tested; rollout in progress.