I want to talk about what happens when you stop asking for permission.
But first I need to tell you the part I usually skip.
A few years ago I went through something that broke me open. I'm not going to dress it up. It was dark. The kind of dark where you stop being able to see a way through it clearly. I had a career. I had a book. I had a stage. I had a day job I cared about. And none of it was enough to keep the lights on inside.
I came out the other side of that, slowly, and not alone. But the question that stayed with me when I did wasn't what now? It was something quieter and more urgent.
Now that I've worked out how to manage my own darkness, is there any way I can help someone else with theirs?
Not in a grand, sweeping way. Not a movement or a platform or a mission statement. Just: if I could help one person feel less alone in that place, would that be worth something?
That question is what made me a builder.
I was 54. I had no background in software. I had ideas I couldn't execute, tools I could see clearly in my head that didn't exist yet, and I'd spent too long handing them to someone else to make real, or shelving them, or watching someone else ship them two years later.
So I started learning to code. Not in school. Not in a bootcamp. At my kitchen table, at whatever hour I could carve out, using tools that hadn't existed five years before. Cursor. Claude Code. A lot of error. A lot of late nights staring at something that shouldn't be broken but somehow was.
Okay. Learning is an art, and I've heard a lot of people over the years say the older you get, the harder it is to learn. I don't believe that. What I do believe is this: the older you get, the harder it is to get back into the rhythm of learning. Learning itself can be learned. You can learn how to learn. Say that out loud. It sounds kind of weird, but it's true. It's like riding a bike. You haven't ridden one in a while. You'll wobble when you get back on, but you'll still be able to ride it.
One of the first things you find genuinely painful about coding, if you do it properly, is that it's a microcosm of failures reframed as steps toward the next level of success. By success I mean a piece of code that works, or a page that works, or a function that doesn't produce a big red error.
There are people who'll tell you AI can build you a working app in minutes. If you're talking about a bubble pop game or an overlay on a screen, sure, knock yourself out. Head to a vibe coding site today and build that. It will build it for you. But when it comes to building software as a service, apps with real functionality, things people actually use, one of the things that has to go into that is a thought process:
- How do I want the user to feel while they're going through this?
- How long should this sequence of clicks take?
- Am I writing code that will frustrate them until they give up, or am I coming up with a flow that gives them the emotion I actually want them to have?
This is where you realise that AI enables, it does not educate. The education is on you, my friend. AI will not do that for you unless you ask very, very clearly.
There is no point building things where you just let AI run and expect it to be perfect. If I go back to that line, "AI enables, it does not educate," here's the other thing: AI will flatter you. You say to an agent in Cursor, "This doesn't work," and it will come back and say, "Let me fix that for you." The problem is, if you don't know what it's doing, you won't know if what it's doing is wrong.
These tools can genuinely speed up your workflow. They can also take back every hour they saved you, because they've built patch upon patch upon patch instead of going back to the beginning and building something structurally sound. You look at your first interface, you feel proud, and then it falls apart because the foundation was never right.
When you read this and think, "I thought he just built these with AI," no. I've learned to code, at least to the level where I can look at code and understand what it's doing, so I can tell an agent, clearly, what I want and why.
For the reader who has already been here long enough and is hoping I wrap this up soon, the basics worth knowing are:
- React (just the 101, you don't need to go deep yet)
- Tailwind (same deal)
- Databases, what they are and how they work
- The difference between MySQL and Postgres
- The difference between Google Cloud with Firebase and Firestore versus Vercel with Supabase
- What kind of authentication system you're going to use
- How you're going to store and protect your users' data
All of these become second nature after a while. And they're things I now set up almost automatically at the start of a project, because I learned them the hard way first.
Here's something else I've learned that I wish someone had told me earlier.
Don't build the idea. Build what the idea does for someone.
There's a version of building where you fall in love with your own concept, the cleverness of it, the novelty, the thing you'd be proud to put your name on. That version produces a lot of abandoned projects and confused users.
The version that actually works starts somewhere different. It starts with a specific person in a specific moment, feeling a specific thing. What are they struggling with? What do they need? What would make them feel less stuck, less alone, less lost?
When you build toward that, the idea stops being the point. The person becomes the point. And that changes everything about the decisions you make while you're building.
I built rurlyok.com because I was that person first. Someone who needed someone at 2am when no one was there. That story is its own post, and it's not a light one. But the thing that made me build it wasn't "AI companion app sounds interesting." It was: I know what this feels like, and I don't want other people to feel it alone.
If I help one person with that, I've won. That's not a metaphor. That's what keeps me at the keyboard.
I've shipped five things since then.
rurlyok.com: because of what I said above.
krucbl.co: because I've watched too many people spend two years on an idea that deserved an honest hour before they started.
mindhq.ai: because smart people with big problems deserve more than one perspective pulling it apart.
fairtimeto.com and freddyhi.com: because the ideas wouldn't leave me alone until I did.
None of these would exist if I'd kept waiting until I knew enough.
I hear the same thing from people constantly.
I'm not technical. I'd need to go back to school. I wouldn't know where to start.
I said all of those things. Here's what I've learned on the other side of building five products with zero formal training: the floor has moved. AI tools haven't made coding easy. What they've done is something more important: they've removed the gatekeeping. But you still need to engage with what you're building. The people the tools actually help are the ones learning while they use them, not treating AI like a vending machine.
And more than any of that: you need to know what you're building for. Not the feature. The person.
Coding literacy has also changed how I do my day job.
I'm a Product Manager at Waves Audio, working on Voice ReGen, a tool that rescues audio recordings so damaged that nothing else can fix them. The conversations I have with developers now are different because I understand the territory. I can spec things more precisely. I know what's hard and what isn't. I can push back when I need to.
Understanding how things are built changes how you build them.
I wrote a book called The Fuck It Method. The whole idea is this: the thing stopping you is almost never as big as you've made it in your head.
We run the risk calculation unconsciously before we try anything new. We overestimate the downside. We underestimate what we'll learn even if it goes wrong.
Learning to code at 54 was a Fuck It moment. The worst case was I'd spend some hours confused and chalk it up to experience.
The real outcome was five products that exist in the world. One of them, I think, might be helping someone get through the night.
That's enough.
If you're sitting on an idea, something you wish existed, something that would help people, something that scares you a little: stop asking yourself if you're ready.
Ask yourself who needs it.
Then start there.
Much love,
Michael Pearson-Adams michaelpa.com
If you want to read about why I started building in the first place, that story is here. And if any of the things I've built sound useful: rurlyok.com, krucbl.co, mindhq.ai. They exist because I stopped waiting.
— Michael
More writing →