SellVia Docs — menu
DocsInfrastructure & DevOpsTeam Collaboration Workflow

Team Collaboration Workflow

Infrastructure & DevOps/Team Collaboration Workflow.md
backendUpdated Aug 24, 2026

Team Collaboration Workflow

Purpose

How a two-person team (Backend/complex logic + Frontend/testing) actually works day to day on this codebase — the practical layer on top of Git Repository Strategy, which already designed the repo structure with exactly this split in mind.

Team Split

  • Backend + complex logic — FastAPI, database, business logic, payments/billing, security
  • Frontend + testing — Next.js, UI, QA against Staging, running the automated test suites (Cross-Tenant Isolation Testing, Error-Path Testing)

What's Already Built For This Split

Update (2026-08-24): Per Git Repository Strategy's reversal, the "Monorepo" and "service-prefixed branch naming" bullets below no longer apply — replaced by two separate repos. Kept updated in place (this is an operating doc describing current infra, not a decision log) rather than layered with history.

  • Two separate repos (sellvia-frontend, sellvia-backend) — independent ownership, independent release cadence per person; the coordination overhead this trades away is handled via API/API-CONTRACT-SHEET.md's status column and matching tracking-issue numbers across the two repos' PRs (see Git Repository Strategy's "Coordinating Cross-Cutting Changes")
  • Plain feature branch naming (feature/<thing>) — a service prefix is no longer needed since each repo only ever contains one service's branches
  • Independent CI per repo — a frontend PR doesn't wait on backend tests and vice versa, because they're literally different repos, not because of path-scoped jobs in a shared one
  • Independent deploy paths — frontend (Vercel) and backend (VPS) ship separately, each from its own repo

Task Tracking

GitHub Issues/Projects — no third tool. One board: To Do / In Progress / In Review / Done, each person in their own lane. Avoids fragmenting work-tracking away from where the code already lives.

PR Review

Different rules for different stakes, not one blanket policy:

  • Routine, low-stakes changes (styling, copy, non-critical fixes): self-merge once CI passes — deep cross-specialty review isn't realistic and shouldn't be required for everything
  • Anything touching money, checkout, or the financial chain: the other person reviews before merge, even without deep backend expertise — a second pair of eyes catches obvious mistakes and keeps both people aware of what's changing in the highest-stakes part of the product. Ties directly to 06. Feature Flags Strategy's existing "extra scrutiny for financial-chain changes" rule.

Local Development — Docker (resolved 2026-08-07)

Use Docker for local dev, specifically to avoid environment drift between two different machines — see 06. Docker Strategy for the resolved decision. Production/VPS deployment is unaffected, this is local-only.

Environments

  • Testing happens against Staging, never directly against Production — unchanged from 06. Environment Strategy, now has a concrete owner (the frontend/testing half of the team runs QA passes here before anything promotes)
  • Local → Staging → Production flow is unchanged; both people work the same way through it

Testing Ownership

The frontend/testing half of the team owns:

  • Manual QA pass on Staging before each Production promotion
  • Running and verifying 04. Cross-Tenant Isolation Testing and 06. Error Handling & Logging Pipeline's error-path test suite — doesn't require writing the backend logic being tested, just verifying it catches what it should

Access Checklist for Onboarding a Second Person

  • GitHub repos, write access (sellvia-frontend, sellvia-backend — and sellviadocs if they'll be updating documentation too)
  • Notion workspace (full documentation)
  • Staging environment credentials
  • Design files (Figma or equivalent), if applicable
  • Never Production secrets or live Swich keys (updated 2026-08-23 from Paddle) unless specifically needed for their role

Communication

Not prescribing a specific tool here — a lightweight daily or weekly check-in habit matters more than which app it happens in. Worth agreeing on a cadence explicitly rather than assuming it'll happen organically.

Open Questions

  • None blocking — this is a practical operating doc, revise as the team's actual working rhythm reveals what works.