Skip to main content

Delivery Model

How work moves from idea to production. The short version: epics are broken into small stories, stories land on the development environment continuously, and production gets one promotion per epic — after the whole epic is built and tested.

Epics and stories​

Larger pieces of work are scoped as epics and decomposed into stories — atomic tasks, one concern each, in the smallest shippable units. Each story is sequenced explicitly: which stories can run in parallel, which are serial because they depend on shared state (for example, database migrations).

Stories are committed complete — phased checkpoints are fine on a branch, but a half-finished story doesn't land. Changes that touch migrations, billing, or auth stay in their own small commits so they can be rolled back surgically. An epic is never collapsed into one commit.

How releases work​

  • Stories land on the development environment incrementally. Every story merges and deploys to dev as it finishes, so integration problems surface early.
  • Production promotion happens once per epic. Production is promoted at the epic boundary, after the full epic is built and tested — never story-by-story.
  • Risky changes ship behind feature flags or dark. Where it de-risks the release, new behavior deploys disabled (or invisible) and is switched on separately from the deploy. Migrations go first, ahead of the code that needs them.
  • Every surface has a stated rollback path before promotion. Database changes have a reverse migration; code can be reverted or flag-disabled; configuration changes record the prior value.

Quality gates​

Automated coverage is the default proof of done​

Every story ships with unit/integration tests in the owning repository, green before commit. Coverage targets the highest meaningful level — tests that prove behavior, not vanity percentages. User-facing flows additionally get a browser end-to-end test (Playwright) in the dedicated E2E suite, runnable against the development build, so every shipped behavior has automated regression going forward.

Human testing is reserved for critical, irreversible paths​

Manual QA is deliberately narrow: live interview entry, billing, and auth — the places where a miss is unrecoverable for a user. Everything else is gated by automation, and routine work is not held up waiting for manual testing.

Ticket hygiene​

  • Every task has a Jira ticket (TI-XXX). Work starts by creating or claiming the ticket, and the ticket's status tracks the work as it moves (In Progress → In Review → QA/Testing → Done).
  • Commits reference the ticket. Commit messages start with the ticket key (for example feat(TI-123): …), which links commits, branches, and pull requests onto the ticket automatically. The ticket — not chat — is the audit trail: significant milestones get a ticket comment recording what shipped and how it was verified.
  • Test instructions are written before QA handoff. Before any ticket goes to QA, its description gets numbered, step-by-step test instructions: exact inputs and selections, the expected result for each step, regression checks, and the rollback levers.