Online bizleen.com
Bizleen × Bizleen Orbit
One product, two codebases: the public site sells, the connected workspace delivers.
In short
Bizleen Orbit is a product of Bizleen, one product served by two repositories.
Bizleen, the public site, sells: digital card, catalogue, opening hours, reservations, in ten languages, with a unified Studio editor and marketing redesign. Bizleen Orbit, the connected workspace, executes: hours, tips, leave, rota, estimated payroll, on the shared tablet and on every employee’s phone in 14 languages. The two databases stay separate. Both repositories are now joined by bidirectional production SSO (shared cookie on .bizleen.com), seven unified RPC channels, a venue mode arbitrator (internal vs standalone), and a live Team plan at €20/month with automated provisioning.
Highlights
-
Bidirectional SSO live in production
Since 16 September 2026, Bizleen SSO has been live in production both ways: an active session on bizleen.com instantly opens app.bizleen.com without password re-entry, and from app.bizleen.com a manager reaches Bizleen Studio or Insights through a one-time token valid for 60 seconds. Closing the session on either side instantly revokes access on the other, tested and verified, logged in the audit trail.
-
Seven unified RPC channels
Seven typed channels connect the Workers inside the Cloudflare account with no public HTTP surface, including BookingRpcV1, BizleenProvisioningV1, EtablissementSyncV1, MigrationReadiness, SessionsBizleenV1 and StatistiquesOrbitV1.
-
Venue mode arbitrator (internal / standalone)
definirNiveauEspace contract: an internal-management venue disables standalone public booking without losing any of its records or staff rights.
-
Monetised Team plan and direct provisioning
The Team plan at €20/month (or €200/year) is live and billable via Stripe Checkout, automatically provisioning the Orbit connected workspace upon subscription.
-
Public reservations with no shared secret
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.
-
Daily special entered on the ops side, published on the storefront
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.
-
Translated in batches, openly asynchronous
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.
-
A customer record built by the floor, not by a form
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.
-
The customer file is a role privilege, not a rota privilege
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.
-
Two access modes, both owned
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.
-
The accountant receives a document, not an account
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.
-
The storefront reused in the dining room
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.
By the numbers
- 1 Product
- 2 Repositories
- 4 Shared surfaces
- 7 Unified RPC channels
- 535 Markdown documents
- 674,850 Production lines
- 28,350 Test cases
- 268 SQL migrations
The story
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 exchange document, 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. The public site sells, the connected workspace executes. The four pieces of the bridge were built in order: pairing, service contract, catalogue bridge, provisioning.
On 16 September 2026, unified SSO went live in production: a session on bizleen.com instantly opens app.bizleen.com. On 18 September, a fifth RPC channel and venue mode arbitrator were deployed, while the Team plan became billable; two more channels followed by 28 September, bringing the total to seven. 674,850 production lines and 528,420 test lines now back this enterprise suite.
Structural decisions
The point of entry follows the rate of change
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.
Orbit calls, Bizleen never calls back
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.
One secret per venue, never a public identifier
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.
Access to sensitive data follows the role, never the rota
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
Moving a catalogue and reservations between two databases that share nothing
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 typed RPC channels, with the venue’s secret on every call and an idempotency registry that replays the original response when a call is repeated. SSO relies on a shared cookie (.bizleen.com) and instantly revokes associated Orbit sessions on sign-out.
Lesson learned
One product does not require one database. What connects two repositories must stay smaller than they are and fully named: four surfaces, seven RPC channels, one secret per venue, no intermediate storage beyond a read-only projection.
That is what lets me deploy one without redeploying the other, and verify every step of the pipeline in production.
Tech specs
Where it runs Cloudflare Workers · 2 production D1 databases, never shared · R2 · Hono 4 · 3 Durable Objects
| Public site | Astro 6 SSR · Cloudflare Workers · D1 · R2 · Cloudflare Images · Stripe over direct REST · Bizleen Studio |
|---|---|
| Connected workspace | Hono 4 · React 19 · D1 + Drizzle · 3 Durable Objects · Cloudflare Cron · 14 languages |
| Delivered surfaces | iframe + CSP frame-ancestors · Turnstile · Server-to-server fetch · Per-venue bearer token |
| Bridge & SSO | Bidirectional SSO (.bizleen.com) · 7 unified RPC channels · Live ORBIT_SESSIONS binding · Cascade revocation |
| Data | 2 production D1 databases, never shared · 128 tables (41 + 87) · 268 SQL migrations · Isolation per venue |
| Delivery | Resend · Web push autonomous re-subscription · Monthly PDF · Idempotent send lock |
| Tests | Vitest · 28,350 test cases · 528,420 test lines · 70,200+ assertions |