Building an AI companion app: 6 problems and fixes

A lot of people have no one to talk to at the end of the day. Friends are busy, family is far away, and some things are hard to say to anyone. That's why AI companion apps exist: you pick someone to talk to and chat with them any time.

Building one looks simple. A chat screen, a system prompt and a model call. Then the real problems show up, and most of them aren't about the model.

I built Saathi, an AI companion app for Android and iOS, to deal with six of them. Here's each problem and what Saathi does about it.

1. Every chat sits on someone's server

The problem. In most chat apps, every message goes to the company's server and stays there. In a companion app, those messages are about people's families, their exams, their bad days. That server becomes the riskiest thing you own. You have to secure it, back it up, and keep a privacy policy you can actually stand behind.

How Saathi solves it. The phone is the backend. Chats, companions and memories live in an encrypted SQLite database on the phone, and the key is kept in the phone's secure storage. Nothing a user writes reaches you, the person who publishes the app. It goes only to the AI service the user picked.

Users also get the controls they'd expect from a private app: an app lock with a PIN or Face ID / fingerprint, an option to hide the app in the app switcher, export and import, and one button that deletes everything.

2. The model bill grows with every message

The problem. If your server calls the model with your API key, every message costs you money. A companion app is chatty by nature, so the bill grows fastest with your most loyal users. You end up adding daily limits, plans and usage tracking before you've even launched.

How Saathi solves it. Each user brings their own key. In Settings → AI they pick a service (Ollama Cloud, OpenAI, Claude, Gemini, OpenRouter, Groq or any OpenAI-compatible API), paste their key and choose a model. Save and test sends one tiny message and says whether the key and the model work.

You pay for no model calls and have no limits to manage. The trade-off is real: users need a key, and chat quality depends on the model they choose. Small models are weaker at Hinglish and at staying in character.

3. Most companion apps are English-first

The problem. Many people don't text in English. They text in Hinglish ("kal interview hai, thoda tension ho raha hai"), or in Hindi in Devanagari. An app that only replies in polished English feels like talking to a customer-care bot, not to a friend.

How Saathi solves it. Users chat in English, Hinglish or Hindi, chosen when they start. The companion answers in the language and script of the user's last message, so a message in Devanagari gets a reply in Devanagari. Replies use the right grammatical gender for the user, which matters a lot in Hindi: "kya kar rahi ho" and "kya kar rahe ho" are not the same sentence. The app's own screens are in English and Hindi.

4. The companion forgets everything

The problem. An LLM remembers nothing between requests. A chat that runs for weeks doesn't fit in the context window, and sending all of it every time gets slower and more expensive. A companion that forgets your sister's name after three days doesn't feel like a companion.

How Saathi solves it. Each request carries a few layers of context, each with a fixed size:

• the recent messages, within a budget;
• short memories like "Has an interview on Friday", kept up to date in the background;
• a summary of the story so far, under 200 words;
• a few older lines that share rare words with the new message, found on the phone with no vector database.

Users can see, edit, add and delete every memory, and the memories they write themselves are never changed by the model. I wrote up the details in Long memory for an LLM chat, without a vector database.

5. One personality doesn't fit everyone

The problem. Some people want a partner to talk to. Others want a best friend, someone who talks like their Maa, or a coach who keeps them on track. A single "helpful assistant" persona fits none of them.

How Saathi solves it. It comes with 11 companions, each with a face, a nature and a way of talking: two partners, two best friends, Maa, Papa, an elder brother, an elder sister, Dadi, a listener and a coach. Users can also make their own: name, photo, relation, nature, language, backstory and interests, with a live preview. A companion can send a daily check-in at a time the user picks, like "Khana khaya beta?"

6. Safety can't be an afterthought

The problem. People open a companion app on their worst days too. Teenagers will find it. And partner companions need clear limits. If safety is added after launch, it usually shows up as a bad story first.

How Saathi solves it. The app asks for a birthday first, and you set the minimum age. Users under 18 never see partner companions. Partner companions are romantic, within limits written into every prompt. When someone writes about suicide or self-harm, a helpline card shows, and users can report any reply.

Making it your own

All of this is only useful if you can publish it under your own name. In Saathi, the app name, colours, helplines, report email and privacy link are in one file, brand.json. The icon, splash screen, companions and prompts each sit in their own files, so you edit files, not code. There are guides for publishing to the Play Store and the App Store, and a privacy policy template.

Where it stands

Saathi is an Expo (React Native) app. I've tested it on an Android emulator with Ollama Cloud: connecting a key, chatting in Hinglish, and the messages for a wrong key or model. It hasn't been tested on a physical phone yet, and the iOS build hasn't been made yet. It runs as a development build rather than in Expo Go, because of the encrypted database.

If you're building an AI companion app, these six problems will find you whichever way you build it. It's better to design for them on day one than to fix them after launch.