One Quiet Evening

I remember a quiet evening, laptop open, VS Code still running from earlier in the day. A half-finished side project stared back at me, and a cup of chai brewed beside the keyboard. I was stuck in that familiar limbo between ideas – too many GitHub repos collecting dust, not enough shipping. On a whim, I cracked open Million Dollar Weekend. I didn’t know what to expect. A get-rich-quick gimmick? Instead, I found a mirror. Page after page, it felt like Noah Kagan (the author) was peering over my shoulder at my unlaunched projects and saying, “So, are you gonna build something or what?”

As a developer who’s always seeking ways to break through self-imposed limits – to scale not just systems but my own life – this book hit different. It wasn’t a generic “hustle harder” mantra. It was more like a candid code review for my mindset. In the same way we optimize code by finding bottlenecks, Million Dollar Weekend started pointing out the mental bottlenecks that kept me from deploying my ideas. One chapter in, and I already felt like I was having a late-night coffee with a senior dev who’s giving me the tough love I didn’t know I needed.

The Developer Struggle is Real

Before I dive into the book’s lessons, let me confess some of my own bugs (you might recognise a few in your own system):

• Perfectionism – I’d polish a side project endlessly, telling myself “just one more feature and it’ll be launch-ready.” Spoiler: “one more feature” was a never-ending loop.

• Shiny Tech Syndrome – Guilty. I’d jump between the latest JS framework or cloud tool, convinced that this would make my project 10x better. In reality, it just reset my progress to 0.

• Too Many Unfinished Projects – My /projects folder is a graveyard of ideas that never saw the light of day. I’ve started things that never even made it to a 0.1 release because I kept waiting to make them perfect.

• Impostor Syndrome – The voice that says, “Who am I to launch this? There are better developers out there.” So I’d over-prepare and overthink as a stalling tactic.

• Fear of Public Launch – Let’s be honest: hitting “Publish” or opening a repo can be scarier than rm -rf /. What if no one cares? Or worse, what if people do care and judge it?

Reading Million Dollar Weekend was like having these struggles refactored in front of me. Kagan doesn’t just identify these traps – he calls them out with no fluff. The need for more research, more polish, more anything before starting is just another form of procrastination that paralyses would-be creators. That hit hard, because I saw myself in that line. All my elaborate planning and learning was often just a way to delay the real test: putting something out into the world.

Why Developers Should Read It?

If you write code, you know the thrill of seeing a program run successfully. Now imagine getting that thrill from seeing an idea run in real life. That’s what this book is about – moving from code to outcome, from idea to impact. As developers, we’re great at tinkering in code, but we sometimes forget that no one really cares about our code until it solves their problem. Kagan drives this home:

Customers don't care about your ideas; they care about whether you can solve their problems.

In dev-speak: no one’s starring your GitHub repo until it actually helps them in some way.

This book matters for devs because it reframes action as something we can engineer. It treats taking action like building a feature – something you can learn, iterate on, and improve. Instead of mystical “entrepreneurial spirit,” it gives you a playbook (almost like pseudocode) for going from zero to one. It’s full of insights that translate surprisingly well to our world:

• “Now, Not How” Mindset: Stop over-engineering the solution in your head; build a quick prototype of your life. We’d never write a full system without a single test run, so why live that way?

• User Feedback > Theoretical Perfect Product: Just like we need user testing, you need to test your ideas with real people now, not after you’ve perfected them. A crappy command-line tool that solves someone’s pain is worth more than a polished app no one needs.

• Overcoming Excuses: The book systematically knocks down excuses (no time, no money, not expert enough – you name it). Reading it, I felt a bit called out and a lot inspired. For every excuse, there was a counter:

  • Don’t have time? Prioritise and make time.

  • Worried it’s not perfect? Good – ship it anyway and learn as you go.

  • Afraid to put yourself out there? Others have felt that too, and pushed past it.

In short, Million Dollar Weekend is the kick in the pants that us chronically hesitant developers need. It’s the reminder that our skills don’t fully matter until we apply them to something real, something that reaches people. And Kagan delivers this message in a way that feels like your tech friend who’s a bit ahead in the game giving you frank advice over coffee.

What You Actually Need to Launch

One theme that resonated with me deeply: having the code is not enough; you need the courage to launch it. I’ve spent years accumulating programming knowledge, learning frameworks, refining my coding style – thinking that if I just code well enough, success will follow. But the hardest algorithm to optimiSe was my own fear of launching.

Kagan’s blunt motto in the book is “Just f***ing start.” It’s literally the title of Chapter 1, Begin Before You Are Ready.

