Think like a builder.

The constraint was never the code

Here's what I noticed after about six months of this. My ideas hadn't gotten better. My taste hadn't improved. What changed is that I stopped pre-shrinking them.

You do this constantly and you don't notice. An idea shows up — "we should have a thing that watches all the local event calendars and tells our guests what's on this week" — and before it's even finished forming, some quiet part of your brain has already priced it, decided it's a six-month engineering project, and filed it under Someday. The idea never even reaches the page. You are not choosing not to build it. You are deciding it's unbuildable, silently, in about a second and a half, and moving on.

That specific example is a thing I built. It scrapes 175-odd local sources, sorts what it finds, and feeds a hotel's staff and guests a daily readout of what's happening in the area. Old me would have priced it at three months and a developer. It was not that.

The work now is noticing the moment you shrink an idea, and not doing it. That's the skill. Everything else in this guide is logistics in service of that one habit.

Ask "what would this take?" before "can I do this?"

These sound similar and they are completely different questions.

Can I do this? is a question about you, and you will answer it with your insecurities. What would this take? is a question about the work, and it has an actual answer — usually a much smaller one than you feared.

So when the idea shows up, don't evaluate it. Describe it. Out loud, to the agent, in the messiest terms you like:

Half the time the answer is "that's four hours." A quarter of the time it's "that already exists, here it is, install it." And the last quarter it's genuinely hard — in which case you've learned that in ten minutes instead of never. Every one of those outcomes is a win, and you got it for the cost of asking.

Build the ugly version first, and use it

The instinct is to plan. Resist it. Build the ugliest possible version of the thing this week, then use it yourself, immediately.

Not because "ship fast" is a slogan, but because the ugly version tells you what the idea actually was. You will discover within three days of real use that half of what you planned is worthless and one thing you never thought of is the whole point. You cannot learn that in a planning document. Nobody can. It is only available on the other side of using the thing.

Every tool I run that I actually care about started as something embarrassing that solved one narrow problem for exactly one person, me, and grew from there. Every ambitious thing I tried to design properly up front is dead.

Follow the annoyance

You want a reliable source of good ideas? Stop looking for ideas. Track your annoyances.

Every time you do something manually for the second time — copying numbers between two places, checking whether the site's still up, retyping the same email, digging through a folder for the same file — write it down. Don't fix it yet. Just log it. Keep the list for two weeks.

What you'll have at the end is a list of things that are, by definition, worth automating: they're real (you actually do them), they're recurring (you did them twice), and they annoy you (so you'll actually use the fix). That's a better product roadmap than anything you'd invent by brainstorming, and it costs you nothing but attention.

Then work the list, one at a time, smallest first. The compounding is the point: every annoyance you kill is time back, permanently, forever, and it frees you to notice the next one.

The thing that keeps people stuck

I'll be direct, because I think this is the actual barrier and everything else is a proxy for it.

Most people don't build because they've decided, somewhere below the level of conscious thought, that building is for a category of person they aren't in. Engineers build. Technical people build. You run the business, or you do the marketing, or you manage the shop, and building is something you buy from someone else.

That was true. For decades it was completely true, and it is not true anymore, and most people haven't updated. The thing that has changed is not that AI writes code. It's that the ability to describe what you want clearly is now sufficient — and that ability is what you have been developing your entire working life, in every brief you've written and every job you've delegated and every time you've explained to somebody what "good" looks like.

You already have the hard skill. You've been told, for twenty years, that it wasn't the one that counted. It's the one that counts now.

Where to start, today

1. Get the server. Six dollars. Do it before you finish talking yourself out of it. Chapter one.
2. Put the agent on it and let it teach you for an hour. Ask it to explain everything. Chapter two.
3. Write your CLAUDE.md — who you are, how you need to be talked to. Chapter three.
4. Kill one subscription by self-hosting its free twin. Feel what that feels like. Chapter five.
5. Start the annoyance list. Two weeks. Then build the top one.

That's it. That's the whole thing. I'm about a year into it and I still don't write code, and I've stopped noticing that I don't.

Genuinely — if this gets you unstuck and you make something, I want to hear about it. That's the only payment I want for this page.