Standards and Practices Our Delivery Pods Run On

Every pod we deploy runs on the same operating standards, regardless of stack, industry, or engagement length. These aren't aspirational — they're the baseline a pod is expected to meet from sprint one. This is that standard, published so you know exactly what you're getting before the pod starts.

Sprint cadence

• One-week or two-week sprints, set at scoping and fixed for the engagement — no sliding sprint boundaries.
• A demo at the end of every sprint, showing working software, not a status slide. If there's nothing to demo, that's a signal to raise immediately, not at the next sync.
• Weekly syncs with the client, separate from the sprint demo — for scope questions, blockers, and priority calls that shouldn't wait for a sprint boundary.

Code review discipline

• Every change gets reviewed by someone other than its author — no exceptions for "small" changes, because small changes are where scope creep and quiet regressions hide.
• AI-assisted code is reviewed like any other engineer's PR. Generation speed doesn't lower the review bar — if anything, AI-assisted PRs get closer scrutiny on the sections the author didn't hand-write.
• Reviews block on correctness and architecture fit, not style. Style is enforced by tooling (linters, formatters) so human review time goes to the things tooling can't catch.

Architecture decisions get written down

• Non-trivial architecture choices get a short decision record: what was decided, what alternatives were considered, and why. Not a full ADR template — a few paragraphs that a future engineer (yours or ours) can read in two minutes and understand the reasoning, not just the outcome.
• Decisions that affect data ownership, security boundaries, or third-party dependencies always get one. This is non-negotiable — it's how you keep full visibility into a codebase you didn't write day-to-day.

Testing is embedded, not bolted on

• Test coverage is a sprint deliverable, not a phase that happens "later." A feature isn't done until its tests are.
• QA Pods embed into the sprint, not into a separate release gate at the end. Defects caught in the same sprint they're introduced cost a fraction of what they cost a release cycle later.
• Automated regression coverage grows every sprint — manual QA fills the gap tooling can't reach yet, not the other way around.

Documentation-as-you-go

• README and setup docs are kept current every sprint, not reconstructed at handoff. If a new engineer can't get a local environment running from the README alone, that's a defect.
• API contracts and integration points get documented at the point they're built, while the reasoning is still fresh — not retrofitted from memory later.

Where AI tooling fits — and where it stops

Every engineer in our network is AI-native by our own evaluation bar (see our hiring guide for exactly what that means). In practice, on every pod, that translates to house rules:

• AI-assisted generation is standard for boilerplate, test scaffolding, and well-understood implementation patterns.
• Architecture decisions, security-sensitive logic, and anything touching data governance are human-reasoned, full stop — AI tooling can draft, but a person owns the decision and the review.
• Nothing generated goes to production without passing the same review bar as hand-written code. Speed of generation never substitutes for review rigor.

Definition of done

A story isn't done when the code compiles. It's done when:

1. It's reviewed and merged.
2. It has test coverage appropriate to its risk (not 100% everywhere — proportionate to what breaks if it's wrong).
3. Documentation reflects the change.
4. It's demoed, working, in the environment it's meant to run in — not just locally.

Why we publish this

Most engagements — staffing agencies especially — don't tell you how the team actually operates until you're already inside the contract. We'd rather you hold us to this before you sign anything. If a pod isn't running this way, that's a scoping conversation, not a surprise six weeks in.