We build things that work
"This handbook outlines the practices and operational standards we use to build correct, stable software."
Hammad MajidWhy this exists
Most engineering handbooks list restrictions and say nothing about operational quality. We wrote this document because the difference between a junior developer and an experienced engineer lies in their operational judgment, which must be taught explicitly.
Operational Flow
Shipping: We deploy small, isolated changes to production frequently.
Safety: We protect database state and system availability through tested migrations and rotation discipline.
Decisions: We record our technical choices in Architecture Decision Records to preserve context.
Observability: We monitor active systems using structured logs and dashboard alerts.
Dependencies: We treat third-party libraries as long-term maintenance liabilities.
Local environments: We configure development setups to mirror production configuration.
What good looks like
- An engineer deploys a feature, updates the local ADR, checks active metrics, and receives no alerts.
- A new developer begins writing code within two hours of cloning the repository.
- You run a database schema change on a Friday afternoon safely because the runbook covers all failure states.
- The on-call handoff is clean because the outgoing engineer logged every recent incident.
What NOT to do
- Do not read these pages once and assume you understand them. The value is in the execution details.
- Do not treat these guidelines as a compliance checklist. Understand the failure modes they prevent.
- Do not use these processes to justify bad outcomes. Operational responsibility remains with the engineer.
Kryft runs a small engineering team. Every service we deploy is maintained by developers who need to sleep and take vacations. We do not have a separate infrastructure or platform team. When production fails at 2:00 AM, the engineer on call resolves the outage. We write code and configure systems to make night pages rare. Our goal is to build software that works reliably, resolve errors quickly when they occur, and prevent repeating failures.
This handbook details how we build systems. Read it through once, and return to specific sections when resolving relevant situations. I have found that the most frustrating engineering failures occur when developers improvise instead of following established procedures, or follow procedures blindly instead of using their judgment. This document outlines where each approach is necessary.