Project
Hocaya Sor — an advice platform serving five brands from one backend
Five separate brands, from vet to lawyer; one codebase, one database, and five separate data worlds that never mix.
The problem
Building an app where you can quickly ask an expert (a vet, a tradesperson, a lawyer, a dietitian, an estate agent) brings a user panel, an expert panel, a case/request flow and messaging along with it. Building that from scratch for every vertical — five backends, five mobile apps — is both expensive and needless repetition.
The solution
A single Express + Prisma + PostgreSQL backend, built with a multi-tenant architecture. The user panel, expert panel, case flow and messaging were written once; each brand (Hocaya Sor, Ustaya Sor and so on) can ship to the App Store with its own colour, logo and mobile interface while sharing the same engine.
The real cost of that decision is not speed but discipline: on a shared engine, a single missing filter shows one brand's data to another. So tenant isolation stopped being a "feature" and became a rule checked again at every new endpoint.
Technology
A detail worth highlighting
Tenant isolation runs through an appId filter on every query — serving five separate brands from one codebase without their data ever mixing. Adding a new vertical (say "Diyetisyene Sor") means defining a new tenant, not standing up a new backend.
Let's talk about a similar problem
If a multi-brand or multi-tenant architecture is on the table, we can talk about where this kind of work gets expensive.