AI makes it easier to build the wrong thing faster
Why I threw away 20,000+ lines of working code and started over with nothing.
I just spent two weeks building a custom newsletter platform from scratch. Auth, subscriptions, analytics, drip campaigns, email previews, Stripe integration… the list goes on.
I did it all with Claude. 20,000+ lines of code. And it worked!
Then I deleted it.
Content in two places felt broken
For six months I’ve had this nagging feeling that my content lives in the wrong place.
My newsletter is on Substack. My website is a Jekyll site. Every time I wrote something, I’d copy it to both places. Then I’d update one and forget to update the other. It felt messy. And all the SEO/AI juice I thought I was losing by having my stuff live on two separate domains.
So I decided to fix it. I’d build one system where everything lives together. My website would become my newsletter platform. No more duplication. No more sync issues. One source of truth.
I fired up a new Rails app and got to work.
What I built
In two weeks, I had:
User authentication with free and paid tiers
Subscription flows through Stripe
Admin interface for managing posts
Multiple analytics dashboards
Email sending through Postmark
Drip campaigns through Bento
Dynamic CTAs based on whether you were signed in, free, or paid
A custom markdown renderer (I’m still pretty proud of this one!)
Over 20,000 lines of code. It all worked. I set up my Render config, deployed it, and watched it run.
But then I thought: what happens if…?
Then the “what ifs” started
What happens if a background job fails and I don’t notice?
What happens if a job gets stuck in a loop and sends 500 emails to one person?
What happens if I forget some esoteric header in the emails and my domain gets flagged for spam?
What happens if I leak a credential?
What happens if Cloudflare caches a page wrong and someone sees another user’s session?
None of these were unsolvable. I could always write more code, add more monitoring, and build more safeguards.
But that’s when it hit me: I didn’t have a code problem. I had a decision problem.
The real answer took an afternoon
The real question was never “how do I build a unified platform?” It was “where should my content live?”
Once I actually sat down and thought about it, the answer was obvious.
Substack handles content. That’s what it’s good at. Sending emails, managing subscribers, handling spam complaints, dealing with deliverability. All the stuff I was about to become responsible for.
My website is a business card. A list of my services, an about page, and links to everything else. Simple, static, and practically zero maintenance.
That’s it! No code required. Just a decision about what goes where.
I could have made that decision in an afternoon. Instead, I spent two weeks building something I didn’t need.
Without AI, I would have quit at 20%
If I had tried to build this myself, without AI, I probably would have quit at 20%. It would have been too much work with too many moving parts. Just… not worth it.
But Claude got me to 90%. I was cranking out features, knocking off todos and shipping tons of code. I felt productive.
I was on a ship going full speed with no idea where I was headed.
And that’s the trap. AI removes the friction that used to make us stop and ask “is this even worth building?” You can get so far down the wrong path that you forget to check if it’s the right path.
Building is easy. Building the right thing is hard.
A few weeks ago I wrote about building something real, almost entirely with AI. My takeaway was that code isn’t the bottleneck anymore.
I went off the deep end with AI
For the past few weeks I ran an experiment: build something real, almost entirely with AI. Here’s what I learned, what’s shifting in how I think about code, and what I’m honestly terrified about.
But here’s what I didn’t fully appreciate: that cuts both ways.
If building is easy, building the wrong thing is just as easy. You can spin up a working prototype in a weekend. You can add features faster than you can decide if you need them.
The constraint is no longer “can we build this?” It’s “should we?”
And that’s a strategy question, not a code question.
If I had spent an afternoon thinking through what I actually needed, I would have ended up exactly where I am now. Content on Substack, everything else on my website. No code. No maintenance. No “what ifs” keeping me up at night.
Instead, I learned it the expensive way. Two weeks of work, deleted.
Strategy before code
Before you start prompting Claude, ask yourself: what problem are you actually solving?
Not “what would be cool to build?” Not “what can I build?” What do you actually need?
The answer might be a decision, not a feature. Maybe a conversation instead of a codebase. Or like me, an afternoon of thinking, not two weeks of “shipping”.
Don’t let the ease of building trick you into skipping the strategy. It’s more expensive than it looks.
This is a big part of why I now help teams figure out what to build before they start building. The decision, not just the code.




Good insight, thank you for this !
Thank you for sharing this (and for 'Permission not required' podcast).
I find that I need to be really careful not to 'other do' features because it's so easy to just respond 'yes' when your are asked something like 'do you want me to also ...' by an agent. Having a clear vision of where you want to go is key to not get lost in a massive amount of unneeded code and features.