RD
Back to portfolio

Case study / Booka

Three products, one database, one team.

Booka is a salon operating platform. A public marketplace where people book, a B2B workspace where salons run their day, and a superadmin console for whoever operates the platform itself. Three audiences, three release rhythms, one set of data underneath them.

Role
Software architect
Ownership
Shared venture with Giulio
Scope
Architecture, delivery, production handover
Shape
Monorepo, three deploy units, one database
Status
In production
Open booka-app.it
01

The constraint

The three products do not move at the same speed. The marketplace changes whenever marketing needs it to. The workspace changes when salons ask for something. The superadmin console barely changes at all, and when it does, nobody outside the company notices.

But they all describe the same world. The same salon. The same booking. The same person, who can be a customer in the morning and a salon owner in the afternoon. Splitting the products was easy. Splitting the data would have been a mistake nobody could undo later.

So the architecture had one job: let three products evolve on their own schedules while keeping one truth about identity, bookings and salons.

02

The fork

Three shapes solve this. Two of them cost more than they look like they cost.

  1. Three repositories

    Each product owns its own codebase, its own pipeline, its own database.

    Authentication, the data client and the design system get written three times and drift apart within a quarter. Every schema change becomes a three-way release negotiation. And the person who is both a customer and a salon owner ends up with two accounts and no way to merge them.

    Rejected. Independence bought at the price of the one thing that had to stay shared.

  2. One application

    A single deploy that shows a different interface depending on who is signed in.

    The cheapest thing to start and the hardest thing to leave. The public marketplace and the internal admin console share a bundle, a release and a blast radius: a marketing deploy can take down the tool used to fix it. Public pages ship code that only administrators should ever hold.

    Rejected. Three audiences with three risk profiles do not belong in one release.

  3. Monorepo, three deploys

    One repository, one shared foundation, three applications deployed separately, one database with explicit environment ownership.

    The boundaries have to be enforced rather than assumed. Shared code needs an owner, cross-imports need to stay illegal, and the pipeline has to know which of the three actually changed. It is more discipline up front than the other two.

    Chosen. It is the only shape where the data stays single and the release does not.

03

What that turned into

Three Next.js applications, deployed separately, on one Supabase foundation. Each environment has an explicit owner, so nobody has to guess which database a given deploy is talking to.

On top of that: a pre-launch funnel, consent and email flows, multilingual routing, a fiscal-readiness path, and transactional communications that are part of the product rather than bolted on after it.

The handover was designed alongside the code. A platform that only its author can deploy is not finished, it is hostage.

04

What this shape buys

The marketplace can ship on a Tuesday afternoon without anyone asking the workspace team for permission, because they are different deploy units.

A schema change is written once, in one place, and every product sees the same truth the moment it lands, because there is one database, not three that agree on a good day.

A person stays one person across all three products. That sounds obvious right up until the moment two separate systems have to be told that the customer booking an appointment and the owner accepting it are the same account.

And the platform moved from validation into commercial operation without a rewrite. The delivery model it started with is the one it still uses.

Want the same decision made on your product?

This is the part of the work I am usually hired for: the point where a product is about to become three products, and the choice made in that week decides what the next two years cost.

hello@robertodrago.dev