Jonathan Bennett

Small but mighty: How teams should start

You’ve probably heard the saying: “If you want to go fast, go alone; if you want to go far, go together.” But when it comes to software startups, this advice misses the mark. Early on, a single skilled developer — or a very small, focused team — will often move faster and build better foundations than a larger group of less experienced developers. Here’s why.

Here’s why the common wisdom falls apart in software development:

Faster Feedback Means Faster Course Corrections

A one-day mistake is easy to fix. A month of going down the wrong path can set you back significantly.

Speed matters most for startups — but not just raw speed. It’s speed of learning and alignment that counts. Micro-pivots let you outpace the competition and build features incumbents can’t anticipate. This is how you discover what truly delights your customers.

Larger, less experienced teams are slower to align and more likely to veer off course — wasting precious time and energy.

Knowing What to Build (and When to Build It Right)

Knowing when to build something “good enough” versus building it the right way is a superpower for developers.

If parts on the edges of your system are just good enough, that’s often fine—you can improve them later. But if core components are only “good enough,” you’re asking for trouble. Since more features depend on these core parts, making changes later is risky and expensive.

Failing to distinguish between the two leads to two kinds of errors: wasting time over-engineering edges, and risking system failure by under-investing in the core.

Why Developer Skill Isn’t a Simple Numbers Game

Developers aren’t interchangeable parts. The idea of a “10x developer” is misleading—not because such developers don’t exist, but because the gap can be much bigger than that.

For example, I worked on a project where a developer built a modal form that would lose your edits if you closed and reopened it. They stored the original values locally and tried to reset the form manually. It took about a week and was still buggy.

I suggested just calling form.reset(), a built-in browser function that fixed the problem in 10 seconds.

Is this a cherry-picked example? Of course. But it highlights how a highly skilled developer can deliver solutions orders of magnitude faster and cleaner than an average developer.

That said, not every developer excels everywhere. I wouldn’t be a 10x developer on a video game 3D engine, for instance.

So What?

At a product’s kickoff, the most valuable asset isn’t just developer speed — it’s how quickly the business learns what works and what doesn’t. Speedy learning lets you pivot early, avoid costly mistakes, and build something customers truly want.

Longevity and scaling come later. For now, focus on getting to that learning faster, even if that means a smaller, highly skilled team rather than a big, inexperienced one.