With work stuff — especially in tech — it’s easy to get caught up in the bigness of a problem.
The moment something feels complex, we feel pressure to match it with a complex solution. If it feels too simple, we second-guess ourselves. We stretch for obscure edge cases. We plan for rare conditions that may never happen. And suddenly, a 0.01% scenario eats up 30% of the effort.
It slows things down. Bloats the build. Makes everything scarier than it needs to be — and it’s often unnecessary.
Sure, complex problems can require complex solutions. But they shouldn’t start that way.
In the beginning
I’m going to make a bold generalization:
In the beginning, we probably don’t know what we’re doing.
(And that’s okay! Expected even).
That’s why the first move should be fast, small, and almost comedically simple. You do this for three reasons:
- To overcome the fear of starting.
- To immerse yourself in the problem — feel it firsthand.
- To test assumptions and figure out what actually matters.
Here’s a real example.
When we were building Webflow’s AI Site Builder, we needed a CSS framework to scaffold the generated UI — something we could theme, extend, and evolve over time.
We didn’t start with a slick microsite, polished best practices, or even a name.
We started with a Confluence doc.
It mapped out the parts. How they might fit together. A few loose ideas on customization. It wasn’t perfect — not even close — but it gave the team something to respond to. Something to shape.
So we built on it. We iterated. I think it went through 30+ versions.
And eventually, that scrappy doc became a real framework. With structure. With standards. With its own official documentation.
But none of that would’ve happened if we hadn’t started small.
Pathway
Starting small helps you find the path to the big idea — instead of assuming one.
It keeps you from jumping into polish too early. From adding “the shiny,” “the fancy,” or “the just-in-case.” It keeps your focus on the actual problem — not the temptation to look smart or build something impressive.
Because here’s the truth:
Those unnecessary layers of complexity? They’re enticing. They feed your curiosity more than the problem. And later? They become baggage. Baggage others (and future you) have to manage, untangle, and eventually delete (if they even can).
Against the grain
Starting small often feels wrong.
It feels manual. Messy. Slow. Like wasting time. It feels like scribbling when you “should” be shipping.
In tech — where everything is about automation, scale, and speed — doing things by hand feels almost blasphemous.
But here’s the thing:
You can’t automate what you don’t understand. You can’t scale what you haven’t seen.
Starting small helps you see the system. Build intuition. Get your bearings. Then — and only then — can you decide what to refine, automate, or throw away.
Starting
Starting small isn’t lazy.
It’s disciplined. It’s focused. It’s brave.
Because it means saying:
“I don’t know yet.” “Let’s find out.” “Here’s a first version — let’s mess with it.”
It starts with something small enough to survive the reality of the problem.
Because, as the saying goes:
“No plan survives first contact with the enemy.” – Helmuth von Moltke