I Wasted Two Weeks Building a Product Nobody Can Use

And I burnt it all down.

AI made it easy to build. That’s the trap.

I wasted two weeks building a product that was dead on arrival.

I could have figured that out in 30 minutes. One browser tab. One Terms of Service page. That’s all it would have taken.

Instead I had a working prototype, a validated use case, a clean UI, and absolutely zero future.

And today I’m going to tell you exactly what happened so you don’t make the same mistake.

Let me show you where it all went wrong.

What I Built (and Why It Mattered)

I built a Substack discovery tool for content creators.

The idea was straightforward. Creators on Substack have no efficient way to find similar publications in their niche. No way to track what their peers are writing about. No way to get a pulse on trending topics across their category on any given day.

My tool solved that.

You tell it your niche, it curates articles from similar publications and generates daily trending reports. It shows you what fellow creators are publishing so you can stay ahead of the conversation instead of guessing what to write about next.

I validated the idea. Talked to creators. Confirmed the pain point. The demand was real.

I would lay awake at night thinking of what I could fix to make it better. How I would market it. I even started onboarding beta testers.

And I had it working. The screens looked clean. The reports were pulling real data. Leaning back in my chair watching it all populate across the screen in real time.

That feeling when something you built actually WORKS???

You know the feeling.

I could smell the dolla bills

Then the cracks started showing.

The Foundation Was Quicksand

I need to be upfront with you here.

I knew going in that Substack doesn’t have a public API. No developer program. No official documentation for building tools on top of it.

I KNEW ALL OF THIS.

And I built anyway.

Why? Because AI makes building so fast that you start thinking you can outrun structural problems. You tell yourself you’ll figure it out as you go. You’ll find a workaround. Somebody on GitHub has already solved it.

So I started pulling data through the unofficial, undocumented endpoints that Substack’s own website uses behind the scenes. And at first, it worked.

Sort of.

The responses were inconsistent. Data would come back incomplete. Fields that populated fine one hour would return empty the next. Nothing was reliable enough to run a real product on top of.

I was building a house and the lumber kept changing shape.

That’s when I finally stopped building and started doing the research I should have done BEFORE I wrote my first line of code.

I pulled up Substack’s Terms of Service on my laptop. Right there in plain language:

They prohibit crawling, scraping, or spidering any page, data, or portion of Substack through manual or automated means.

They prohibit copying or storing any significant portion of content.

They ban reverse engineering or attempting to obtain underlying source code or information.

FACT: Substack’s TOS was last updated April 21, 2025. This language is current and enforceable. I confirmed it myself.

That covers EVERYTHING.

The scraping I’d need to do to pull article data. The database I’d need to build to store content for trend analysis. The reverse-engineered API endpoints I was already using.

All of it violates their Terms of Service.

The RSS feeds don’t give enough data either. To do real trend analysis across publications, I’d need full article content stored in my own database. Which is exactly what the TOS prohibits.

Dead end after dead end.

The Two-Week Lesson

Here’s where I have to be brutally honest with myself and with you.

I validated the product. The demand was real. Creators want this tool. The market wasn’t the problem.

THE PLATFORM WAS THE PROBLEM.

Even if the responses had been perfectly consistent. Even if Substack had a well-documented developer program with official API keys and rate limits and dedicated support.

I would STILL be building a business that lives or dies based on another company’s decisions.

They change an endpoint. Your product breaks.

They update their TOS. Your product is illegal.

They revoke your API access. Your product vanishes overnight.

They get acquired. Your product is someone else’s problem now.

FACT: 42% of startups fail because they build products that don’t meet market demand. But there’s a subset of that number nobody tracks. The products that had REAL demand but were built on foundations that couldn’t support them.

I didn’t misread the market.

I misread the map.

The Startup Genome Project found that founders overestimate the value of their IP before product-market fit by 255%. They also found that market validation takes 2-3x longer than most founders expect.

