Case Study 01

Metra AI — Production SaaS for Telegram Content Automation

Solo-built end-to-end SaaS platform with multi-agent LLM orchestration. From architecture to deployment in 3 months.

Role: Founding Engineer · Timeline: 3 months · Status: Live with paying users · metra-ai.org →

The business problem

Telegram channel owners and content teams spend enormous amounts of time creating posts manually. Standard solutions either don't fit Telegram's specific UX (Buffer, Hootsuite are built for Instagram/Twitter), or rely on raw ChatGPT output that produces generic, low-quality content requiring extensive manual editing.

The core pain: content teams spend 60–80% of their time on production instead of strategy, and quality suffers because AI-generated content typically lacks brand voice, channel-specific context, and real-time relevance.

What I built

A full SaaS platform that automates the entire Telegram content workflow:

Architecture: why multi-agent instead of single LLM call

The core technical innovation is a multi-stage LLM orchestration pipeline rather than relying on single API calls. This was a deliberate architectural choice based on a key insight:

LLMs perform poorly when given too many simultaneous constraints. A single 3000-token prompt asking for "rewrite this post in voice X, with lore Y, in format Z, with rules A/B/C" produces inconsistent results because attention dilutes across requirements.

Solution: decompose post generation into specialized stages, each with a single focused responsibility.

Standard posting pipeline

Extended posting pipeline (generates from scratch)

This architecture eliminates the typical AI failures — hallucinations mid-text, structural drift, lore over-application, format breakage — that single-shot LLM calls produce.

Key technical innovations

1. Prompt sanitization layer

The image generation model initially refused to generate humans due to safety filters. Rather than switching models, I built a sanitization layer that rewrites user prompts to pass filters while preserving generation intent. This avoids the need to host more expensive alternative models.

2. Lore compression and translation

User-provided channel lore (often 3000+ tokens of unstructured text) is compressed and translated to the channel's posting language at upload time. The AI receives a structured, language-matched summary instead of raw lore, dramatically improving content relevance while reducing token costs.

3. Lore as context, not constraint

Discovered through iteration that AI over-applies lore when given it as direct instruction. Architected lore as soft context that influences but doesn't dominate generation — producing more natural content.

4. Premium LLM selection strategy

Chose specific LLMs for specific reasons:

Infrastructure

Outcome

3 months
Solo development to launch
16
Docker containers in production
Week 1
First paying users acquired
25/day
Automated posts per channel on paid tier

Launched to production within the 3-month development window. Multi-account CRM allows agencies to manage operators without exposing channel owner credentials. Active early-stage traction with growing user base.

Tech stack

BackendFastAPI · Python · Celery
FrontendReact · TypeScript · Next.js
DatabasePostgreSQL · Redis
InfrastructureDocker · Nginx · Multiple Ubuntu servers
MonitoringPrometheus · Grafana · Sentry · Uptime Kuma
AI / LLMMulti-provider stack (proprietary + open source)

What this demonstrates

Got a similar problem?

I'd love to hear about what you're building.

david@chystyi.dev →
← All case studies Next: Open Source Lipsync →