Day 8: shipped the landing page (was supposed to be Day 5)
Quick ship update.
8 days ago I posted my Day 1 story here as a broke student trying to validate an AI tool for technical founders. Today the landing page is live: subkitt.com
The arc:
- Days 1-4: positioning, conversations, GitHub repo, copy drafted
- Days 5-6: I was sick. Lost 2 days.
- Day 7: came back, deployed to Vercel
- Day 8: domain wired, waitlist open, landing page shipped
What helped most:
- @aryan_sinh gave 10 rounds of free product consulting on my Day 1 thread. Reshaped the entire positioning from "AI that turns commits into tweets" (mechanism, reads like a writing tool) to "you ship, your work turns into inbound" (outcome, reads like a system). Different price, different user, different product.
- @StasyBashin (building CoTel for Telegram) gave me the language. "I don't want to be a blogger" became the ICP definition.
- @mahiraaaa caught me presenting a hypothesis as data and forced an honest correction. Trust > looking smart.
Where I'm at:
- 2 X followers
- $0 MRR
- 0 waitlist signups so far
- A real URL
Honest ask: if any of you are building in public and hate marketing, the page is at subkitt.com. Tell me what reads wrong cold. Don't be polite.
Next: drive traffic, run a $0/$19/$49/$99 anchor pricing test in 5 conversations (promised @mahiraaaa I'd report back), and start scoping the actual agent MVP.
Week 1+1 done.
It’s funny how people approach building a product from completely different angles.
In my case, I left the landing page for last — because at the very least, I want real screenshots from the actual working product. So I focused first on architecture, databases, and infrastructure. Only now am I getting close to the landing.
And honestly, I haven’t even started thinking about positioning or marketing philosophy yet.
From what I see, you’ve taken the opposite route — and it might actually be a smart one.
Curious to see how it plays out. Good luck!
Honest tradeoff: I bet on positioning-first because I wanted real customer conversations to shape v1, not the other way around. The risk is that the landing page promises something the product has to deliver — which is now a real-time forcing function (just got my first partnership inquiry yesterday off the page alone, no product to demo).
Your route is the safer one. You ship a real product, the page is downstream of working software. Less reverse-engineering risk.
Different bets. Mine pays off if I ship v1 fast. Yours pays off when the product is undeniable. Watching how yours unfolds — drop me a link when the page goes up.
That’s actually a very fair point — and to be honest, even with my “build-first” approach, I’m still constantly talking to potential users.
Right now it’s mostly friends, colleagues, and people around me. I ask them about the features and workflows I’m designing, whether they’d actually be useful in real life, and I’m already getting early feedback and suggestions that influence the product.
But one thing this process taught me very quickly: implementation reality can seriously reshape initial ideas.
I ran into multiple architectural and technical constraints while building CoTel. In some cases, features I originally imagined simply turned out to be impossible — or at least not possible in the exact form I planned at first.
That’s why I think there’s also a certain risk in the “landing-first” approach: you publicly commit to functionality before you fully understand the implementation boundaries. And later you may discover that some things from the original positioning either can’t be built at all, or require major compromises.
Food for thought 🙂
P.S. I finally published the first MVP version of CoTel. You can already try real Telegram AI queries, explore the interface, and even send feedback directly through the app. Feel free to take a look and test it yourself. https://cotel.onrender.com/new-analysis.html
You're right about that risk and I've felt it twice already.
Two specific places the gap is real for SubKitt:
My mitigation: building v1 with abstract architecture (event source → draft generation → channel delivery) so I can change the actual mechanics under the same positioning if implementation forces it. Doesn't fully solve your point but reduces the rewrite cost.
Genuinely useful pushback. Going to test CoTel properly after my exams this week — proper feedback then, not a quick "looks great."
Good luck with your exams!
Thanks!