Field notes — what we learn shipping AI systems, written down.

The distance between an AI demo and production

Every AI project has a moment where the demo works and everyone in the room believes the hard part is over. It isn't. In our experience, the demo is roughly 20% of the work. The other 80% is everything the demo quietly skipped.

Retrieval quality is usually the first wall. The demo answered questions about ten hand-picked documents. Production has to answer questions about thousands of messy ones — PDFs with broken tables, near-duplicate versions, documents that contradict each other. Chunking strategy, metadata, and re-ranking matter more than which model you picked, and none of it shows up in a demo.

Evals are the second. If you cannot measure whether the system got better after a change, you are not engineering — you are vibing. A few hundred labeled examples and a script that scores them will save you from shipping regressions you would otherwise discover through angry users.

Then come cost ceilings. A demo that costs a few rupees per query is charming; the same query pattern at real traffic is a bill nobody approved. Caching, smaller models for routing, and hard budgets per request have to be designed in, not bolted on.

Finally, failure handling and humans in the loop. Models will be wrong. The system around them decides whether that wrongness is a caught exception or a customer incident. Escalation paths, confidence thresholds, and a person who can override the machine are not optional extras — they are what makes the word "production" honest.

#demo-to-production

WhatsApp is the UI your customers already installed

Indian SMBs keep asking us for customer portals. Our first question is always: will your customers actually log in? A portal means a URL to remember, a password to reset, and a habit to build. WhatsApp means none of that. The app is already on the phone, already open, already trusted. For order updates, appointment reminders, quotes, and support, the messaging channel wins before the portal has finished loading.

The catch is that WhatsApp is not a free-for-all. The Business API enforces template discipline: business-initiated messages must use pre-approved templates, and Meta rejects vague or spammy ones. That constraint is a feature. It forces you to decide, in advance, exactly what you will say and when — which is the product thinking most notification systems skip.

Opt-ins are the other non-negotiable. Collect explicit consent, log it, and honor opt-outs instantly. Businesses that blast unsolicited messages get their quality rating cut and their throughput throttled. The channel punishes spam structurally, which is good news for everyone who isn't a spammer.

Where does AI fit? In the reply loop, not the broadcast. Inbound messages are where an LLM earns its keep — understanding a free-text question, pulling the right order or account, and drafting a reply a human can approve or that clears a confidence threshold to send directly. Routine queries get answered in seconds; ambiguous ones escalate to a person with full context. That split — templates outbound, AI-assisted triage inbound, humans on the edge cases — is the shape we keep converging on.

#whatsapp-channel

A boring stack for exciting software

Our default stack is deliberately unexciting: serverless edge functions for compute, edge SQL for the database, object storage for files, and typed APIs end to end. No Kubernetes, no fleet of containers, no 3 a.m. pages about a node that fell over. For products that are still finding their market, we think this is the right kind of boring.

The main reason is scale-to-zero economics. Early-stage products have lumpy, unpredictable traffic — a launch spike, then quiet weeks, then a customer demo that must not fail. Serverless means the quiet weeks cost close to nothing and the spikes are absorbed without anyone re-provisioning. You are not paying rent on idle servers while you search for product-market fit; the infrastructure bill grows only when usage does.

The second reason is operational surface area. Every moving part you run is a part that can break, drift, or need patching. Workers deploy in seconds, roll back in seconds, and run at the edge close to users in India and everywhere else. D1 is just SQLite with replication — a database model every engineer already understands. Less to operate means more hours spent on the product, which is the only place early-stage hours belong.

And typed APIs — schema-first, shared types between server and client — are how a small team moves fast without breaking things. The compiler catches the mismatch before the customer does.

Exciting software deserves boring infrastructure. Save the novelty budget for the part users actually see.

#boring-stack