Context and problem
Writing the first message to a stranger, or the next reply in a conversation that is fading, is where many people on dating apps get stuck. A general-purpose chatbot can write something, but it does not see the profile or the chat, and it tends to produce generic text.
The product started in August 2025 as an experiment: can an assistant that sees what the user sees give advice specific enough to be useful — and is that worth paying for?
Understanding
The useful output turned out to be small: a short read of the situation — where the conversation stands, how interested the other person seems, what could go wrong, what to do next — and one message that fits. A menu of options moved the work back to the user.
Trust mattered as much as wit. The assistant must not invent details that are not on the screenshot, and an image it cannot read must not cost the user anything.
MVP and scope
- In
- Three scenarios: a first message from a profile screenshot, a reply that takes the whole saved conversation into account, and a quick read of a chat screenshot. A token balance with trial credits and payment in Telegram Stars. A Mini App for history, editing and the balance.
- Out
- Connecting to dating apps or sending messages on the user’s behalf, a native mobile app, and any automation that acts for the user. Prices are still treated as hypotheses.
What I built
- ScreenshotThe user sends a screenshot to the bot or uploads it in the Mini App — or pastes the other person’s latest message.
- ReadingOne call to a multimodal model reads the image and returns structured data: a profile, a chat or neither. An image that is neither is rejected, and nothing is charged.
- AnalysisThe assistant sums up the stage of the conversation, the other person’s interest on a 1–10 scale, the risks and the next move.
- MessageOne call to a text model drafts one message from the analysis and, for replies, from the saved conversation.
- Edit and saveIn the Mini App the user edits the draft before saving it. The saved text becomes part of the history used for the next reply.
My ownership
- Built by me
- The product from its first version: the scenarios and prompts, the AI pipeline and how it is evaluated, the backend and data model, the bot, the Mini App, token billing and payments, deployment and operations.
- With AI coding agents
- Most of the code was written with AI coding agents under my rules. I set the architecture and the constraints, reviewed the code, ran the tests and shipped the releases.
Key decisions
- A multimodal model instead of OCR
- The first version ran a separate OCR service and parsed its text. One multimodal call per screenshot replaced it: it classifies the image and returns the fields in a single step, and the OCR service was removed.
- Explicit scenarios instead of a generic workflow engine
- A configurable engine once described every scenario in YAML. I replaced it with explicit code for each scenario, which is easier to read, test and change.
- One message and the reasoning behind it
- Earlier versions generated two messages in different tones. Since October 2026 the assistant writes one message and shows the analysis it is based on.
- Model changes are decided by a test fixed in advance
- Before switching the image model I wrote down the pass criteria and ran a corpus of about 55 cases through both models. Neither met the bar, the current model scored higher, and the switch was rejected.
- Charge only for useful output
- The balance is checked before a screenshot is downloaded; an unreadable image or an unusable answer is not charged. Each model call is retried within a time budget, and every attempt is logged with its cost.
Constraints, mistakes and trade-offs
- The answer can only be as good as what is visible in the screenshot; the prompts forbid inventing anything that is not there.
- A failed model call is retried on the same model, not switched to another one: simpler to reason about, at the cost of occasional slow answers.
- An independent audit in September 2026 paused feature work until its findings were fixed.
- When the product moved to separate beta and production environments, I started new bots with empty databases instead of migrating the legacy bot’s data.
- User terms and consent are not in place yet; they come before a wider launch.
Validation and testing
- More than 6,000 backend unit tests, including a test that keeps the business core independent of Telegram.
- A full acceptance run covers 14 isolated modes, plus Mini App and frontend test suites.
- Production accepts only an image that was first released and checked in the beta environment.
- Prompt and model changes go through a prompt lab with a fixed corpus and pass criteria written down before the run.
Deployment and real status
Public beta. The bot is open, the scenarios and prices are still being tested, and there are no public usage figures.
The product runs as separate beta and production environments on Docker Compose. A wider launch is the next milestone.
What I would improve next
- Put user terms and consent in place before a wider launch.
- Measure which analyses and messages users actually keep, and tune the prompts on that.
- Move beyond Telegram: the long-term target is a standalone mobile app.
Tech summary
- Bot and API
- Python, aiogram 3 and FastAPI in one process, APScheduler
- Mini App
- Vue 3, TypeScript, Vite
- Data
- PostgreSQL, Redis
- AI
- Via OpenRouter: one multimodal call to read the screenshot, one text call to write; Jinja2 prompt templates
- Payments
- Telegram Stars; a token balance with trial, subscription and package credits
- Infrastructure
- Docker Compose with separate beta and production environments