All work
Case study
AI analyst SaaS: ask your database and documents in plain language
A multi-tenant product where business owners connect a database or upload documents and get numbers, tables and charts from questions in Russian, Uzbek or English — with every SQL query checked before it runs.
- Client
- Own SaaS product (Uzbekistan & CIS)
- Role
- Founder-engineer — research, architecture, full stack, operations
- Timeline
- Research → MVP in production
- Stack
- PythonFastAPIPostgreSQL + pgvectorsqlglotOpenAI / AnthropicaiogramReactTypeScriptVega-Lite
Problem
Small and mid-sized businesses in the region keep their data in databases, accounting exports and spreadsheets, but have no analyst and no BI tool. Generic chatbots either can't reach the data or invent numbers.
The product had to answer real questions from real data, safely: the AI must never be able to change or leak a customer's database, and tenants must never see each other's data.
Approach & architecture
- Started with market and competitor research, a vision, an architecture, a roadmap and milestones M0–M8 — nineteen planning documents before the first commit.
- A channel-agnostic engine emits typed answer events from a bounded tool loop (run SQL, describe schema, retrieve knowledge, build chart), so the web app and the Telegram bot share one brain.
- A SQL gateway parses every generated query — SELECT only, allowed functions, row limits — and runs it in a read-only transaction with timeouts and a circuit breaker.
- A semantic layer: the schema is read, an LLM drafts business descriptions and the owner confirms them; verified queries are reused by vector similarity. Document Q&A uses hybrid vector and full-text search with citations.
Result
- A deployed MVP with continuous delivery: every push to main is linted, tested, evaluated and deployed behind a health check.
- Answers arrive as cards with a restatement of the question, a table, a chart, follow-up suggestions and a “how it was calculated” panel.
- Web app, Telegram bot and Telegram Mini App sign-in run on one backend.
What made it robust
- Tenant isolation with row-level security on every table; source credentials encrypted with AES-GCM; argon2 passwords and rate limits.
- A corpus of 49 SQL-injection attacks that must all be blocked for a merge to pass, and an answer-quality eval gate at 90% or higher.
- 160+ tests, headless-browser end-to-end checks, daily database backups and an operations runbook.
Have a similar problem?
Tell me about it — I'll reply with an honest view of scope, approach and what a first milestone could look like.