ContentsTailor
Grow

6 Products, $0 Revenue, 1 Engineer -- How I Got Here

6 products are running in production. Payments work. But revenue is $0. An honest account of what went wrong and what I'm doing about it.

March 28, 20269 min read
6 Products, $0 Revenue, 1 Engineer -- How I Got Here

6 products are running in production. They have domains, landing pages, and working payment integrations. Hit the checkout button and you'll actually get charged.

But revenue is $0.

To be precise, not a single user has ever paid. The services are live, infrastructure costs go out every month, but nothing comes in.

This is not an excuse. It's an analysis. What I did, what I didn't do across 6 products, and why I'm sitting at $0. Plus the plan for how I'm going to change that.

6 Products, Each With Its Own Story

1. vibecheck -- Multi-device Claude Code Access

A service that lets you use Claude Code across multiple devices.

It started from the idea of breaking free from the constraint of Claude Code only running in a local terminal. Sometimes you start a task on your laptop and want to pick it up on your desktop, or check on it from your tablet. That's the problem I set out to solve.

Current status: Posted on Reddit a month ago. One person signed up yesterday.

  • Signups: 1
  • Paid conversions: 0
  • Revenue: $0

Zero response for a month, then suddenly one signup yesterday. That's the reality.

2. b4uship.com -- Pre-launch Code/URL Scanner

A tool that scans your code and URLs before you launch.

Simple concept: "One last check before you ship." It catches security vulnerabilities, broken links, basic SEO issues -- things you want to catch right before launch. The goal was to be the final checklist a developer runs before putting a side project out into the world.

Current status: No marketing yet. Mentioned it during a mentoring session -- "give this a try" -- and one person signed up.

  • Signups: 1 (from mentoring referral)
  • Paid conversions: 0
  • Revenue: $0

3. build.drillcheck -- Market Demand Analysis (Reddit Data)

A tool that analyzes market demand using Reddit data.

It shows what people are frustrated about on Reddit and what solutions they're looking for. The idea was to answer "Is this idea any good?" with data instead of gut feeling.

Current status: Not a finished product yet. No marketing either.

  • Signups: 0
  • Revenue: $0

The irony: I built a tool for validating market demand without validating the market demand for the tool itself.

4. career.drillcheck -- Freelancer Skill Trend Data

A service that shows which skills are trending in the freelancer market.

It tracks which technologies are in demand on platforms like Upwork and Fiverr, and how rates are changing. The goal was to give freelancers data to help them decide what to learn next.

Current status: No signups.

  • Signups: 0
  • Revenue: $0

5. drillcheck.app -- Interview Prep SaaS

A SaaS for technical interview preparation.

It helps you systematically prepare for coding interviews and system design interviews.

Current status: No signups.

  • Signups: 0
  • Revenue: $0

6. littlestory.me -- Children's Photo Album

A niche service that turns your kid's photos into photo albums.

This one is different from the other five. It's not a developer tool or B2B SaaS -- it's a consumer product. Parents upload photos of their kids, and it creates a beautiful photo book.

Current status: One person signed up but never actually used it.

  • Signups: 1 (inactive)
  • Orders: 0
  • Revenue: $0

The Scoreboard

  • vibecheck: 1 signup, $0
  • b4uship.com: 1 signup, $0
  • build.drillcheck: 0 signups, $0
  • career.drillcheck: 0 signups, $0
  • drillcheck.app: 0 signups, $0
  • littlestory.me: 1 signup (inactive), $0

Total: 3 signups, $0 revenue. That's the reality.

Why $0

All 6 products at $0 is not a coincidence. There's a pattern. It means I kept making the same mistakes.

Here's the honest breakdown.

I built first

This is the biggest problem. Every single one of these 6 products started with "wouldn't it be nice to have this." Not "would someone pay for this?" but "can I build this?" was the starting point.

I could build it. I did build it. But I couldn't find anyone to use it.

This is the Build First trap. It's the easiest trap for engineers to fall into. If it's technically feasible, it feels worth doing. And once you finish building it, you assume people will come. They don't.

I didn't do marketing

After building a product, what I did next was build the next product. I started building the second one before finding users for the first. I was already planning the third before the second was even done.

vibecheck got posted to Reddit once. That's it. The rest have had zero activity that could be called marketing. b4uship was mentioned once during a mentoring session. That's the extent of it.

