A production LLM product delivered over SMS

Context

A question worth spending a year on: can one engineer design, build and operate a production AI product across every layer — client, backend, infrastructure and model pipeline — with agentic tooling as the force multiplier? The product is a narrative game whose characters talk to players by text message.

Why the obvious approach failed

The default shape for anything involving an LLM in 2025 was the chatbot wrapper: a prompt, a response, a chat window. It fails this product on two counts. Stateless prompt-and-response cannot sustain a narrative that has to remember what a specific player did three days ago and diverge accordingly — the state is the product, and putting it in the context window is not the same as owning it. And a chat window is the wrong channel: it requires an install, an account, and attention, whereas a text message arrives where the player already is. Choosing SMS meant giving up every UI affordance and rebuilding the experience out of nothing but text and timing.

The mechanism

The LLM pipeline drives characters with branching dialogue and per-player narrative personalization. Narrative state is owned by the system in Postgres rather than delegated to the model's context, so the story a player is in is a durable fact rather than an artifact of the last prompt.

Delivery runs over SMS through Twilio. There is no interface to design and none to learn: the product's entire surface is a message thread the player already knows how to use.

The client is Kotlin and Compose Multiplatform, sharing business logic across web and mobile, with a React and shadcn web frontend. The backend is Node.js on Postgres, deployed across Cloudflare, Railway and Google Cloud.

Internal tooling built on Claude automates content and clue generation, cutting narrative prototyping time. The product is built with the same class of system it runs on, which is the part of this work that transfers most directly to a mobile engineering role.

The hard part

Durable narrative state over a channel with no interface and hard constraints. SMS gives you no session, no back button, no loading state, and a strict message budget — a player can reply to something you sent yesterday, out of order, or not at all, and the system has to know exactly where they are in the story regardless. Every affordance a UI normally provides has to be reconstructed from message content and timing alone, and every ambiguity that a screen would resolve visually has to be resolved by the model without breaking the fiction.

Results

A production cross-platform AI system with every layer designed, shipped and operated by one engineer. The caveat, stated plainly: this is an independent product, not a company-scale deployment, and there are no user numbers here worth quoting. The claim is about engineering scope rather than traction — that the client, the backend, the infrastructure across three providers and the model pipeline were all owned by one person, which is the part relevant to a staff-level mobile role.

What I'd do differently

[NICK TO CONFIRM] Candidate: build the narrative-state model before the pipeline. The temptation with LLMs is to start where the interesting output is; the durable part of the system turned out to be the state machine underneath, and everything got simpler once that was explicit.