That unapologetic push to take the leap hit me like a code review comment in all caps. He argues – and I’m now convinced – that the winners aren’t the ones with perfect code, but the ones who put something out there.

For us devs, this is like deploying to prod on day one. Terrifying? Yes. But you learn more from one deployment (even if it fails) than from a year of local builds. Code vs. Courage means I had to confront a tough truth: I wasn’t missing a framework or a feature, I was missing guts. The courage to hit “Launch” when my inner voice screamed it wasn’t ready. The courage to ask someone to try my app, or to charge for a tool I made.

One of the most empowering realisations was that courage is a skill you build. The book suggests treating it like a muscle – you strengthen it by reps. Say, by doing small bold acts regularly. (Kagan even recommends wild exercises like the “Coffee Challenge” – asking a barista for a discount, just to practice being okay with rejection and awkwardness. Talk about stepping out of the comfort zone!). The specifics might sound silly, but the principle is gold: if you push your comfort zone in little ways, you’ll have the nerve to tackle the big stuff, like launching that app or startup you've been dreaming about.

Bottom line: If you have 100 side-projects worth of code but zero that are public, it might be time to focus less on code and more on courage. I’m saying this to myself as much as to anyone else. This book made me realise that my repository of unfinished projects wasn’t due to lack of coding time or talent – it was a lack of courage to share them with the world.

Breaking the Loop

Ever find yourself in an infinite loop of “think, plan, think, plan” and never actually execute? That was me. I’d map out grand architectures in my head, sketch feature roadmaps, compare tech stacks… and stall. It’s like writing a 10-page design document and never writing the actual code. Million Dollar Weekend basically yelled at me (in a friendly way) to break out of that loop. The cure? Action. Fast, imperfect action.

One of the book’s core lessons is that speed is clarity. When you move quickly, you force clarity upon yourself. It’s akin to how in software development a rapid prototype teaches you more in a day than weeks of theoretical spec-writing. There’s a line in the book that essentially says:

Start before you feel ready, because action leads to learning and growth. Or as I like to rephrase it, “Ship it, and you’ll figure it out as you go.”

I had to admit, whenever I did hackathons or quick-and-dirty prototypes, I learned a ton – way more than when I spent forever reading docs without coding. Yet, with my own ideas I was doing the opposite: endless overthinking. The book pushed me to treat my projects more like a hackathon and less like a moon landing. Shipping fast breaks analysis paralysis. Once something is out there, you get actual feedback (users, errors, etc.), and that feedback is worth dozens of hypothetical scenarios.

A great example from Million Dollar Weekend is the idea of validating an idea in 48 hours:

If you can find a few people willing to pay for your concept in a weekend, you’re onto something.

This forced timeline is genius because you don’t have time to overthink — you have to strip the idea to its core value and act. I realised I could apply this to side projects: instead of planning every feature, what if I challenged myself to get one real user or one functional demo by the end of the weekend? That kind of constraint cuts through a lot of BS.

So how do we break the overthinking loop as devs? Here’s what I’m doing now, inspired by the book: whenever I catch myself spiraling into “I should research a bit more before I start coding this idea,” I stop and ask, “What’s the smallest test I can run right now?” Maybe it’s a 10-minute ugly prototype. Maybe it’s emailing a friend who might be the target user to ask if they’d even want this. Anything that produces a real outcome beats another evening of theory-crafting. It’s uncomfortable for sure – shipping something half-baked feels against our developer instincts – but I remind myself that an MVP in the wild beats a perfect plan on paper every time.

The Psychology of Action

After years of being stuck in my habits, I realised I needed to rewire how my brain approaches taking action. We’re used to debugging our code; this was about debugging my mindset. Million Dollar Weekend digs into the psychology of why we hesitate and how to fix it in a very pragmatic way.

One concept that struck me was treating rejection and failure as mere signals, not stop signs. As a developer, I’m used to compilers spitting out errors – I don’t quit coding when I see errors; I treat them as feedback to fix the code. What if I approached life and projects the same way? The book actually suggests setting “rejection goals” – like aiming to get a certain number of no’s or failures under your belt. At first, that sounds insane. Why would I want to fail or get rejected? But then it clicked: if you’re not hitting any rejections, you’re probably not pushing your limits or asking for much. It reframes a “no” from the world as progress – you’re one attempt closer to a yes.

For me, this hit home in the context of launching projects. I feared putting something out there because it might flop or people might criticise it. But Kagan’s approach is:

Expect some flops, even welcome them. They’re part of the process. He even reminds us that “experiments are supposed to fail”[8] – that’s how you learn.

