The Moment Authenticity Beat the Formula

A year ago, I caught Mike Posner on the My First Million podcast, talking about why he stopped chasing hits. It stuck with me—honestly more than I expected. He was mapping out a feeling I knew well but had never heard anyone name so plainly.

After Posner’s breakout with Cooler Than Me, he spent years trying every “proven” trick people swore would bring back that spark. Chasing what worked before, tweaking ideas for radio, following the trends. None of it landed. He talked about riding that loop so long it started to dull whatever made him want to write music in the first place.

Eventually, Posner hit a wall. He decided, almost out of frustration, to make something for himself instead—like choosing to build software you believe in rather than chasing hits. For the first time in a while, not caring what a record label or a crowd might say. He made what he thought was cool, not what the industry would call a hit.

The result was I Took a Pill in Ibiza. That one changed everything—a global smash, even bigger than the first.

But here’s the thing that really landed for me. Even if it hadn’t taken off, it wouldn’t matter. For once, the work was about him. It lined up with who he was and what he felt—something you could hear in every line.

The same dynamic applies to us, building software and testing ideas with AI. This story isn’t just about music. It’s a playbook for making things that actually matter. So let’s dig into how we can use it.

Why Chasing Formulas Drains Motivation—and How to See It

When you start optimizing everything for the usual proxies—stars, likes, OKRs—it’s easy to slip from craft into compliance without even noticing. The work stops being about making something real, and you end up chasing numbers instead. It feels productive for a while, but the spark gets eaten by the checklist. Here’s what changes with intrinsic motivation for developers when environments support autonomy, competence, and relatedness. Intrinsic motivation goes up—authentic work thrives in those conditions. That’s the difference between building something for your own curiosity and building strictly for applause.

Last year I finally caught myself doing this after hearing Posner re-label it on that podcast. I realized I was defaulting toward patterns—trying to fit my projects into what “should” work instead of what I actually wanted to build. It stuck with me.

Frameworks can be good, but they’re supposed to be tools, not rulers. Best practices are just the starting line. The finish should be yours. If you’re reading this, I hope you take that as permission to keep your own metrics in view.

That’s not to say you can always ignore expectations or skip the frameworks. Working with constraints—team deadlines, client requests, technical limits—is normal. Earlier this year, I was sure I had to stick to every “approved” process to get buy-in. But you can meet those constraints while still prioritizing authenticity. The trick is not letting someone else’s checklist become your definition of success.

It’s sort of like cooking straight from a recipe without ever tasting the food. You might hit every step, but the meal ends up emotionally flat. We remember the meals with a signature—something only you would put in, even if it breaks the usual rules.

How to Define What “Worth It” Means—Before Anyone Else Gets a Say

Let’s pause before you get swept up in building. Name your criteria up front—define success on your terms so the project is worth the energy even if no one else ever claps. I’ll admit, I used to skip this step. It felt awkward, almost unnecessary. Turns out, that’s exactly why I kept spinning my wheels for other people’s approval.

Worried this will eat too much time? Don’t be. Laying this out takes an hour, not a quarter. That single hour recalibrates your direction and saves you weeks—even months—of aimless iteration.

When metrics wobble (and they will), hold onto a line like this. “Sometimes the world will agree with your work, and sometimes it won’t.” Let that be enough.

Honestly, I still skip this step sometimes if the excitement takes over. I know it’s smarter to slow down and set my own goals, but when the idea feels urgent, I just dive in. Maybe that’s a habit I’ll change; maybe not. It’s strange to admit, but it’s true.

How to Pick the Project That Actually Moves You—And Build Software You Believe In Your Way

Start by looking for the problem or idea that actually gets you fired up and build software you believe in, even if it feels a little offbeat. If you’re picking between what seems easy or what feels true, go for the one that lights up real curiosity. I’ve learned to ask myself directly, “Would I care about this if nobody ever saw it?” Weird ideas count too. Sometimes those are the ones that stick. You don’t need permission to chase what feels alive to you; that energy is the single best signal you have.

Once you’ve found something with some spark, scope it ruthlessly. Instead of planning a launch that needs a month of polish, sketch out the smallest version that lets you test your hunch—something you can genuinely ship in a week. If today is Monday, ship by Friday. Your goal isn’t to solve the entire problem, just to build a slice that proves your angle is worth pushing further.

Now, before you even hit “publish,” define how you’ll know this worked for you. Create a dead-simple rubric that’s tailored to your own goals, not someone else’s. That means setting signals to watch—maybe you want to see if you enjoyed building it, if it taught you something new, if one person got value, or if you found patterns you can reuse. Write these down. Don’t keep them in your head.

Decide how you’ll record what happens (a daily note, a short log after each session, a postmortem when you ship) and how you’ll decide next steps. If the signals show promise, keep going; if not, pivot or pause. The point is that you’re evaluating the work by your own markers, which brings a kind of stability no external metric can fake. This is clearer and more honest than chasing the moving target of external approval, and it makes your next move obvious instead of stressful.

And if you’re worried about how this fits with stakeholder demands or team norms, frame authentic software development as a way to reduce risk—never as an indulgence. When you define scope clearly, make decisions based on what matters, and document your learnings, you’re actually protecting your time (and theirs). The truth is, framing cuts down back-and-forth and tightens iteration, which keeps progress real instead of just performative. Don’t be afraid to admit directly, “I made something true to me first, and learned from that.” Most people respect that clarity more than endless tweaks for imagined approval.

Finally, accept that recognition may not come right away. When you create from a place of authenticity, external validation becomes a bonus, not the goal. The main thing is momentum that fits who you are. Keep stacking that up, and eventually the world catches on. Even if it doesn’t, you’ve built something that is fully yours, and that compounding energy stays.

Remember what Posner said, back at the start—sometimes the world will agree with your work, and sometimes it won’t. The real win is when you agree with it yourself, first.

Ship, Learn, Repeat—Let the World Catch Up

Stop chasing formulas and ship the small thing that aligns with your criteria now. You don’t need more consensus—you need movement that means something to you. The checklist can wait. The spark can’t.

That’s the arc Posner showed—all-in on authenticity, and only then did the outcomes follow. The result? I Took a Pill in Ibiza. A global smash. But even if it hadn’t blown up, it still would’ve mattered, because it was his.

Some days, I wonder if this approach will work for every project, or if certain kinds will always need to play the formula game. I don’t have an answer. But the ones that mattered most to me always started here—with something real.