You’ve felt it. That split-second delay when you tap an app and nothing happens. Your thumb hovers. Your brain screams: something’s broken. Then the interface stutters to life, and you’ve already decided—this software is mediocre.
That frustration isn’t just a petty annoyance. It’s a visceral signal that the people who built it don’t respect your time. And in that moment, every shiny feature they crammed in becomes worthless.
Fast software doesn’t just work better. It feels better. It feels like the universe is cooperating with you.
We’ve been lied to. The industry tells us that the competitive advantage lies in features, in AI, in the next big thing. But the most overlooked advantage is something far more primal: the sheer, unadulterated pleasure of speed.
I read an essay by Craig Mod that nailed it. He compared fast software to great margins in a book. You don’t consciously notice the margins, but they make the reading experience feel effortless. Same with speed. You don’t celebrate it until it’s gone. But when it’s there, everything feels more capable, more trustworthy.
Speed isn’t a feature. It’s the foundation that makes every other feature feel good.
Think about the apps you love. Not the ones you tolerate—the ones you actually enjoy opening. They’re snappy. They respond before you finish thinking the command. They make you feel smart, efficient, in control.
Now think about the apps you dread. The ones where every click costs you two seconds of your life. They feel heavy, bloated, disrespectful. You avoid them until you can’t.
This isn’t about milliseconds on a benchmark. It’s about an emotional contract between the software and the human using it. When you deliver speed, you deliver a promise: I value your time. I will not waste it.
But most engineering teams treat speed as a secondary optimization. A nice-to-have. Something to fix in a later sprint, after the feature ship. That’s a catastrophic mistake.
Neutrality on speed is career suicide. Pick a side: fast or irrelevant.
I’ve seen startups burn millions building complex features nobody used, while their competitors won by making the basics feel effortless. Speed is the ultimate moat. It’s hard to replicate because it requires discipline, not just clever algorithms. It demands that every layer—from database queries to animation frames—be tuned for human delight.
Here’s the twist: you don’t need to sacrifice functionality. In fact, speed enhances perceived functionality. A fast app with fewer features beats a slow app with more features every time. Why? Because the brain interprets speed as competence. If the software moves quickly, it must be smart. If it lags, it must be broken.
So stop obsessing over your feature backlog. Start measuring how your software feels in the hands of a real user. Ask them: does it feel alive? Does it keep up with your thinking? If they hesitate, you have a problem that no new feature can solve.
The best software isn’t the most powerful. It’s the most effortless.
Build for the joy of the moment. Prioritize speed like it’s the only thing that matters—because in the end, it just might be.
FAQ
Q: Isn't speed already solved? Modern hardware and frameworks are fast enough.
A: No. Speed is a design principle, not a technical checkbox. Most teams still prioritize features over performance, leading to bloat. Even with fast hardware, poorly optimized code and unnecessary network calls destroy the user experience. The gap between 'good enough' and 'delightful' is enormous—and that gap is where loyalty is won.
Q: How do I convince my team to prioritize speed over features?
A: Stop talking about milliseconds. Start talking about feeling. Run a user test where you compare a fast version of your app against a slow one. Show how users' satisfaction, trust, and willingness to recommend drop with every extra second of load time. Use the 'book margins' analogy: speed is invisible when done right, but its absence is catastrophic.
Q: What if slower software is intentional, like for meditation or deep work apps?
A: That's a different category. Deliberate slowness can be a design choice when it serves a purpose—e.g., calming animations or deliberate pacing. That's not the same as accidental lag. The principle still holds: the speed should match the emotional state you want to evoke. Lag that frustrates is never intentional.