Fast by Default is a software development model created by Den Odell. It treats performance as a first-class requirement, shaping decisions in architecture, code, testing, deployment, and team habits. The goal is to build systems where speed and responsiveness emerge naturally from everyday work instead of 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."
Fast by Default breaks the Performance Decay Cycle—the predictable loop of shipping, complaining, panicking, patching, and repeating that plagues most engineering teams. Instead of treating speed as something to fix later, it becomes a natural outcome of how the team builds software every day.
A System Is Fast by Default When:
- 1Architecture creates room for speed by avoiding designs that guarantee slow behaviour.
- 2Developers see performance impact during daily work, not weeks later.
- 3Budgets and checks run automatically, preventing regressions from reaching production.
- 4Real user data shapes decisions, and teams respond based on what users actually experience.
- 5Speed is a shared responsibility, with team members across roles protecting responsiveness for all users, devices, and regions.
The Seven Principles
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.
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.
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.
Optimise Complete User Flows
Users experience journeys, not single pages. Test and improve full flows, including transitions, loading states, and interactions between steps.
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.
Treat Performance as a Shared Responsibility
Speed is a team outcome. Everyone plays a part, from backend and frontend to design, QA, and DevOps.
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.
Start Here
If you do nothing else, start with these three moves.
One principle
Design for speed before you write code. Treat performance as a requirement, not a rescue mission.
One practice
Make performance visible during development. Show long tasks, bundle size, and blocking operations as you work.
One check
Add a simple budget for JavaScript size or API latency and enforce it automatically.
Taken together, these three actions move a team out of the performance decay cycle and into the Fast by Default mindset.
The Fast by Default Cycle
A Simple Recurring Loop
Fast by Default uses a simple recurring loop that keeps systems fast as they grow.
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 steps are the tactical actions inside the larger Fast by Default Cycle. They describe what teams do day to day while the bigger loop keeps performance healthy over time.
These are the hands-on actions teams take inside the cycle. Together they create a continuous loop that keeps systems fast as they grow.
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.
Is Your Team Fast by Default?
Use this quick self-check to see where your team stands today.
Answer yes or no to each question:
- 1Do you catch performance problems during development rather than after release?
- 2Are performance budgets defined and enforced automatically in CI?
- 3Do you use real user data to decide which performance issues to fix first?
- 4Do developers see the performance impact of their changes as they work?
- 5Do you run a regular cleanup cycle that removes dead code and unnecessary complexity?
If you answered no to more than two questions, your team is probably working inside the performance decay cycle.
The Fast by Default model offers a way out by making performance part of everyday work instead of emergency work.