We could have built “the” project-management application. We preferred a hub — Bench — and satellites: Scoper for scoping, Retroplanning for scheduling, Tally for costs, Timely for the calendar, Roster for the team, Tackler for tasks, Tracer for the log, Shippy for deliverables.
How it holds together
Each satellite is a separate application: its own subdomain, database, repository. What ties them together is a home-made SSO: a signed cookie, valid across the whole artisan-digital.eu domain, carrying the user’s identity. Bench opens the satellite in a tab (an iframe, concretely) and passes it the project id; the satellite checks the signature and shows the right thing. No cookie, no access: it sends you back to Bench.
Why this choice
- Replaceable: if a satellite no longer fits, we rewrite it without touching the others.
- Deployable alone: each tool updates independently, in seconds, through the host’s API.
- Readable: a satellite fits in one person’s head. The monolith does not.
- Sellable separately: Retroplanning has its own customers, without Bench.
The traps
Cross-subdomain SSO demands rigour: the cookie must carry the e-mail, PHP sessions are not shared across subdomains, a “sandboxed” iframe can block the cookie. And drift between code in git and code in production is a silent enemy: we audited it once and do not want to do it again.
Where we are
Bench, Scoper, Retroplanning and ProjectNaming are running. The six satellites are deployed and plugged in, each still showing its “under construction” page: the business logic lands one by one, Tally and Tackler first. Everything is detailed in the showcase.