I didn’t plan to ship anything that weekend. What started as vibe coding a Telegram bot quickly turned into a one-hour experiment that actually shipped.
It was one of those rare mornings when you open your laptop without a roadmap, a Jira ticket, or a validation strategy. Just curiosity and a bit of mental whitespace.
I told myself I’d experiment for sixty minutes.
That hour turned into Sondrify.
From minute one, I treated it like a real product, even if the only stakeholder was me. I pushed everything to a private GitHub repository. No pressure, no audience. But deep down, the product manager in me wanted to see if I could solve a personal friction point before my coffee went cold.
The Problem: A Product Gap at 8:00 AM
It started with a very familiar experience.
I woke up with a dream that felt important. Not a full story, just a strong image and a lingering emotional weight. Within ten minutes, as the morning routine kicked in, it was already slipping away.
This is a classic retention problem. Dreams feel meaningful in the moment, but the way we capture them is broken.
- Dream journals ask for too much effort when you’re barely awake.
- Dream dictionaries offer generic interpretations that rarely fit real life.
- Professional dream analysis exists, but it’s expensive, slow, and never available when you actually need it.
I found myself asking a simple question: is there a lightweight way to work with dreams? Something immediate that doesn’t try to explain everything, but helps you reflect while the feeling is still there.
It’s exactly the kind of small, personal problem that works well for vibe coding a Telegram bot instead of designing a full product upfront.
Why Telegram? (The Zero-UI Approach)
My first instinct was simple. Don’t build an app.
The world doesn’t need another standalone mobile app for a thirty-second daily interaction. Building a React Native UI for this would be over-engineering. Telegram was the obvious choice for the MVP.
Zero friction. It’s already part of the daily routine.
Native modalities. Voice messages feel natural for recounting stories, especially at 7 AM.
Privacy. It feels intimate, not public.
Dreams are fragile data. They don’t belong in complex dashboards. They belong in a chat.
The Stack: Speed as a Feature
Once I defined the constraints, the build moved fast. I chose a stack optimized for velocity, not scalability.
For the runtime, I used Node.js with Telegraf.js. It’s lightweight, middleware-based, and handles Telegram context cleanly.
For storage, I chose Supabase. I didn’t want to overthink schemas for a prototype. It’s quick and it works.
For analysis, I used Google Gemini. I chose it over GPT mainly for the speed-to-cost ratio. For creative writing and empathetic reflection, the latency is almost non-existent.
I am huge fan of Cursor.
I can’t overstate the impact of the modern AI stack on product velocity. Cursor didn’t do the thinking for me, but it removed friction between intent and syntax. I could iterate on onboarding flows, write small middleware checks, and adjust prompts without breaking my flow state.
Since I already had my own VPS on Hostinger with Dockploy configured, deployment was a non-event.
git push, webhook, build, live.
Total time to production: about five minutes.
The Trap of Premature Complexity
I did make one classic product mistake.
The hardest part wasn’t the AI.
It wasn’t prompt engineering or voice-to-text logic.
It was multi-language support.
I wanted sondrify to support Ukrainian, English, and Russian from day one. In theory, it sounded simple. Just detect the user’s language and switch the system prompt.
In practice, it became the most fragile part of the system.
State management became messy.
Error messages needed proper localization.
The AI context window had to be primed correctly every single time to prevent language drift.
Here’s the takeaway.
Even seasoned product leaders fall into this trap. I prioritized completeness over simplicity. If I were advising a startup, I would have said: ignore localization. Ship one language. Nail the core value proposition first.
I broke the cardinal rule of the MVP, and the code complexity doubled because of it.
The Aha Moment
I decided to dogfood the product, not as the developer reading logs, but as a user looking for clarity.
I typed a dream that I saw today and that I saw a few times before, it’s some type of repetitive dream. Do you have such?
The bot didn’t rush to solve the dream. I had deliberately tuned the system prompt to avoid acting like a guru. Instead, it behaved more like a coach.
It asked how the flying felt. Anxious or free.
It asked why I needed to land.
I answered honestly. Slight anxiety. A feeling of suspension. Wanting direction.
The interpretation that followed connected the dots.
Flying reflected momentum.
The inability to land suggested progress without grounding, being mentally ahead of where reality has caught up.
It hit harder than I expected. It described my current state almost exactly. Executing on many fronts, feeling capable, but postponing the decisions that would bring things back to earth.
The Verdict
sondrify isn’t about fortune-telling. It’s about slowing down just enough to notice patterns.
This project reminded me how often we overthink products. We jump to scalability, TAM, and virality, when sometimes the most interesting things come from building something honest that you’d actually use yourself.
Out of curiosity, I tried to frame the idea as a small service and generated a lightweight pitch deck in about a minute using NotebookLM. It’s not a serious proposal, just a compressed snapshot of the experiment.
👉 Vibe Coding the Inner World (Pitch Deck.PDF)
Watch the video
I’ll keep iterating on sondrify slowly, refining the AI coach persona and simplifying what doesn’t need to be complex.
Sometimes the best work starts when you stop trying to plan it.
Leave a Reply