Performance Engineering

Fast by Default

Build Fast, Stay Fast
The Philosophy

Fast by Default is a software development model created by Den Odell. It puts performance at the centre of architecture, code, testing, deployment, and team habits. The goal is to build systems where speed and responsiveness emerge naturally from everyday work rather than being retrofitted in a rescue mission after users complain.

"Fast by Default is not a tool or framework. It is a disciplined way of building software that stays fast as it grows."

A System Is Fast by Default When:

  1. 1Architecture creates room for speed by avoiding designs that guarantee slow behaviour.
  2. 2Developers see performance impact during daily work, not weeks later.
  3. 3Budgets and checks run automatically, preventing regressions from reaching production.
  4. 4Real user data shapes decisions, and teams respond based on what users actually experience.
  5. 5Speed is a shared responsibility, with engineers across roles protecting responsiveness for all users, devices, and regions.

The Seven Principles

I

Design for Speed Before You Write Code

Make performance a requirement during planning and architecture. Avoid chains of work, slow dependencies, and designs that guarantee delays.

II

Make Performance Visible During Development

Use tools and workflows that show how each change affects speed. Developers should see slow tasks, blocking operations, and heavy assets as they work.

III

Protect the Experience with Clear Budgets

Set limits for the things that slow users down. Enforce budgets for JavaScript size, API latency, startup cost, memory use, and render time.

IV

Optimise Complete User Flows

Users experience journeys, not single pages. Test and improve full flows, including transitions, loading states, and interactions between steps.

V

Use Real-World Data to Guide Decisions

Base priorities on what users actually feel. Track key metrics in production, including Core Web Vitals, slow interactions, and crashes on real devices.

VI

Treat Performance as a Shared Responsibility

Speed is a team outcome. Everyone plays a part, from backend and frontend to design, QA, and DevOps.

VII

Prevent Decay Through Regular Cleanup and Review

Performance declines naturally over time. Counter this by reviewing dependencies, removing dead code, resetting budgets, and auditing critical flows on a predictable cadence.

The Fast by Default Cycle

A Simple Recurring Loop

Fast by Default uses a simple recurring loop that keeps systems fast as they grow.

Fast byDefaultMeasureBuildOwnMaintain& Refine

1. Measure

Understand what users experience. Quantify cost and identify where speed matters most.

2. Build

Architect and implement systems that behave fast under real conditions.

3. Own

Verify performance continuously with CI, budgets, and workflow visibility.

4. Maintain and Refine

Observe real users, then feed that data back into architecture and development.

How the Cycle Works

It repeats forever.

Measure → Build → Own → Maintain and Refine → back to Measure

A team that follows this cycle does not wait for incidents. Speed stays healthy because the loop runs as part of normal work.

The Five Practical Steps

Hands-On Actions Inside the Cycle

These are the hands-on actions teams take inside the cycle. Together they create a continuous loop that keeps systems fast as they grow.

Fast byDefaultArchitectImplementVerifyObserveRefine

1. Architect

Start with designs that make fast behaviour possible. Reduce critical-path work, keep dependencies shallow, plan caching and data loading early.

2. Implement

Write code with performance feedback available at every step. Developers should see long tasks, heavy bundles, and blocking operations as they build.

3. Verify

Check performance automatically in CI. Enforce budgets, run tests, detect regressions, and block changes that would slow users down.

4. Observe

Measure what real users experience in production. Track Core Web Vitals, latency, slow interactions, and device-level performance at scale.

5. Refine

Feed real-world data back into architecture and development. Fix bottlenecks, reset budgets, simplify flows, and reduce complexity.

How the Steps Work

They repeat in sequence.

Architect → Implement → Verify → Observe → Refine → back to Architect

These practical steps fit within the larger Fast by Default Cycle, ensuring that performance stays healthy as part of everyday work.

Fast by Default Checklist

Architecture

Development

Code Review

CI and Budgets

Testing

Observability

Team Habits

Newsletter

Stay Fast

Get practical performance engineering insights and Fast by Default updates delivered to your inbox.

Powered by Buttondown