I had the opposite problem. I validated fast. I built fast. I skipped the part where you check whether the building has a foundation before you start decorating the rooms.

Research would have taken 30 minutes. Building took two weeks.

You tell me which one was actually slow.

The lesson is simple. A long-term business is not built on top of another product.

If your entire product only works for Substack, or only works for X, or only works inside one platform’s ecosystem, you are not building a business. You’re building a feature inside someone else’s house.

Build tools that solve problems ACROSS platforms whenever possible. Or at minimum, build your system so the data layer is modular. When one source dries up you plug in another without tearing down the walls.

If you read nothing else in this article, go back and read that paragraph again.

How to Use AI for Research BEFORE You Build

If you still insist on building on top of another platform or using their tools as a core dependency, here’s how to protect yourself. This is the framework I’m using going forward. And it’s what I should have done before I touched a single line of code.

Step 1: Read the Terms of Service.

This is the most boring, most important 20 minutes you’ll spend before any build. You’re looking for language around scraping, crawling, data storage, reverse engineering, API usage, and third-party applications.

Substack’s TOS would have killed my project on Day One.

I didn’t read it until I was already knee-deep in code on Day Twelve.

Use AI here. Drop the TOS into Gemini or Claude and ask: “What restrictions does this platform place on third-party developers, automated data collection, and content storage?”

You’ll get a clear breakdown in under two minutes.

Step 2: Verify the API landscape.

Does the platform offer a public, documented, supported API? Is there an official developer program with real documentation?

If the answer to both questions is no, you’re not building on a platform. You’re building on a rumor.

Undocumented internal APIs are fun for side projects. They’re terrible for businesses. An afternoon of research using AI to search for “[Platform Name] developer API” and “[Platform Name] developer program” will tell you everything you need to know about whether your technical foundation is real or duct-taped together by strangers on GitHub.

Step 3: Map your data dependencies.

Open a blank doc. Write down every piece of data your product needs to function. Next to each one, write down where that data comes from.

Then ask one question for each line item:

“Can the source of this data cut me off?”

If the answer is yes for the core data your product runs on, you don’t have a product. You have a countdown timer.

My tool needed article content from Substack publications. Substack controls that content. Substack’s TOS prohibits me from collecting it.

I could have mapped this out on a napkin at my kitchen table in fifteen minutes.

Step 4: Stress-test with AI before you commit.

Before you invest real dev time, run these prompts through a deep research tool like Gemini:

“What are the known risks of building third-party tools on [Platform]?”

“Have any products been shut down for violating [Platform’s] terms of service?”

“What data access limitations exist for [Platform] and how have other developers worked around them?”

“What is the technical feasibility of [your specific product idea] given [Platform’s] current infrastructure?”

Most people use AI to speed up the build.

Operators use AI to speed up the decision about WHETHER to build.

That distinction is worth more than any coding shortcut you’ll ever find.

The Real Takeaway

AI made it possible for me to build in two weeks what used to take two months.

But the speed didn’t make the product more viable.

It made the failure faster.

The people who will win in this era aren’t the fastest builders. They’re the ones who spend two hours researching before spending two weeks building. The ones with a notepad open on the desk, mapping dependencies BEFORE they open the code editor.

I learned this the hard way so you don’t have to.

Before you build your next tool, run the framework above. Spend one afternoon. Save yourself weeks of wasted effort. This is the kind of thinking we do inside The AI Operator Handbook every single week.

Not chasing shiny tools. Not building for the sake of building.

Thinking clearly about what’s worth building in the first place, what foundation to build it on, and how to avoid the traps that eat your most valuable resource: your time.

If that sounds like the kind of newsletter you need in your inbox, hit subscribe and join us.

Talk soon,

Ryan

P.S. Paid subscribers get early access to every framework, prompt template, and workflow breakdown I publish. Including the full AI research workflow I now run before starting any new build. If you’re building in the margins around a 9-5, you need systems that prevent wasted weeks, not create more of them. The link to upgrade is below.