Reading that was oddly comforting. It’s like being given permission to mess up, as long as you mess up while trying. This is basically how we debug code; we run it, see it break, learn, and iterate. Why not apply the same iterative mindset to building a startup or launching a side project?

Another psychological barrier the book helped me with is imposter syndrome. It doesn’t address it by name, but the ethos is everywhere: stop worrying about being the best or an “expert” and just help someone with what you know. It dawned on me that every time I delayed launching something due to self-doubt, I was making it about me (how I’d be perceived) rather than about whoever could benefit from my app or tool. By flipping that mindset – focusing on the people I could help or the problem I could solve – action becomes easier. You’re not putting yourself on stage to be judged; you’re delivering value, and feedback (even negative) just tells you how to deliver more or better value next time.

In practical terms, I started doing little things to rewire my “dev brain” for action:

• Tiny Acts of Boldness: Like pushing code to a public repo even if it’s not perfect, or tweeting about an idea before it’s fully formed to gauge interest. Each time, it gets a bit easier.

• Gamifying Action: I kind of make a game out of it now. e.g., “Can I get 5 rejections this month from pitching my project to people?” Sounds weird, but if I hit 5, it means I actually asked at least 5 people (which is 5 more than if I stayed shy). And who knows, one of those might be a yes.

• Communities and Accountability: I told a few dev friends about the book and my goal to launch something by a certain date. Just like a stand-up meeting keeps you accountable on code, having peers know your goals helps you stick to them. We’re even considering a mini “ship it” challenge together.

Rewiring our mindset is like refactoring a legacy codebase – it takes effort, and the old patterns (habits, fears) are still lurking ready to cause regression. But with repetition, the new patterns start to stick. I’m finding that the more I practice this action-oriented approach, the more natural it feels. It’s oddly liberating to treat life a bit more like a coding experiment: try things, expect bugs, fix forward.

My Next Steps (An Honest Reflection)

I finished Million Dollar Weekend feeling a mix of fired-up excitement and “why have I been like this for years?!” frustration with myself. But I’ll take that over feeling stuck any day. The real question is: what am I going to do differently now? It’s easy to feel motivated after reading a book; the trick is to act on it. So here’s my plan, laid out like a dev roadmap, and a real example I’m already working on:

1. Embracing “Now, Not How”

I’ve printed a little sticky note for my monitor with “NOW ➜ not HOW”. This is to remind me to act first, then figure it out. For instance, instead of spending a week choosing the perfect tech stack, I just used what I know best and built the core in a day. Surprise, it works! The old me would have spent that day reading about which database scales better for when I have a million users (ha!). The new me is like, “Let’s worry about a million users when we have, say, 10.” This shift is already making me more productive.

2. Seeking Feedback Early

I’m pushing myself to share early drafts and prototypes for feedback. Whether it’s a blog post (like this one!) or a code snippet, I’m sending it out sooner. It’s a bit nerve-wracking, but here’s what I found: people are generally supportive, and their suggestions are gold. It’s like code review – scary before you do it, incredibly helpful after you get the comments.

3. Staying Accountable

I roped in a fellow developer friend as an accountability partner. We check in weekly on our progress – what did we ship this week, what rejections or learnings did we get, what’s the plan for next week. This mirrors one of the book’s tips about having an accountability partner to keep you on track. It’s amazing how knowing you have to report progress can push you to avoid slacking. It’s like pair programming for productivity. (Don’t find one? HMU)

4. Continuous “Deployments” to Life

Ultimately, I want to treat my personal growth and projects like an agile project – continuous integration and deployment. Rather than one big reveal, I’ll try to make incremental improvements or releases regularly. Write that blog post series one part at a time. Roll out a new feature to my app every few days. Basically, keep the ball rolling so momentum keeps building.

Finally, I want to say this: If you’re a developer reading this and any of it felt uncomfortably familiar, consider this your invitation (or challenge) to shake things up. Million Dollar Weekend is worth your time, but only if you’re willing to do something with what it teaches. Don’t just read it and nod; use it as fuel. Start that project today, even if it’s clunky. Email that potential user or mentor now, even if you’re afraid they’ll say no. Push your work out of the cozy development branch and into production – your life’s production environment.

I’m done waiting for “perfect” and over-planning in the shadows. The next chapter for me is all about action. As I close this out (and push it live, gulp), I’ll leave you with the same question I had to ask myself:

What will you ship by next weekend?

Go on, grab that idea and give it a go. I’ll be cheering for you – and more importantly, I’ll be coding and launching right alongside you. Happy shipping! 🚀

If you ever need help or just want to chat, DM me on Twitter / X or LinkedIn.

Kartik Mehta

X / LinkedIn