build-in-publicsaasstartupidea-validationmicro-saas

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

First Build in Public season closed without a single line of code. Shipping policy idea, landing page, real feedback, some backlash in the groups. And the decision to kill it. Still a win in my book.

Published June 7, 20265 min read
I Killed My First SaaS Before Writing a Single Line of Code

First Build in Public season closed. Zero lines of code written.

And it didn't happen by accident. It was a choice.

In this episode I explain why I killed my first SaaS idea — a tool around ecommerce shipping policies — after talking to real people. Not after six months locked at home writing code for nothing.

Watch the YouTube video

The context: a SaaS for shipping policies

The context: a SaaS for shipping policies

I started from a 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 risky: regulations change, markets differ, languages differ, copy needs adapting every time. And the temptation to copy-paste from other sites is always one click away.

The idea was simple:

  • a micro-SaaS like "Iubenda but for shipping policies",
  • integrations with the main ecommerce platforms,
  • guided generation and updating of policy pages.

On paper, sensible. Like every idea on paper.

The test: landing page + Facebook groups + friction

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

1. Minimal landing

Very rough landing, no-code builder.

Goal: explain the problem in a few lines, show the idea, collect emails only from people who 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 the potential users actually are: Facebook groups for online sellers.

Straight question:

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 and headaches?

That's where everything came out.

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: the space is real. It touches money, time and support.

But most comments went elsewhere:

  • "We're not talking marketing, 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 is even cheaper?"
  • "Iubenda, LexDoIt and a thousand other tools already exist. What the hell are you building?"

And that's a big red warning light.

The real issue wasn't technical, it was strategic

Here's what I got from this friction:

  • people's mental model is set on "lawyer + legal obligation", not "software that makes my life better";
  • the idea of "yet another AI policy tool" is perceived as a commodity. Best case. Worst case, as fluff;
  • to shift that perception I'd need to fight a market education war that, honestly, I have neither the energy nor the appetite for.

It's just not the mountain I want to climb. Period.

Why I chose to kill the idea

At that point I had two paths:

  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 building something in this space is impossible.

But because, with my resources and the kind of solo founder I am, the energy I'd need to educate this market doesn't hold up against the risk/return I want.

And that's exactly the point of the 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 sounds depressing.

In reality:

  • I spent weeks, not years;
  • I validated by talking to real people, not to my Notion page;
  • I found out I can drop a project without tying my identity to it.

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

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 immediately sees the value of software, not just of consulting.
  2. A problem painful enough that people actively look for solutions, not just comment under a post.
  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 a garage who's always right.

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


If you want the full story, with behind the scenes and the emotional side, here's the YouTube episode:

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