📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Goldfein ran engineering at Facebook and VMware and lays out how release process should change as a team grows from one person to many. She is explicit that the right process for three people is not the right process for three hundred, which is exactly the trap this question is about. Read it to calibrate how little process you actually need at the first-hire stage.
From
First Round Review
by Jocelyn Goldfein
20 min read
- Match the ceremony to your team size, not to the company you admire
- Add process to solve a real pain you have felt, not one you imagine
- A small team can ship fast and safely with very few rules
Open
review.firstround.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
Holman was an early GitHub engineer and this is the single most complete plain English essay on what a healthy deploy looks like, covering branches, staging, code review, and rollbacks without turning it into heavy process. He is clear that the goal is confidence, not paperwork, so you keep shipping often. Use it as the menu you pick two or three things from, not a checklist to adopt whole.
From
zachholman.com
by Zach Holman
30 min read
- A good deploy is boring, reversible, and frequent
- Keep the main branch always deployable and review risky changes
- A fast rollback matters more than preventing every mistake
Open
zachholman.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Orosz maps the full spectrum from YOLO shipping (change it in prod and watch) to heavy multi stage verification, and explains which stage of company each one fits. That framing lets you place your three person team honestly and add only the next layer, not five. It is the clearest guide to deciding how much verification is enough right now. The full spectrum is free to read before the piece turns to paid subscribers.
From
The Pragmatic Engineer
by Gergely Orosz
25 min read
- Verification layers should grow with the cost of a bug, not all at once
- Local checks and CI on every pull request are the cheap early wins
- Most heavy release process exists to protect large user bases you do not have yet
Open
newsletter.pragmaticengineer.com →
📖 Book
✓ Link checked
Paid
Intermediate
Why we picked it
Once you have a second engineer, the question stops being taste and starts being: what actually keeps a team shipping fast without breaking things. This book answers that with data from thousands of teams, and its four measures (how often you deploy, how long a change takes to reach prod, how often changes fail, how fast you recover) give a solo founder turned tech lead a shared scoreboard instead of opinions. Read it as the evidence base for why lightweight process and frequent small deploys beat big cautious releases, then pick one or two metrics to watch.
From
IT Revolution Press
by Nicole Forsgren, Jez Humble, and Gene Kim
~250 pages
- Speed and stability are not a trade-off: the teams that deploy most often are also the ones that break prod least, which is the whole case for shipping small and often as you grow past one person.
- Four metrics tell you if your shipping process is healthy: deployment frequency, lead time for changes, change failure rate, and time to recover.
- The findings come from surveying thousands of organizations, so this is evidence rather than one person's playbook, which makes it a solid anchor when you and your first hire disagree on process.
Open
itrevolution.com →
📄 Article
✓ Link checked
Free
Advanced
Why we picked it
Explains how to keep every change ready to release at any time, which is the technical backbone of a weekly staging link. It helps you ask your dev team the right questions about deploying on demand rather than saving work for a monthly push. Pairs well with the small batches page.
From
DORA (Google Cloud)
~10 min read
- Aim to release any change quickly and safely on demand.
- Keep work in a deployable state instead of batching it.
- On demand releases depend on small batches and automation.
Open
dora.dev →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Majors argues that instead of piling on pre deploy gates, you invest in fast deploys, good observability, and quick rollback so problems are caught and fixed in minutes. For a tiny team this is freeing: you do not need a giant staging apparatus if you can see and undo a bad change quickly. It reframes safety as recovery speed rather than ceremony.
From
Honeycomb Blog
by Charity Majors
12 min read
- Shipping fast plus fast rollback beats slow, heavily gated releases
- You cannot fully replicate production, so watch production closely
- Aim for a short time from merge to deploy, ideally minutes
Open
honeycomb.io →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Flags let you merge and deploy unfinished or risky work while keeping it switched off, so you avoid long lived branches and can turn a bad feature off without a redeploy. That is a cheap safety net that fits two people and removes a lot of the fear that pushes founders toward heavy process. This piece covers the useful patterns and the ones that create mess later.
From
martinfowler.com
by Pete Hodgson
30 min read
- A flag decouples deploying code from releasing a feature
- A kill switch is a rollback you can flip in seconds
- Remove stale flags so they do not become permanent debt
Open
martinfowler.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Once a second person is committing, the first real risk is two branches drifting apart, and this essay explains the one habit that prevents it: integrate to a shared main every day with automated checks. It is arguably the single highest value practice to adopt at the first hire. Read it to understand why short lived branches and a green build matter more than elaborate approval flows.
From
martinfowler.com
by Martin Fowler
30 min read
- Merge to a shared main at least daily to avoid painful integrations
- Every integration should trigger an automated build and tests
- Keep the build green so main is always safe to ship
Open
martinfowler.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
A focused reference on the simplest branching model that works for small teams: short lived branches off one trunk, merged fast. It spells out the version scaled down for a couple of engineers, so you do not accidentally adopt a complex GitFlow setup built for large release trains. Use it to pick a branching rule you can write in one sentence.
From
trunkbaseddevelopment.com
by Paul Hammant
Reference site
- Keep branches short lived and merge them within a day or two
- One trunk that stays releasable beats many long running branches
- Small teams can commit to trunk directly or via quick pull requests
Open
trunkbaseddevelopment.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
The most practical single lever for making code review fast and painless is keeping each change small, and Google's guide explains exactly why and how. Small reviewable changes are what let review stay light instead of becoming a bottleneck that tempts you to skip it. This is the habit to set on day one with your first engineer.
From
Google Engineering Practices
by Google
10 min read
- Small changes get reviewed faster and merged sooner
- Around a hundred lines is a comfortable review size
- Splitting work into small pieces keeps momentum and quality
Open
google.github.io →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Founders often swing between rubber stamping and nitpicking every line, and this sets a sane bar: approve once the change improves the codebase, not once it is perfect. That principle keeps review from becoming the ceremony that kills your speed. Read it to agree with your first hire on what review is actually for.
From
Google Engineering Practices
by Google
10 min read
- Approve when a change improves overall code health, not when flawless
- Reviewers focus on design and correctness, not personal preference
- Do not let the pursuit of perfect block a clear improvement
Open
google.github.io →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
When a deploy breaks and it is no longer just you, how you react sets the culture for years, and this chapter makes the case for blameless review that fixes the system rather than the person. For a founder and a first engineer, this is what keeps them shipping confidently instead of freezing up after a mistake. It is short and immediately usable.
From
Google SRE Book
by Google SRE
20 min read
- Blame free reviews get people to surface problems instead of hiding them
- Fix the process and the safeguards, not the individual
- Write down what happened so the same failure does not repeat
Open
sre.google →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This short principle explains why separating the build, the release, and the run steps gives you clean versioned releases you can roll back to instantly. It is the mental model behind a rollback button, and internalizing it early keeps your deploy setup sane as it grows. Five minutes that pays off the first time a deploy goes wrong.
From
12factor.net
by Adam Wiggins
5 min read
- Give every release a unique, immutable version id
- Separating build from run is what makes rollback a one step action
- Never edit code live in production, always cut a new release
Open
12factor.net →
📄 Article
✓ Link checked
India
Free
Advanced
Why we picked it
The CTO of India's largest broker explains how a tiny team scales huge load by optimizing the application before touching infrastructure or rewriting. It is a strong reminder that hitting a limit usually means fixing the slow query, not rebuilding the system. A grounded Indian counterweight to the belief that scale requires a from-scratch rewrite.
From
Zerodha Tech Blog
by Kailash Nadh
15 min read
- Exhaust easy optimizations in the app before rebuilding
- Most bottlenecks are the database, not the platform
- Simple, boring, well understood setups scale further than you think
Open
zerodha.tech →
