The parts that break in production.

The demo works, then the first real user arrives. The failures cluster in four places: auth that only exists in the UI, secrets shipped to the browser, code that only ever met the happy path, and money handled as if the network never retries.

Handler, service, repository — where each piece belongs, why internal/ exists, and how to keep the layout readable once you pass ten endpoints.

The three models, what each costs at 10 and at 10.000 tenants, and how row-level isolation fails quietly when you get it wrong.

Why a working window is wall-clock time, not a UTC instant — and how to generate booking slots that stay correct across timezones and a daylight-saving change.

Signing and parsing claims, wiring auth middleware in the right order, and a refresh-token flow that survives a stolen token.

Password hashing, session versus JWT, TOTP two-factor, and password reset — the flows a login tutorial leaves you to figure out alone.

Everyone says authorization belongs on the backend. This shows the full loop — one policy, enforced by the server and rendered by the UI from the same rules, so they never drift.

Verifying the signing secret, surviving duplicate deliveries, and why the webhook — not the redirect — is what confirms an order.

The frontend exports clean. Auth, storage and the data do not. What each piece costs to move, in the order that keeps the app running.

Two different answers to two different problems. Self-hosting moves the ops burden to you and keeps the architecture; owning a backend changes the architecture. When each one is right.

What per-seat scheduling actually costs at 10 and 50 users, what you give up by running it yourself, and the parts nobody warns you about — timezones, DST and double-booking.

MAU pricing, what you actually need versus what they sell, and an honest list of what you take on when you own authentication yourself.