Day 45: working product, 3 people who want it, 0 users connected. The gap is the whole story.
I'm 16, self-taught, building SubKitt solo — it reads your GitHub commits and drafts 5 tweets from them, then emails a fresh batch every Monday. For people who ship constantly but never post.
What actually happened in 45 days:
The product works. Connect GitHub, get drafts in ~60s. The part I'm proud of isn't the LLM call — it's the layer underneath that classifies each commit from its diff shape and clusters a week's work into a story, so drafts read like "shipped X" not "updated 4 files."
Three ideal-fit founders replied "I'll definitely try it." None have connected yet. That taught me the bottleneck isn't whether people want it — it's the friction of "connect your GitHub to a tool you've never heard of."
A skeptic gave me my most useful feedback: he was wary the output would turn into noisy, repetitive build-in-public spam. That one comment is why the commit-intelligence layer exists.
And I posted in r/SaaS asking where everyone's first user came from. It turned into a strategy clinic — the through-line from a dozen founders was the same: first users come from direct conversations and places that don't scale, not audience size.
So that's where I am. The build was the easy part. Distribution is the actual job, and I'm doing it in public — wins and faceplants both.
If you ship more than you post, it's live and free to try at subkitt.com — and honestly I'd value hearing what would make you trust a tool like this enough to connect. That's the thing I'm stuck on.
I'm curious where the idea for the product came from.
In my experience, SaaS ideas usually come either from a personal pain point (that's how my own product, CoTel, started) or from talking to potential customers and discovering a common problem.
Was this something you experienced yourself, or did you notice it while talking to other developers?
I'm also curious whether you did any user interviews before building it, or if you're validating the idea as you go.
The reason I'm asking is that I'm currently learning the same lesson myself — trying to understand how much validation should happen before building versus during the building process.
The real blocker is not distribution yet. It is trust before activation.
Three people saying “I’ll try it” but not connecting GitHub means the value is interesting, but the first action feels too expensive for a tool they do not trust yet.
I’d test a lower-friction path before asking for GitHub access.
Something like: paste 3 recent commit messages or a repo link, get a sample batch of tweets, then ask them to connect GitHub only after they see the quality.
That lets SubKitt prove the commit-intelligence layer before asking for permission.
The positioning could also shift slightly from “drafts tweets from commits” to “turn shipped work into founder posts without making it sound like build-in-public spam.”
That directly answers the skeptic’s concern and makes the product feel more thoughtful than another LLM posting tool.
Most useful comment I've gotten on this. Trust-before-activation is exactly the diagnosis.
One wrinkle on the paste flow: three commit messages with no diffs or PR context is the thinnest input the engine ever sees — and that's what I'd be using to earn trust. Someone pastes "fix bug / update deps / wip," gets mediocre output, bounces. So I'm leaning toward "paste a repo link" instead: public commits are fetchable without OAuth, so I get real history at zero permission cost. Stronger demo, same friction.
The positioning shift is the part that sticks with me. "Without sounding like build-in-public spam" sets a quality bar — which is the whole point, but also means the sample has to actually clear it or the promise backfires.
Testing it. Real question is whether people who see a good sample connect after, or whether OAuth is friction regardless — in which case the fix is scoping the ask down, not proving quality first.
Exactly. The repo-link path is the right first test because it lets SubKitt prove quality before asking for GitHub access.
I think there’s a clean activation flow here: no-OAuth sample first, then a narrower GitHub ask only after the output is good enough.
Send me your email and I’ll continue privately. I can map the activation test, positioning angle, and first conversion path in a tighter way there.
Yeah, let's do it — [email protected], or wherever's easiest for you.
The thing I most want to pressure-test with you is the conversion question: whether a good no-OAuth sample actually gets people to connect, or whether OAuth is friction no matter how good the sample is. If it's the latter the fix is scoping the ask, not proving quality.
I'll have the repo-link flow built to test against. Appreciate you, genuinely.
Sent you the note, Hassan.
Kept it focused on the no-OAuth sample flow, GitHub connection point, and how to test whether the blocker is trust or OAuth friction itself.
Appreciate this, Aryan — and the thread genuinely gave me the direction I needed, the trust-before-activation framing especially.
Going to be straight: I'm 16 with basically no budget and zero revenue right now, so I can't do the paid breakdown. No worries at all on your end.
I'm going to build the repo-link sample flow and run the 7-day test myself first — the public exchange already pointed me at the right question. Would love to keep trading notes as peers, and I'll report back what the conversion data actually shows.
Thanks again, genuinely.
Totally fair, Hassan. Appreciate you being straight about it.
Then I’d just run the repo-link test yourself and watch the data cleanly. If the sample gets saves/copies but not GitHub connects, OAuth is the blocker. If the sample itself gets ignored, quality or positioning is the blocker.
No need to overthink it before you have those numbers.
Build it, run the 7-day test, and report back with what happened.
Appreciate you being cool about it, man.
That's a clean way to read it — saves/copies but no connect means OAuth's the wall, sample ignored means it's quality or positioning. Gives me an actual signal instead of guessing.
Building the repo-link flow after exams, running the 7 days, and I'll come back here with the real numbers. Thanks again.
Sounds good, Hassan.
Run the test first. The numbers will make the next decision much clearer than more theory right now.
When you have the 7-day results, share what happened: sample views, saves/copies, GitHub connects, and where people dropped.
That’ll tell you whether the problem is trust, OAuth friction, or the sample quality itself.
This comment was deleted 5 days ago.