The other day I did this short vibe code hackathon - built a personal finance autopilot in a few hours. Ship it, done. And it felt... refreshing? Took me a bit to figure out why.
I'd forgotten what it felt like to just build and ship without overthinking every decision.
If you're a startup builder, you know the tension. Ship fast or build right? MVP or scalable architecture? Every day you're making these tradeoffs.
Then one day, you get that rare opportunity. Maybe it's your own startup. Maybe it's a greenfield project. Finally, you think, I can build this properly from the start.
That's when we mess it up.
The Startup Builder's Curse
As product engineers, we're supposed to balance speed with quality. We pride ourselves on knowing when to cut corners and when to invest in infrastructure.
But give us a blank cheque? We forget everything we know about shipping.
Suddenly we're not product engineers anymore. We're architects. We're building for a million users when we don't even have ten. We're solving scaling problems for a product that doesn't exist yet.
I've been that person. The one who overengineers everything. Who reads about distributed systems at 2am and dreams about "doing it right" for once. Building the perfect system with every pattern from that conference talk. Every abstraction I've been hoarding in my head.
Meanwhile, the actual requirement was something embarrassingly simple. Something that could have been solved in a day. But I couldn't help myself. I had the freedom, finally, to build it "properly."
The Blank Cheque Problem
A blank cheque still needs an amount written on it. And that amount needs to clear when someone cashes it.
Every architectural decision has a price. Abstractions cost time. "Best practices" add complexity. That blank cheque? It's a loan against future productivity, and the interest compounds fast.
The thing is, those overengineered projects aren't always waste. Sometimes they're R&D. Sometimes they're how we level up our skills. I've pulled patterns from those "failed" projects into production code years later.
The key is knowing when you're building to ship versus building to learn. Both are valid. Just don't confuse them.
When it's time to ship, ship. When it's time to explore and push your skills, do that too. The blank cheque problem happens when we pretend our learning experiments are shipping vehicles.
Finding Your Food Cart
Do you need a restaurant or will a food cart work?
The food cart solves the immediate problem. People get fed. Money comes in. You learn what customers actually want. Maybe it grows into a restaurant later. Maybe it doesn't need to.
But we convince ourselves we need the restaurant from day one. The full kitchen. The dining room. The wine list. When really, we just needed to feed people.
The Two Week Test
What would I build if I only had two weeks?
Not "what's the most scalable architecture?" Not "what would handle a million users?" But what would I ship if the deadline was breathing down my neck?
That constraint - even when it's artificial - keeps me honest. It forces me back into product engineer mode. Ship something. Get feedback. Iterate.
The blank cheque is a trap. It makes us forget that shipping beats planning. That customer feedback beats architectural beauty. That a working product beats a perfect codebase.
Sometimes You Actually Are Building Infrastructure
Here's the nuance though. Sometimes you really do need to build infrastructure. Sometimes that authentication system, that data pipeline, that deployment framework - it's the thing that unlocks velocity later.
The difference? You know you're building infrastructure when you can name three specific features it enables. When you've felt the pain of not having it multiple times. When the time saved next month pays for the time spent this week.
If you're being honest about building infrastructure to ship faster later, go for it. But if you're building infrastructure because it's more fun than talking to users? That's when you need the two week test.
Write the smallest cheque that clears. You can always write another one tomorrow.
Photo by Med Badr Chemmaoui on Unsplash
Content on this blog was created using human and AI-assisted workflows described here. Original ideas and editorial decisions by Justin Quaintance.