Team & Ownership
A team without explicit ownership defaults to "whoever last touched it" or "whoever Vincent pings." Both are bad: the first punishes the most active engineers, the second is a bottleneck. So ownership is written down, per domain, with two distinct roles.
The rule: every technical domain has an Owner and an Architect, and the two roles can disagree.
Owner vs. Architect
Owner — does the day-to-day work. Default PR reviewer for the domain. Triages bugs. Wins on execution decisions (how it ships, what trade-offs are acceptable).
Architect — owns direction and design decisions. Tagged only on PRs that cross architectural boundaries (new module, schema change, cross-cutting refactor). Wins on direction decisions (what we build, how it's structured).
When Owner and Architect disagree:
- Architect wins on direction.
- Owner wins on execution.
- Vincent breaks ties if they can't resolve.
The disagreement and its resolution get written in the PR or the relevant doc — future decisions reference it instead of re-litigating.
Why split the roles
Most teams collapse Owner and Architect into one "lead." That works until the lead becomes a bottleneck for both shipping and design at the same time. Splitting the roles lets execution scale (route to the Owner) without forcing every design call through the same person.
It also makes mismatches visible. An Owner who never gets to make execution calls is being micromanaged. An Architect who never gets tagged on cross-cutting PRs is being routed around. Either signal is actionable.
People
| Person | Role |
|---|---|
| Vincent | CTO, full-stack |
| Ivan | Mobile lead, full-stack |
| Axel | Founding engineer, infra/data |
| Imad | Voice + LLM expert |
| Swap | Full-stack |
| Quentin | Full-stack (intern) |
| Coline | CEO |
| Carla | Head of Sales / CSM |
| Marceau | CSM + QA |
Domains
| Domain | Owner | Architect | Includes |
|---|---|---|---|
apps/mobile/ | Ivan | Ivan | All mobile features, Maestro QA, EAS releases, RN upgrades, mobile bugs, push notifications, deeplinks |
| Infra + CI/CD + DB ops | Axel | Axel, Vincent, Ivan | Terraform, GCP, Firebase, observability (Pino/Grafana/Loki/Tempo), DB indexes/migrations, backups, security baseline. Ivan co-architects CI/CD (mobile EAS pipelines, shared Actions) |
| Embedded Tellia / Partner APIs | Axel | Axel, Vincent | UdL benchmarking endpoint, partner audio, SSRF, API key admin, partner docs |
| Voice + AI | Imad | Imad, Axel, Vincent | Transcription pipeline (Whisper, BullMQ), LLM agents, Mastra, evals, prompts, model selection, LLM cost tracking |
| Unified Tellia Chat project | Imad | Imad, Axel, Vincent | The 5-phase chat unification plan. Imad leads given his Mastra/LLM background; Vincent stays as architect/advisor |
| Web app + core backend modules | Swap | Swap, Axel, Imad | Feature implementation: Onboarding, Shape-file management, Reports, Workspaces, Meteo. packages/schemas + packages/api-client upkeep |
| Bug triage + test gap | Quentin | Swap, Vincent | Bug triage from Sentry / Grafana / MongoDB; writing tests for untested modules (companies, workspaces, drafts, attachments, reports). Scoped intern project — small surface, real value |
| Product feedback + QA process + Review | Marceau | — | QA, QA automation, product feedback aggregation, user-entries review |
| Customer feedback → eng | Carla + Marceau | Vincent | Aggregate and prioritize customer feedback; engineering pulls from their list |
Code review protocol
- Owner reviews by default. GitHub
CODEOWNERSauto-requests them. - Architect tagged on cross-cutting changes — anything that touches module boundaries, schemas, multi-tenancy, or design patterns.
- Vincent tagged only on auth / money / data-integrity / cross-domain PRs. Not the default reviewer for anything anymore. Tagging Vincent on a routine PR is a signal that the Owner is being routed around — fix the cause, not the symptom.
Operating cadence
- Weekly written async update from each Owner. Friday. Posted in the team channel.
- 30-day check-in with each Owner: scope still right, blockers, authority gaps.
Changing ownership
The table above is the single source of truth. Anyone can propose a change via PR; Vincent merges.
Where the line is
Ownership is for domains, not files. A file may sit inside one domain but get touched by another (e.g. a schema in packages/schemas used by the mobile app) — the Owner of the domain that produced the change is responsible for the review, the Owner of the consuming domain reviews the integration.
TIP
If you don't know who owns the code you're changing, the answer is in the Domains table above. If it's not there, that's the bug — open a PR to fix it.