Remember how good it felt to run your first “Hello world” program?
I sometimes think we might be the last generation that got genuinely excited about that. Because over the last two years, building software has gone from hard to almost trivial. I’ve felt it firsthand, and it has changed how I think about what’s actually scarce.
What building looks like now
In August 2024 I was browsing expired domains, a slightly odd hobby of mine, and found detectwptheme.com. It was a perfect name for a tool that tells you which WordPress theme a website uses. Instead of buying it and letting it sit, I gave myself a challenge: build and ship something useful in 30 minutes.
I asked Claude, inside Cursor, to build a WordPress theme detector with one constraint: it had to run entirely on Cloudflare Pages and Workers. The first prompt produced a working landing page and the detection logic. I deployed it, tested it, and only then bought the domain and pointed it at the site. Most of my later deploys were copy and style tweaks.
That wasn’t a one-off. I built JobReferral over a weekend and had a waitlist of referrers and recruiters within days. Around the new year I built FormSubmit, a small form backend for landing pages, in another weekend, and got my first payment from a stranger a few weeks later. When I tried Bolt a couple of months later, it felt like another step up again.
I had been away from hands-on coding for years. It didn’t matter. The gap between “I have an idea” and “it’s live on the internet” has nearly closed.
What didn’t get cheaper
Here’s the uncomfortable part. Every one of those projects taught me the same thing: building was the easy bit.
Adoption is still hard. In early 2025 I spoke with a dentist who had a tech-enabled business idea: digitize appointments, reminders, and resource planning that were all still on paper. I could easily have convinced him to start building. Instead I told him to find 10 potential customers with that exact problem, real ones who would pay, not friends being nice. If he can find 10 today, he can find 100 tomorrow. If he builds first, he risks spending money on software and giving up when nobody changes their habits. With traditional businesses, the hardest part isn’t the technology. It’s changing behavior.
Selling the product is still harder than selling the dream. I see founders spend months polishing a pitch deck for investors but not one week building something to show customers. The tools to build that something are now free. The excuse is gone.
Maintenance is still expensive. Vibe coding is great for demos and quick wins. It breaks down when you care about reliability, teams, and time horizons longer than a weekend. Writing the code got cheap. Maintaining, debugging, and retrofitting structure onto code nobody fully understands did not. There’s a reason companies happily pay for hosted versions of open source tools they could run for free: they’re buying freedom from the upkeep. A focused team that lives in one problem space will go deeper on edge cases, security, and UX than a one-off tool someone vibe-coded on a Saturday.
So what is scarce?
If execution is cheap, three things matter more than ever. I’d rank them in this order:
- Agency. The founders who stand out don’t wait for permission or capital. They show receipts: a live product, real customers, actual usage.
- Taste. Knowing which 10% of features solve 90% of the problem. AI lets you ship more. Taste stops you from shipping the wrong more.
- Curiosity. Markets move fast. The moment you stop asking “why,” you stop learning.
There’s also a new kind of builder emerging. Ben Tossell has written about shipping real software without being “technical” in the traditional sense, by directing AI agents and learning systems through building. I think he’s right that this is a new technical class. The skill isn’t writing code anymore. It’s giving tools the right context, spotting the gaps in your own understanding, and building systems that compound.
Where I’ve landed
I’m more excited about building than I’ve been in years. But I’ve stopped treating “can I build this?” as the interesting question. The answer is almost always yes.
The interesting questions are the old ones:
- Who has this problem badly enough to change their behavior?
- What’s the smallest thing that proves it?
- Will I still want to maintain this in a year?
What’s one idea you’ve been overthinking? Build it this week. Then go find ten people who’ll use it.