Four products, $206 total: what 300 days of building SaaS actually looks like

Tom spent 300 days building four SaaS products. Total revenue: $206.

The first product made $29. The second made nothing. The third made nothing. The fourth made $177.

The pattern: he only used one of them himself.

This isn't a failure story. It's what the early stage of building SaaS products actually looks like when you strip away the survivor bias. Most products don't work. The question is whether you learn fast enough to make the fifth attempt better than the first four.

Product one: solve a problem nobody has

He built a YouTube thumbnail comparison tool. Took a month to ship. The group of people he thought would buy it gave good feedback when it was free. When he added paid features, one person bought.

Revenue: $29.

The mistake wasn't the execution. It was building for imagined demand rather than observed pain.

Product two: solve a problem for nobody

A vlog discovery tool. Shipped in 5 days. He didn't know how to market it. The only people who might care were daily vloggers, and he knew one of them. That person ignored his message.

Revenue: $0.

At least the first product had a real user. This one didn't even have that.

Product three: solve a problem you don't have

A tool to automatically overlay text on YouTube channel banners. He built the landing page first to generate excitement. It worked—he shipped in 7 days.

Then he realised he didn't want to use it. Nobody else signed up either.

Revenue: $0.

This was the turning point. Building something you don't want to use yourself is building on sand.

Product four: copy something that works

He built his own version of a bootstrap starter project he'd seen another indie hacker sell. This time he had a real use case: he wanted to use it. And he had a small audience from YouTube who might want it too.

Three sales. Revenue: $177.

Still not enough to justify the effort. But the first product where the fundamentals were right: he used it, and he knew people who might pay for it.

What the numbers actually show

Four products in 300 days. Total revenue: $206. Average revenue per product: $51.50.

The gap between products one and four isn't revenue. It's judgement. The fourth product had the right foundations even if the market wasn't there yet. The first three were built on guesses.

The pattern that emerges:

• Products you don't use yourself fail quietly
• Products built for imagined users rarely find real ones
• Speed matters more than perfection when you're learning
• The fifth attempt only gets better if you learn from the first four

The actual lessons

Five things that would have saved time:

Solve a problem for people you already know. Not a problem you think exists. A problem you've watched someone struggle with. The second and third products invented problems. The first and fourth at least started with real people.

Only build what you'd use yourself. The YouTube banner tool shipped and died. He never used it. Nobody else signed up. If you won't use it, why would anyone else?

Ship fast and move on. Perfectionism kills momentum. The customer cares about the experience, not the code. Get it working, launch it, learn from it.

Don't wait for permission to move on. When a product doesn't get traction, it's easy to take weeks off and question everything. Better approach: set a time limit, ship, move to the next one. Twelve startups in twelve months beats four products in 300 days.

Expect the first four to fail. Going in assuming your first product will work sets you up for emotional whiplash. Going in knowing you're running small experiments and building skill makes failure useful rather than defeating.

Where this leaves things

The opportunity is still real. People are building SaaS products and earning good income from them. The question is whether you can run enough experiments to find the one that works.

Four products, $206, 300 days. The numbers look bad. But the trajectory from product one to product four shows learning. The fifth product starts with better foundations than the first: a real problem, a real user (himself), and a small audience who might pay.

That's not success yet. But it's the difference between guessing and building on evidence.