Accelerate for One Person: 24 Capabilities, One Developer

Accelerate describes 24 software delivery capabilities correlated with better performance and team wellbeing. I use 4.

Not because the others are wrong — the research behind the book is solid and the correlations hold. But because most of those capabilities assume something I don't have: a team. Change approval boards require someone to approve. Pair programming requires a pair. Complex governance structures require an organization to govern.

Building Swoin alone, I had to figure out which of the 24 capabilities actually scale down to one person — and which ones, when stripped of their organizational context, become theater.

What I found is that a small number of capabilities produce most of the leverage. If you're building software alone, getting those right matters more than checking off a list.

Accelerate, by Nicole Forsgren, Jez Humble, and Gene Kim, is a research-backed analysis of what distinguishes high-performing software delivery teams from the rest. The underlying data comes from the DORA (DevOps Research and Assessment) studies, which tracked software delivery performance across thousands of organizations over multiple years.

The 24 capabilities they identify are correlations, not prescriptions. That's a distinction the authors are careful about, and I'll be careful about it too: implementing these capabilities doesn't guarantee anything. They're a compass — a way to navigate trade-offs when you don't have clean data about your own situation yet.

With that said, here's what I actually use.

Every merge to main triggers an automated deployment pipeline. No manual steps, no "remember to update the server," no deployment scripts that only run correctly on my machine.

In practice: Swoin runs on Kubernetes. ArgoCD handles the GitOps layer — it watches the repository and reconciles the cluster state with whatever's in main. When I merge a change, it's deployed within minutes. I don't touch the production environment directly.

The leverage at solo scale isn't just avoiding human error (though that's real). It's eliminating deployment as a cognitive task. When deployment is a fact that happens rather than a process I perform, my mental model of what's running in production stays accurate because it's always what's in main. The drift between "what I wrote" and "what's running" approaches zero.

The DORA data shows deployment automation correlates strongly with deployment frequency and lead time for changes. In my experience, those metrics translate directly into iteration speed without fear. I can ship a small change, see the effect in production, and adjust — because the feedback loop between code and running system is short and automatic.

Almost no long-lived feature branches. Code goes into main when it's ready — not when I feel like merging two weeks of divergent work.

This is as much a discipline constraint as a technical practice. Working in small batches means I have to think clearly about what "done enough to integrate" looks like at each step. A half-built feature doesn't sit in a branch accumulating drift. It either ships behind a feature flag, or it doesn't ship yet — but either way, it integrates.

So here's the thing: trunk-based development doesn't make hard problems easier. It makes the failure mode visible faster. When a change breaks something, I know immediately — not three weeks later when I'm merging a branch and untangling two weeks of accumulated conflict that's now impossible to attribute.

For a solo developer, speed of feedback is everything. I can't afford to discover in week 4 that a week 1 architectural decision was wrong. Small batches compress that discovery.

Three test layers: unit tests for domain logic, integration tests for API endpoints and service boundaries, end-to-end tests for critical user journeys via Playwright, run against multiple QA environments.

Writing meaningful tests takes time — sometimes as long as writing the feature itself. It's an honest upfront cost. But the return compounds.

Confidence in the test suite changes how fast I can move. When I make a change and all tests pass, I can ship it without manually verifying 30 things that "might be affected." When a test fails, I know exactly what broke and why. The test suite is a living specification of what the system is supposed to do — and it enforces that specification automatically, every time I push.

At solo scale, comprehensive tests serve a function that's usually handled by other humans: they catch the mistakes I make when I'm tired, when I've been staring at the same code for two hours, when I'm confident about something I shouldn't be confident about. A second pair of eyes that's always available and never needs context.

The investment is front-loaded. The confidence compounds indefinitely.

Catch problems early, without a dedicated operations team.

Swoin has monitoring in place that surfaces errors and performance issues before they become user-visible incidents. Alerts reach me when something is wrong while the problem is still small. This isn't glamorous infrastructure — it's plumbing. But without it, the first indication that something's broken is a user complaint, which means the user has already experienced the failure.

Monitoring closes that feedback loop. It's the difference between finding a problem and being told about one.

For a solo developer without an on-call rotation, this is particularly important. There's no one else watching. If something breaks at 2am on a Sunday and there's no alerting, it stays broken until someone happens to try to use the product. That's not an acceptable operating model.

Change Approval Boards, complex governance frameworks, formal change management processes — these exist because organizations have coordination problems. Multiple teams working on the same codebase need processes to prevent stepping on each other.

When there's one person, the coordination IS the work. Creating the process would be a solo performance with no audience and no benefit. The overhead would consume time without producing value.

I've also deprioritized pair programming and formal code review at this stage. Not because they're without value — they're not — but the cost-benefit calculation looks different at solo scale. What I do instead: AI-assisted review as a second perspective on significant changes, deliberate pauses before merging anything architectural, and a habit of reading my own diffs in the morning with fresh eyes before they go to production.

These four capabilities correlate with delivery performance regardless of team size — that's what the DORA research shows. But when you apply them at solo scale, they serve a different function than what you'd expect from their team context.

They don't make one person faster than a team. They create the conditions where one person can move at a pace that usually requires a team. Each capability eliminates a specific bottleneck:

• Deployment automation removes the deploy-as-bottleneck.

• Trunk-based development removes hidden integration debt.

• Comprehensive testing removes manual verification overhead.

• Monitoring removes operational blindness.

Together, they produce something that's hard to get without them: confidence. Not overconfidence — I still make mistakes. But a grounded confidence about what's in production, what's been tested, what the system actually does. That confidence is what makes it possible to keep moving without accumulating the kind of invisible risk that eventually stops you.

The research suggests these capabilities matter regardless of team size. In my experience building Swoin, they've been the thing that made solo possible.

Swoin is built on this approach — see the product at https://www.swoin.io/p/swoin

Accelerate by Forsgren, Humble, and Kim is worth reading if you care about software delivery performance — correlation vs. causation framing and all