It happened to me.

I remember some years ago, I could sit down on a Friday night, throw some code together over a weekend, and by Sunday evening, I’d have a working prototype to test an idea. It was messy, but it lived.

Lately, it’s been different. Even with the massive boost from AI tooling, which should be making me faster, I’ve found myself paralyzed. I spent a full weekend recently not coding, but thinking. I was obsessing over the “best” directory structure, how to optimize my database entities for long term growth, and a dozen other architectural patterns that honestly make zero sense for a weekend project.

I’ve been institutionalized. I’m applying “Day 1,000” corporate problems to a “Day 1” weekend project.

The corporate trap

When you work in tech or high growth startups, you’re trained to worry about technical debt. You’re taught that you are required to find the sweet spot between “moving fast” and “future proofing” the code you write. Basically it needs to work for 80% of the cases and we can deal with the 20% left when it becomes a problem.

But for a solo dev trying to find product market fit, over engineering is the ultimate technical debt. It’s time spent on features and abstractions for users that don’t even exist yet. I need to stop building a skyscraper foundation for a camping tent.

Now what?

I need to break the chains. I need to unlearn the professional habits that are actually just fancy ways of procrastinating. I am going back to basics: building things that might break, as long as they work right now.

The plan

I’m setting a hard line in the sand to keep myself from falling back into the “institutional” trap.

  1. The 60-Hour Rule: A weekend project is a weekend project. No excuses. If I can’t ship a functional MVP in under 60 hours, the scope is too big or I’m overthinking it. Get shit done, then polish—if it survives.
  2. Public Accountability: I’ll blog or vlog about my progress. Nothing cures over engineering like the pressure of showing people your progress. It forces you to focus on the “what” instead of the “how.”
  3. The Goal: My goal for 2026 is to end the year with €1,000 total side project revenue. The ultimate goal would be to have a possitive balance by the end of the year.

This isn’t about writing clean, perfect, performant and professional code anymore; it’s about getting shit done. If the code is ugly but the solution is real, I win.