Building is fun. Selling is hard. So I just kept building.

I didn't experiment with pricing

All 6 products have pricing pages. All have payment integrations. But I never validated whether any of those prices were right.

Was the plan to let people use it free, collect feedback, then convert to paid? Or was it to charge from day one? That wasn't even consistent across products. Translation: there was no pricing strategy.

The problem of spreading thin

If I had focused on 1 product, things might have been different. Time, energy, and attention split across 6 was never enough for any of them.

Each one took about a week. With vibe coding, that's enough to get to production. Add it up and it's roughly 6 weeks. 6 products in 6 weeks. I was proud of the speed.

If I had spent those 6 weeks on one thing -- 4 weeks building, 2 weeks marketing -- the number might not have been 3 signups.

So what did I learn

What $0 in revenue taught me is clear:

  1. Sell before you build. Put up a landing page, collect pre-signups, and find out if anyone cares first.
  2. Focus on one thing. Running 6 products at $0 is worse than running 1 product at $100.
  3. Marketing is not optional. There need to be days where you don't write a single line of code. Spend that time writing, talking to people, getting the word out.
  4. Kill fast. Some of these 6 need to be shut down. It's emotionally hard, but necessary.

Why I Started This Blog

This blog -- contentstailor.com -- is product number seven. What makes it different from the other six is that it's not a product built to make money. It's a product built to document the process.

Build in Public.

The concept isn't new. Plenty of indie hackers do it. You share revenue, traffic, failures, and wins publicly. You learn as you go, and the process itself becomes content, and content becomes marketing.

That's exactly what was missing from my first 6 products. I built them alone, where nobody could see. Of course nobody used them.

Here's what I plan to do through this blog:

  • Publish monthly build logs. Share honest numbers for each product -- traffic, revenue, changes. If it's $0, I write $0.
  • Document experiments. Change pricing, try different marketing channels, and share the results. Whether it worked or not.
  • Share decisions. When I kill a product, start something new, or change direction, I write down why.
  • Record the journey from $0 to $10K. I don't know if I'll get there. But the process will be documented.

No inflating the numbers. If things go well, I say so. If they don't, I say that too. Just like right now.

The Plan Going Forward

Getting away from $0 means doing things differently. Here's the concrete plan.

1. Pick which products to focus on

Growing all 6 at once is impossible. I'll pick the 1-2 with the most potential and focus there. The rest go into maintenance mode.

Criteria for choosing:

  • Is the problem clear? (Are people actually frustrated by this?)
  • Is this a market where people are willing to pay?
  • Is there a real differentiator vs. competitors?
  • Has there been any signal at all? (Even from just 3 people)

I'll do this analysis publicly in the next post.

2. Publish monthly build logs

At the end of every month, I publish a build log. The format:

  • Traffic per product (with GA screenshots)
  • Revenue (based on the Stripe dashboard)
  • What I worked on that month
  • Plans for next month
  • Total costs vs. total revenue

The revenue column in the first build log will be all $0s. I'm writing it anyway.

3. Start marketing experiments

I need to break the habit of only writing code. Specifically:

  • Content marketing through this blog
  • Community engagement on Reddit, Hacker News, etc.
  • SEO optimization

What works and what doesn't will be shared in the build logs.

4. Target the first $1

$10K is a distant goal. The first milestone is $1. When someone pays for something you built, that's proof the product delivers value. The gap between $0 and $1 is wider than the gap between $1 and $10K.

When the first $1 comes in, I'll write about it here.

Wrapping Up

Here's where things stand.

6 products. All live. All with working payments. 3 total signups. $0 revenue.

This is not a failure story. It's not over yet. This is an origin story. Acknowledging the reality of $0, analyzing why, and laying out a plan to change it -- that's the starting point.

This blog is the record of that process.

Every month I'll share the numbers. Share the experiments. If I fail, I'll write that I failed. If I succeed, I'll write how I did it.

In the next post, I'll break down how I built one of those 6 products -- b4uship.com, a security scanner for vibe coders -- in 48 hours with Cursor and Claude Code. The full build log: what I chose, what broke, and the irony of using AI to catch AI-generated vulnerabilities.

If you found this useful, bookmark contentstailor.com. Every month I'll share build logs and transparently document the journey from $0 to $10K.

Part of the $0 to $10K series on ContentsTailor