How we work.
Openly.
These aren't values on a wall. They're the rules our team follows on every project — written down, agreed upon, and published here because we think you deserve to know.
Quality
Non-negotiable.
- We do not ship work we would not trust to run in production over a weekend.
- Speed comes from doing things right the first time, not from skipping reviews, tests, or documentation.
- "Good enough for the demo" is not good enough for main.
- Hope is not a deployment strategy.
“Done is binary. Partially-done work stays behind a feature flag — it does not get merged to keep the burndown looking good.”
Definition of DoneHonesty
About status, estimates, and what we don't know.
- A red status raised early is more valuable than a green status that turns red the day before a deadline.
- We do not green-wash. If something is at risk, it is reported at risk.
- "I don't know" is a complete and acceptable answer. Guessing in front of clients is not.
- We are here to deliver the product, not to assign blame. When something fails, we find the cause, not the culprit.
- If a single person could break production, the system has a bug — not the person.
“Escalating is not a failure — it is honest status reporting.”
EscalationTransparency
Visibility is not something clients have to ask for.
- Status is visible, not requested. Burndown, risks, and blockers are kept current — always.
- Decisions in writing within 24 hours. If it isn't written down, it didn't happen.
- No tribal knowledge. If only one person knows it, that is a documentation bug, not a feature.
- No surprise architecture. Specs and designs are shared for comment before they freeze.
- Disagreement is welcome and expected. Silent disagreement is not.
“Postmortems describe what happened, what we learned, and what we will change — never who is to blame.”
Incident ResponseSpec-Driven
We design before we code.
- Every meaningful change starts with a written spec that captures the problem, the approach, and the trade-offs.
- Code without a spec is not ready for review.
- The spec is a contract: the implementation matches the spec, or the spec gets updated first.
- Drift between spec and code is a bug.
“Approve a pull request only when you would be willing to be on-call for the change.”
Code ReviewDefinition of Done
- The change is covered by a spec or design doc.
- Code review passed — at least one approval from someone other than the author.
- New code has tests covering the happy path and obvious failure modes.
- CI is green: build, lint, unit and integration tests pass.
- No new secrets committed; dependency scan is clean.
- New code emits the metrics and logs it needs to be diagnosed in production.
- User-facing documentation is updated.
- Done is binary. Partially-done work stays behind a feature flag.
Code Review
- Be specific. "This is wrong" is not feedback; "this race condition triggers when X" is.
- Tag comment intent: nit, question, suggestion, blocking.
- Approve when you would be willing to be on-call for the change.
- Disagreements escalate after one round of clarification — we do not litigate in 30 comments.
Incident Response
- Stabilize before you investigate. Restore service first; find the root cause second.
- Communicate. For major incidents, post status every 30 minutes until resolved.
- Any incident gets a Root Cause Analysis within 24 hours of resolution.
- Postmortems are blameless. They describe what happened, what we learned, and what we will change — never who is to blame.
These are the standards we hold ourselves to. If that sounds like the kind of team you want building with you, let's talk.
Start a project