I started a 90-day experiment because I got tired of a very specific type of startup content.

The story usually goes something like this:

• Buy a MacBook.
• Open Claude.
• Build a SaaS in a weekend.
• Post a few screenshots.
• Somehow arrive at $1M ARR.

The part that always seems to be missing is the middle.

• How do people find it?
• Why would they trust it?
• Would they pay for it?
• What breaks in production?
• How long does billing take?
• How do you explain the product?
• What happens when nobody cares?
• What do you do after the first post disappears into the feed?

That missing middle is what I wanted to test.

So I gave myself 90 days to build and market a tiny SaaS product in public. Not as a success story, but as a measured experiment.

The product is called Blah Blah. It is a GitHub App that helps generate release notes from repositories.

The workflow is intentionally small:

• Connect GitHub
• Pick a repository
• Select an end tag, and optionally a previous tag
• Read commits and changed files between those tags
• Generate an editable Markdown release note

Nothing is published automatically. The point is not to replace the developer. The point is to remove the annoying “what changed since last release?” reconstruction work.

The product was built mostly with AI assistance. Code, UI iterations, copy drafts, debugging, and refactors all went through AI tools.

But the important decisions were still human decisions:

• What problem to pick.
• What scope to cut.
• What permissions to request.
• Whether to auto publish or keep drafts editable.
• How pricing should work.
• When to rename.
• What to redesign.
• What felt trustworthy.
• What felt too generic.
• What was good enough to ship.

That is one of the things I want to test too. AI can make building much faster, but it does not remove product judgment, taste, positioning, or distribution.

Current build investment:

Total build time so far: ~18h

Redesign and rebrand time: ~24h

Marketing time so far: ~4h

What is already working:

The product is live in production.

GitHub login works. GitHub App installation works. Selected repository access works. Repository syncing works. Tag selection works. Release-note generation works. Generated notes are saved and editable. Free usage limits are in place. Paid plans are wired. Subscription billing, cancellation, resume, plan changes, and payment failure handling are wired. There is a dashboard, repository management, release note history, usage history, terms, privacy policy, and a public repo with weekly logs.

That sounds like a lot when written out, but most of it is just the basic plumbing required before you can even ask: “does anyone want this?”

What did not go smoothly:

• I renamed the product right before marketing because the original name and icon were too close to another product (I blame AI here 😂).
• Billing took longer than expected (Merchant of sale approval was tough).
• GitHub App permissions had some sharp edges.
• Production deployment had some annoying issues.
• Realtime UI updates needed extra work.
• The UI needed much more polish than I expected.

Marketing is already clearly harder than building.

I split marketing into tiers so I do not confuse random activity with distribution.

Tier 0 was the baseline.

The product was public and usable, but I did not actively promote it. No Product Hunt, no Reddit, no Hacker News, no launch thread. The goal was to measure whether anything happened from being merely public.

Tier 1 is where I am now.

Small public posts, community feedback, build-in-public updates, lightweight storytelling, and careful measurement. No paid ads yet. The goal is to learn which message gets any real attention, whether developers understand the product, and whether visitors turn into GitHub installs or generated release notes.

Tier 2 starts if there is enough signal.

That is where I plan to spend a small budget and use broader channels. The current idea is to cap Tier 2 at around €500 and use it for things like launch assets, promoted posts or tightly targeted distribution experiments.

The point of the budget is not to “buy growth.” It is to test whether the product can convert attention when attention is no longer completely accidental.

The current numbers are small, but at least they are real.

After a few X posts, the site got 510 unique visitors over 6 days:

• Jun 23: 118
• Jun 24: 107
• Jun 25: 73
• Jun 26: 62
• Jun 27: 72
• Jun 28: 78

That is not bad, but it is also nowhere near the fantasy version of “I launched and the internet noticed.”

It mostly confirmed what I suspected:

shipping is only the start. A working product does not create distribution by itself.

For the next phase I am tracking:

• Visitors
• GitHub App installs
• Activated repositories
• Generated release notes
• Customers
• Revenue
• Build hours
• Marketing hours
• Money spent on distribution

The goal is not to prove that this is easy. The goal is to find out where the real bottleneck is for a solo developer using modern AI tools.

• Maybe the product is useful.
• Maybe the problem is too small.
• Maybe the positioning is wrong.
• Maybe the distribution is the whole game.
• Maybe AI makes the build phase faster, but leaves the hard commercial questions untouched.
• Maybe all of those are true.

That is what I want the experiment to show.

Links for context:

Product:

https://blahblah.dev/

GitHub App:

https://github.com/apps/blah-blah-github-app

Public repo and logs:

https://github.com/secersh/blahblah

For people who have done small SaaS launches before:

• What would you track besides visitors, installs, usage, revenue, and distribution spend?
• At what point would you decide the problem is not painful enough?
• How would you structure a small Tier 2 marketing budget?
• Did your first real users come from communities, direct outreach, build-in-public, SEO, launch platforms, or something else?
• How long did it take before you had enough signal to stop guessing?

secersh

More info @ https://github.com/secersh/etzee