BackWhy one backend for four properties
Four products, one identity, one set of shared services — and the reasoning behind not building four backends with SSO bolted on afterwards.
By The RoburnaLabs team ·
Blog
Every team that builds four products in parallel faces the same fork: four independent stacks that will "unify later", or one shared platform from the start. We took the second road, and the reason is not elegance.
People overlap
A Forest volunteer becomes a Builders founder and later hires Labs. With four user tables that is three accounts, three password resets, and a support conversation nobody can join up. With one identity it is one person with three profile extensions.
Shared services get built once
Authentication, consent, media, notifications, documentation, blog, newsletter, contact. Each of those is a week of work, and each would have been built three or four times.
The seams still exist
One backend is not one blob. Each domain owns its own tables, depends on shared modules and never on its siblings, and reads personal data through exactly one path. The boundaries are internal, enforced, and cheap to move — which is the opposite of a distributed system nobody can change.
Share
