Our site aiomniu had moved from "building features" to "building growth." We had four growth loops running — internal links, email, social media, backlinks. Everything looked like it was on track.
Then, in the span of three months, I almost killed the project three times.
The first time was a tech stack decision. The second was a deployment failure. The third — was realizing I'd been doing everything the wrong way from the start.
Three near-death experiences, three different flavors. But looking back, they were all the same thing from different angles.
1. The Tech Trap: 1,270 Pages That Brought My Site Back to the 2G Era
While working on SEO and internal linking, I used marketing-skills methods to study competitors and build a ton of landing pages. I shipped 1,270 pages — and the result? The site loaded like it was 2007. Google flagged our performance as trash and stopped crawling us entirely.
I did everything I could to get Google to notice us. And those exact actions were what made Google ignore us.
At that point, I had two choices: abandon internal link optimization, or rebuild the entire frontend.
It was a false choice. This was our first growth initiative. If we stopped here, we weren't building a business — we were playing with toys.
So began the massive migration from Vue to Next.js. Long, painful, and every step landed on a landmine.
Here's the thing — this bomb exploded in June, but it was planted back in late April, the day we picked Vue as our frontend framework.
The AI's logic was straightforward: "You want a website fast? Vue. No question." And me? I didn't know how to code. I was like a clueless husband, nodding along — "Yes, dear engineer."
That's an excuse, of course. All I had to do was ask one more question: "But what about scalability? What happens when I need 5,000 pages?"
The AI thinks in the present moment. We have to think in the future. Filling that gap — that's on us. Nobody else is going to do it.
Picking Vue, not realizing the cost until page 1,260 — that one was mine. But honestly, it wasn't the hardest part.
2. The Emotional Trap: The Day Deployment Broke and I Almost Shut It All Down
The hardest part was June 8th.
The day before, I had deployed a new version without a hitch. The next day? Nothing worked. Error after error. I had Claude check and re-check the code endlessly. An entire day, every method I could think of — the deploy just would not go through.
That night, I did nothing. I lay in bed scrolling Douyin until I fell asleep.
Our whole project runs on Cloudflare Workers. The single most critical link in the chain was broken, and I had no idea what to do next.
You might wonder — if your tech stack is wrong, you can at least fix it. But when your deployment pipeline is dead, there's nothing to fix. It's a different kind of despair. The first one is "I chose wrong." The second is "I can't go forward."
After a night of despair, Claude and I mapped out two options: buy a server, or wait for Cloudflare's developers to patch the bug. I hated both. But I had no third option. That's life. We decided to file a bug report and wait two days. If nothing happened, we'd buy a server.
And then — like all good stories — the turnaround came. A Cloudflare developer replied the next day and fixed the versioning issue. I want to say this sincerely: thank you. Really.
Standing here in July, it doesn't look like a big deal anymore. Wait a bit, and problems solve themselves.
On this journey, sometimes it's not the difficulties that crush you. It's one devastating blow after you've already poured everything in. That's what breaks the camel's back. Give yourself some time. Give your project some time.
A lot of problems aren't "unsolvable." They just "need time." That's true for tech roadblocks. It's true for heartbreak, too.
Sometimes you didn't do anything wrong. It just wasn't your problem's turn to be solved yet. "Hang in there" — sometimes that's not a cliché. It's just a fact.
After crawling out of that low point, I caught my breath and looked back at the road behind me. And that's when it hit me — the first two disasters had the same root cause.
3. The Cognition Trap: The Faster AI Got, the Slower I Became
The longer I use AI, the stronger this feeling gets: AI is incredibly good at pulling you into "false efficiency."
The problem is speed. Ask it to build a webpage, and it's done in an hour. Satisfying? Hell yes. Who needs programmers? I became a developer in a day.
But that dopamine hit doesn't help you judge direction. It only helps you "run faster forward." It's like a train where someone keeps shoveling coal — always accelerating, speeding up until it derails.
Looking back, picking Vue was a direct consequence of this. The AI said Vue was fast. I used Vue. And it wasn't wrong — from a "get it built" perspective, Vue really is faster. But it never told me that by page 1,270, the site would crawl. It just kept leading me to the next feature, faster and faster, further off course.
AI has a distinct trait: it sees the world as a Y-axis. Vertical thinking by default. Finish one thing, move to the next. It's dangerously easy to fall into this sunflower-seed instant gratification — "Another feature done! I'm killing it!" But you start mistaking motion for direction. And the truth is, most of the time you're just "moving," not "moving right."
I don't have a perfect fix. Just scar tissue and reflexes from getting burned enough times. Here's what I've learned:
1. Use structured brainstorming tools. Superpowers brainstorming is the most common one. Plenty of people complain it's bloated, but it genuinely helps you dodge bullets before you start building. If I had spent 30 minutes brainstorming Vue vs. Next.js before coding, those 1,270 pages might not have been wasted.
2. Use traditional review processes to constrain AI. Back when we did operations work, we always held product reviews and design reviews first. That wasn't wasted time — it was the old-school method, and it still works. My rule now: visual first. For any feature change, make Claude show you what it looks like before you build it.
3. Make AIs compete. Take Claude's proposal and send it to ChatGPT. In my experience, ChatGPT is really good at finding flaws. This effectively adds an X-axis to the AI's natural Y-axis thinking. When you're too close to the problem, bringing in a third perspective dramatically lowers the risk of rework.
4. Build a contradiction mechanism. Tell your AI not to just agree with you. Once it knows you're not a 300-month-old baby who needs hand-holding, the quality of its thinking improves significantly. Because most of the time — the one shoveling coal into that train isn't the AI. It's you.
The Bottom Line
Three near-death experiences. Three ways to die.
The first was a tech trap — wrong framework, massive migration. The second was an emotional trap — deployment broke, nearly gave up. The third was a cognition trap — false efficiency kept me accelerating in the wrong direction.
But all three share the same root: AI is responsible for speed, not for correctness. It's a train where coal never stops getting shoveled. Your job isn't to run alongside it — it's to stop, before it derails, and ask: am I even going the right way?
AI isn't your problem. You are. It's fast, but it won't help you pick a direction. It's efficient, but it won't make choices for you. It's always outputting, but it will never grab your shoulder and tell you you're walking off a cliff.
On the startup journey, the most expensive thing isn't development, servers, or even time. It's pouring everything into something only to realize you've been running in the wrong direction.
So slow down. Ask one more question. Let someone poke holes in your plan. Give yourself time.
If you're building with AI and walking through similar minefields, come find me at aiomniu.top. Solo developer or founder — this road has no shortage of traps. But the good news is, we don't have to step on all of them alone.
Top comments (0)