I Killed My First SaaS Before Writing a Single Line of Code

I ended my first Build in Public season without writing a single line of code. On purpose.

In this episode I share why I decided to kill my first SaaS idea – a tool around ecommerce shipping policies – after talking to real people, not after six months of building.

Watch the YouTube video

The context: a SaaS for shipping policies

I started from a very concrete pain I’ve had for years: every time I spin up a new Shopify store, I have to rewrite the shipping/returns/policy page from scratch.

It’s not just boring.

It’s also risky: regulations change, markets differ, languages change, copy needs to be adapted each time. And the temptation to just “copy‑paste” from other sites is always there.

The initial idea was simple:

• a micro‑SaaS, kind of like “Iubenda but for shipping policies”,
• integrations with major ecommerce platforms,
• guided generation/updating of policy pages.

On paper, it made sense.

The test: landing page + Facebook groups + friction

Instead of starting with code, I did the least sexy but most useful thing: a minimal landing and a serious feedback round.

1. Minimal landing

I built a very basic landing page with a no‑code builder.

Goal: explain the problem in a few lines, show the idea, and collect emails only from people who actually felt the pain.

No Dribbble‑level design, just:

• clear problem,
• minimal promise,
• short form.

2. Asking publicly in ecommerce groups

Then I brought the conversation where potential users actually are: Facebook groups for ecommerce operators.

The question was straightforward:

How important are your shipping/returns/policy pages really? Have you ever seen cases where a bad page created issues, or a good one saved you time, money, or headaches?

That’s where things became interesting.

The feedback (including the brutal ones) that changed everything

Some replies confirmed the problem is real.

• “The clearer the policy, the fewer returns and issues you have.”
• “If you sell products not covered by standard return rights, the policy must be crystal clear.”
• “If you do it well, you’re often right and you solve disputes faster.”

So yes, this space is real and touches money, time and support.

But most comments went in a different direction:

• “We’re not talking about marketing here, this is legal stuff: talk to a lawyer.”
• “Customers will never read it, it’s there to protect the merchant.”
• “Why don’t you just pay a lawyer, which would even be cheaper?”
• “There’s already Iubenda, LexDoIt and a thousand other tools. What the hell do you need to build?”

That’s a big red warning light.

The real issue wasn’t technical, it was strategic

Here’s what I understood from this friction:

• people’s mental model is “lawyer + legal obligation”, not “software that makes my life better”;
• the idea of “yet another AI policy tool” is perceived as a commodity at best, or as fluff at worst;
• shifting that perception would require a long, heavy education game that I don’t have the energy nor the appetite for right now.

It’s just not the mountain I want to climb.

Why I chose to kill the idea

At that point I had two options:

1. ignore the noise, convince myself “they just don’t get it” and lock myself into building for months;
2. take the signals seriously, admit the idea no longer excites me, and pull the plug before over‑investing.

I chose the second.

Not because it’s impossible to build something in this space.

But because, with my resources and the kind of solo founder/creator I am, the energy I’d need to spend educating this market isn’t aligned with the risk/return profile I want.

And that’s exactly the point of this series: showing the projects that DIE quickly, not only the ones that survive.

The hidden win: time and focus saved

Saying “I failed” in season one might sound depressing.

In reality:

• I spent weeks, not years,
• I validated by talking to real people, not just to my Notion page,
• I proved to myself that I can drop a project without tying my identity to it.

For a solo founder, knowing when to pull the plug is a skill.

Every idea you kill early gives you back time, focus, and clarity for the next one.

What I’m taking into the next season

From this mini‑season I’m taking three clear filters for upcoming ideas:

1. A market that clearly sees the value of software, not just of consulting.
2. A problem that hurts enough for people to actively look for solutions, not just comment under posts.
3. A space where I see myself happily spending months, not just “an interesting side project I could hack together”.

The next Build in Public season starts here.

Not from a “genius in the garage” who’s always right.

But from someone who prefers to fail in public, on small bets, to increase the odds of hitting something meaningful a few attempts down the road.

If you want the full story, including the emotional side and live breakdown, here’s the YouTube episode:

▶ Watch the video: I Killed My First SaaS Before Writing a Single Line of Code