Build It Bad (Then Build It Better)

How I Learned to Stop Worrying and Ship It

Perfection is a seductive trap. The longer you wait to get it right, the longer you delay the real learning — which only happens when you’re shipping.

Imagine two people in a pottery class. The first spends an entire year meticulously crafting a single, perfect pot. The second spends the same amount of time making a thousand pots, none of them perfect. Yet by year’s end, nearly all of those thousand imperfect pots are better than the first person’s single careful attempt. This difference matters beyond pottery — it’s a principle that shapes how to build systems, launch products, and grow businesses.

The temptation to architect the perfect system before launching can feel irresistible. But until an idea collides with reality, it’s hard to know what “perfect” even means. Ship quickly and imperfectly, iterate relentlessly, and let each new version teach something valuable. Great systems aren’t born from a flash of brilliance — they evolve from consistent, imperfect action.

I’ve been thinking about this a lot as I’ve been building out the 3PL Directory at Fulfill. We set a goal to add 5,000 new 3PLs to our network this quarter. So we needed to set up a system to ingest a bunch of data, process it, and publish it to our site. Our first scrape returned 25,000 results (with lots of bad/messy data). I immediately fell into the trap of trying to “make this scale”.

But that’s the “one perfect pot” mindset.

Instead, what if I just found a couple 3PLs and added them today? Then did it again tomorrow — but a little better. Then again the next day, each time learning and improving. It’s a hybrid of manual effort and gradual system building, and if I do that for 30 days, not only will I have added a ton of 3PLs, but I’ll also have built something much more resilient, informed by real-world use, not theoretical perfection.

I’ve realized there’s a hidden cost to aiming for a perfect system upfront: complexity. When I tried to build a fully automated, fifteen-step process right from the start, even minor issues turned into major obstacles. If step seven broke a week later, I had to pause everything and spend lots of time and energy reconstructing the mental map of the entire system just to solve a small problem. The cognitive overhead was enormous, and small issues quickly ballooned into large delays.

On the other hand, when I started building simpler, quicker, rougher systems — even if they were messy and manual — they became easier to manage. When something breaks, I can rebuild it the next day without losing momentum. Each rebuild teaches me something new, and each new version gets better. This incremental approach — imperfect, consistent progress — brings clarity and resilience to everything I build, and teaches me way more in the long run.