BTB - Budget Tracking Bot

The description states the product is a Telegram-based voice-message bot that allows users to log expenses by speaking into their phone. It transcribes voice messages and parses them into expense entries with categories and amounts. The author claims it supports English, Russian, and Spanish, including spoken numbers like “полторы тысячи” (1500). It includes features such as:

• Undo buttons for each entry
• Monthly budget tracking
• CSV export
• Stats view

The bot is built using:

• Telegram API via python-telegram-bot
• AI models hosted on Groq (Whisper for transcription, Llama for parsing)
• PostgreSQL with asyncpg for storage
• Python as the core language
• Docker for deployment

The system is designed to be fast and lightweight, with no configuration required.

Claim: The product is a voice-based expense tracker that integrates with Telegram.

Evidence: Author's own write-up.

The author frames this as a solution to a common problem: users abandon budget tracking because logging expenses takes too long. They repositioned the issue not as a feature problem but as a time-budget problem, where the time spent logging exceeds the time spent spending.

Claim: The goal was to reduce logging time from ~30 seconds to under 2 seconds.

Evidence: Author’s own write-up.

The bot is positioned as a frictionless alternative to traditional expense-tracking apps, which they claim are too slow or complex to use consistently. It is not described as a full financial management platform but rather a lightweight, voice-first logging tool.

Claim: The product is built around reducing friction in expense logging.

Evidence: Author’s own write-up.

The description does not name specific customer segments or personas. However, the author implies that the target user is someone who:

• Has struggled with traditional expense-tracking apps
• Is likely to use their phone frequently and has a Telegram account
• Values speed and simplicity over complex features

Claim: The product targets users who find existing tools too cumbersome.

Evidence: Author’s own write-up.

There is no evidence of segmentation, personas, or customer interviews. The ICP is inferred from the author's personal experience and problem statement.

The description does not contain any information about pricing, monetization, or business model. It only describes how the product works technically and what features it includes.

Claim: No pricing or business model details are provided.

Evidence: Author’s own write-up.

The author provides a detailed technical breakdown:

• Uses Groq for AI processing (Whisper + Llama)
• Built with Python, PostgreSQL, Docker
• Implements asyncpg and asyncio for performance
• Separates transcription and understanding into distinct steps
• Stores money using exact decimal arithmetic to avoid floating-point errors
• Includes a validation layer between AI output and database to prevent corrupted data
• Uses templating instead of str.format() to avoid prompt parsing bugs
• Handles time zones carefully for date boundaries

Claim: The system is built with performance, correctness, and maintainability in mind.

Evidence: Author’s own write-up.

The author also notes that the entire system is designed to be modular and replaceable — e.g., switching to a local model is a one-function change.

There is no evidence of traction or adoption. The author states:

• They have only "just started using it"
• The project was submitted to a hackathon
• No revenue, customers, or usage data are mentioned

Claim: No traction or user engagement data is provided.

Evidence: Author’s own write-up.

The product is described as a personal prototype, not yet validated in the market.

There is no mention of competitors or competitive positioning. The author does not reference existing budget-tracking tools, apps, or platforms.

Claim: No competitive analysis or context provided.

Evidence: Author’s own write-up.

• Unvalidated core premise: The project is built on the assumption that reducing logging friction will lead to sustained adoption — but this has not been tested yet.
• No monetization strategy: No pricing, revenue model or business plan is evident.
• Single-person team: Only one developer (the author) is involved, which raises questions about scalability and long-term maintenance.
• Limited language support: While it supports English, Russian, and Spanish, the author does not indicate plans for broader localization or multilingual expansion.
• AI reliability risk: The system relies heavily on AI outputs, which are validated post-processing — but there is no indication of how often validation fails or how the system handles edge cases.

Inference: The project may be at risk if users do not adopt it consistently due to unproven behavioral assumptions.

Evidence: Author’s own write-up.

1. What is your hypothesis about user behavior and adoption? How will you test this?
2. Have you conducted any user research or usability testing beyond personal use?
3. What are the plans for monetization, if any?
4. How do you intend to scale beyond a single developer?
5. Are there any known edge cases in AI parsing that have not been handled yet?
6. What is your long-term roadmap for product features and language support?