The Secret To Moving Fast
The conventional wisdom is that startups move fast. But what does moving fast actually mean? After years of building startups, I've come to realize that speed isn't just about typing code faster or working longer hours. It's about making the right tactical decisions about what to build and how to build it.
Here's what I've learned about moving fast:
The most important decision you'll make isn't technical - it's about what problem you're actually trying to solve. When someone asks for a feature, the reflexive response is to start building. But the best engineers I know start by questioning the premise. They ask: "What is the user actually trying to accomplish?" Often, the answer reveals a simpler solution than what was initially proposed.
The second most important principle is to embrace pragmatism ruthlessly. Young founders, especially technical ones, often fall into the trap of building everything "the right way." They spend weeks setting up infrastructure-as-code or writing the perfect test suite. This is the software equivalent of premature optimization. The truth is, in a startup's early days, you can get away with remarkably informal solutions. Your code doesn't need to scale to a million users if you only have ten.
Another counterintuitive truth: the fastest way to build something is often to not build it at all. Use existing services. Pay for tools that save developer time. Copy solutions that work. The most successful startups I know are ruthlessly focused on their core differentiators and aggressively unoriginal about everything else. Look at Cursor.so - they didn't try to build a better code editor from scratch. They took VSCode, which already worked, and focused entirely on adding AI capabilities. That's what moving fast really looks like.
The final thing I've noticed is that the best engineers have a kind of pragmatic humility. They don't try to solve every problem from first principles. When faced with a difficult problem, they look for existing solutions they can adapt. They understand that their job isn't to write the most elegant code - it's to solve problems for users in the most efficient way possible.
Remember: in a startup, speed is a feature. But speed isn't about rushing - it's about being ruthlessly efficient with your time and attention. Focus on what makes your startup different, and be shamelessly pragmatic about everything else.
P.S. "Gradient descent codes better than you."