Case study
A live multilingual chat app that translates each message in context — preserving tone, dialect, and intent instead of going word-for-word. Built solo, end to end, by directing AI coding agents through a documented engineering process.
In short: A working product, not a prototype. Real accounts, real-time translated chat, and the unglamorous essentials done properly — authentication, row-level security, GDPR deletion, a context-aware translation engine. Built by one person acting as PM/architect and directing AI agents through a staging-first, documentation-driven process. Try it, then read on for the how and why.
The problem
People increasingly need to talk across languages in real time — partners in cross-language relationships, families spread across countries, support teams and their customers. Today's options force a bad trade: real-time tools (Google Translate, DeepL) translate literally and flatten tone, idiom, and register, while anything more natural isn't built into the flow of a live conversation. You end up with technically-correct translation that still feels wrong — sounding like a robot to the person you're closest to.
The solution
jistchat translates every message into each reader's language with context. The engine is told the speaker's dialect, formality, and the nature of the conversation, so "let's grab dinner, love" lands warmly in the other language instead of stiffly. Under the hood, the chat app is the first client of its own translation API: text plus a small context object go in; a natural translation plus structured inferences (detected language, dialect, register, intent, formality) come back.
The landscape
People already cross language barriers today — just painfully. The alternatives fall into a few camps:
Real-time translation bolted onto Zoom/Teams/Meet with bilingual subtitles and voice playback. Built for business meetings, not personal messaging.
High-quality translation and speech models sold as APIs. Less rivals than a preview of jistchat's own Phase-2 ambition — and, candidly, potential build-vs-buy options underneath it.
The closest match: real-time in-app message translation for relationships, family, and travel, plus voice/video call translation with voice cloning. This is the head-to-head.
Where jistchat fits: it's the only one combining in-flow personal chat, a context- and profile-aware engine (it learns how each person speaks over time), and a deliberate B2B-API business model underneath. The consumer app is the wedge; the engine is the business.
| Shared language | Google / DeepL | General LLM | Meeting translators | Chat app (Intent) | jistchat | |
|---|---|---|---|---|---|---|
| Real-time, inside a personal chat | ~ | ✗ | ✗ | ✗ | ✓ | ✓ |
| Carries tone, dialect & register | ✗ | ✗ | ~ | ~ | ~ | ✓ |
| Learns how you speak over time | ✗ | ✗ | ✗ | ✗ | ~ | ✓ |
The strategy
The chat app is deliberately step one — a distribution vehicle and a data flywheel. Every real conversation generates the linguistic signal and corrections that make the translation engine better. Step two is the actual business: opening that engine as a B2B translation API for the products that need exactly this — dating, gaming, support, healthcare, legal/immigration. Every architectural choice is made as if that API already has external customers, which is why the structure is heavier than a weekend project: it's built to become a platform, not just an app.
How it works
The chat app is a client of its own translation engine. The frontend owns the conversation layer (realtime, message flow, context assembly) and talks to Supabase for chat data, auth, and realtime — and to the translation API for translation. The translation engine is a standalone, versioned, token-authenticated API that knows nothing about rooms, users, or messages. Because the chat app already consumes it exactly as an external customer would, opening it as a B2B product is a lift-and-ship, not a rewrite.
Engineering rigor
A real system with the boring-but-essential parts done properly:
Every backend call requires a verified user token (local JWKS verification) — not an open endpoint.
The database itself enforces who can read what; messages are visible only to members of the conversation.
A two-phase erasure flow (soft-delete → grace period → hard delete) that anonymizes reusable data rather than destroying it.
Tenant scoping on every table, so opening the B2B API later isn't a migration nightmare.
Schema changes run and verify on a staging database before production; every migration is a versioned, replayable file.
Every translation logs structured events and updates a per-user linguistic profile, building the corpus that improves quality over time.
Process
The interesting part isn't that I used AI to code — it's how. I ran the project like a small engineering org with AI agents as the team and myself as the PM/architect making the calls.
A living /docs/ set — architecture, a phased roadmap, an append-only decisions log (every non-trivial choice, with alternatives and tradeoffs), verification checklists, a parking lot. The AI keeps these in sync in the same change as the code, so the project never drifts from its own documentation.
Real changes start with a scoped plan and a decision — tradeoffs surfaced before implementation, with approval gates on anything irreversible. Judgment stays with me; execution is delegated.
Strategy & architecture in one agent (Claude, desktop "Cowork"), line-level edits in an IDE agent (Cursor), and routine execution in an always-on agent on a server (Hermes). Split by which interface fits the task.
Heavier reasoning (architecture, schema, gnarly debugging) routed to a stronger model; routine work to a faster one — a deliberate cost/quality tradeoff.
Judgment
A few representative calls (the full log is in the repo):
Chose local JWKS verification over a per-call network check — the scale-correct path for a high-volume API — behind a single auth helper, so the method can change without touching call sites.
Stood up email + domain on a cheap placeholder instead of waiting for a final brand: a domain change later is config, not a rewrite, and the only sticky cost (email reputation) is cheapest to incur early.
A simpler identity model that's correct for the consumer app, with the path to full multi-tenancy documented as a known one-way door.
Current status
Working today at app.jistchat.com: real accounts (email magic-link auth), multi-conversation chat (direct + group), context-aware translation, per-user linguistic profiles, row-level security, and GDPR deletion. Honest scope: it's demo-grade, not yet mobile-native, and the B2B API is designed-for but not yet opened. Next up: corrections capture (thumbs up/down + inline edits to grow the training corpus), then the public API.
Built with