Knowledge Base
Everything worth keeping gets written down.
This handbook is the public operating system for Kryft. It outlines how we write code, design interfaces, and communicate.
Design
7 articlesTypographic grids, monochrome testing, and visual utility hierarchies.
Design is the argument we make about what matters.Make fast, consistent, defensible design decisions instead of arguing about aesthetics.
A token is a decision with a name.Define, name, and enforce design tokens so the same decision is not made twelve different ways.
Design for speed and utility.Prioritize layout rendering speed, clean typography, and strict utility.
Design for the smallest screen you ship. Expand from there.Approach responsive layouts without writing five separate stylesheets or designing five separate screens.
Not everything that looks the same is the same thing.Decide when a UI pattern becomes a component and when it stays a one-off.
The button label is an instruction, not a decoration.Write clear UI copy for labels, errors, empty states, and tooltips so every word earns its place.
Build software that doesn't need explaining.Internalize these guidelines so they become defaults, not rules you consult mid-project.
Engineering
12 articlesProduction deployment procedures, edge database bindings, and code reviews.
We build things that workThis handbook outlines the practices and operational standards we use to build correct, stable software.
Every dependency is a liabilityWe evaluate, add, and remove third-party packages to keep our dependency graph small and maintainable.
How we handle incidentsWe prioritize system stabilization over root-cause debugging during production outages.
How we review codeWe review code to verify logic, catch edge cases, and prevent latency spikes, leaving formatting to compilers.
Instrument your code before you ship itWe set up logging, error tracking, and metrics dashboards for every service before it handles production traffic.
Record your architectural decisionsWe write Architecture Decision Records (ADRs) to capture the reasons behind our technical choices while they are fresh.
Ship small, isolated changesWe deploy code in small increments to reduce risk and maintain speed.
Test what breaksWe prioritize integration tests over unit tests and eliminate flaky tests within 24 hours.
The on-call rotationWe assign clear ownership of production systems to resolve incidents quickly and distribute the operational burden.
Treat migrations like surgeryWe write, test, and execute database migrations under strict controls to prevent data loss and downtime.
Your laptop should mirror productionWe maintain local environments that match production to prevent configuration drift.
Build software that lastsThis closing chapter checks whether we have internalized our operational values.
Operations
7 articlesStatus reporting standards, client communication rules, and work logs.
Operations is just good habits, written down.Understand why our operations handbook exists and what it protects.
A retro that changes nothing is a meeting that should not exist.Run retrospectives that produce real action items instead of documented complaints.
An estimate is a commitment. Treat it like one.Scope and estimate work so numbers reflect reality and clients can plan around them.
Communicate with facts, not fluff.Talk to clients directly with clear updates, code references, and working software.
Pick tools that disappear and stick with them.Understand the tools we use, why we chose them, and how we expect them to be used.
Start a project right or spend the engagement fixing the start.Establish shared expectations, ownership, and rhythm in the first week of a new client project.
Now do the work.Understand what our operations reduce to and how we know they are working.
Sales
7 articlesTechnical project estimates, scope-defining documents, and intake audits.
Sales is selecting future headachesWhy we filter sales leads aggressively instead of chasing volume.
Closing dealsHow we get contracts signed and deposits paid before starting any work.
Pricing workHow we price projects on complexity and value instead of hourly estimates.
Qualifying inbound workHow we screen leads to filter out time-wasters.
Saying noHow we decline projects that don't fit our stack, capacity, or budget.
Writing proposalsHow we draft proposals that define exact scope and prevent disputes.
The deals we do not make define usWhy protecting engineering time is our main sales goal.
Product
7 articlesSystem spec templates, feature scope-cutting guidelines, and staging reviews.
Product work is choosing what not to build.Understand what product discipline means at a small agency.
Ask users what they do, not what they want.Run practical, scrappy user research that focuses on actual behavior.
Did it work? Go check.Measure whether a shipped feature met its goals, and decide what to do if it failed.
Merge code. Don't release yet.Use feature flags to decouple deployment from release and avoid panicked rollbacks.
The backlog is lying to you.Decide what to build next using a framework that cuts through noise and stakeholder pressure.
Write the spec first, then debate it.Create product specs that define what to build, what to skip, and when a spec is done.
Internalize the handbook.Understand what internalizing these product practices looks like in day to day work.
Security
7 articlesServerless secrets management, API key rotation, and DB access controls.
Security is the floorWhy we treat security as a baseline condition, not an optional layer.
Access ControlHow we grant, scope, and revoke access to our systems.
Data HandlingHow we collect, store, access, and delete client data securely.
Secret ManagementHow we store secrets, who can see them, and how we handle leaks.
Third-Party AuditsHow we evaluate and monitor the external dependencies and vendors we bring into projects.
Vulnerability DisclosureHow we receive, fix, and communicate security vulnerability reports.
The core security questionWhy security is about judgment, not compliance.
Support
7 articlesPlatform incident response, bug tracking logs, and recovery plans.
Support is the productWhy we treat support requests as critical design and code feedback.
Bug ReportingHow we document bugs in Linear with reproduction steps, environments, and expected behavior before writing a fix.
Client EscalationsHow we assign contact points, run calls, and document resolutions during client crises.
Knowledge BaseHow we document runbooks and repeatable fixes in Notion.
Postmortems: SupportHow we run blameless, action-oriented reviews for major incidents and repeated bugs.
Triage and ResponseHow we classify support requests and update clients on a schedule.
Fix things for realWhy support is about building judgment, not just following checklists.
Purpose
Why we publish this
We publish our handbook openly to make our engineering standards visible to everyone. This ensures that new team members can ramp up instantly, clients know exactly what to expect from our delivery flow, and we avoid repeating mistakes.
If we find myself repeating a guideline or correcting a structure twice, we write it down. The handbook is a living knowledge base, continually updated from the work floor.