Building AI Into Your Mobile App Without Wrecking Battery, Privacy or Cost

Adding an AI feature to a mobile app is easy to demo and hard to ship. Three things decide whether it survives contact with real users: where the model runs, what leaves the device, and what each request costs you. Here is how we make those calls.

1. On-Device or in the Cloud?

This is the first decision and it shapes everything after it.

In practice most apps end up hybrid: a small model on the device for the common case, escalating to the cloud when the task genuinely needs it.

• On-device — instant, works offline, nothing leaves the phone, but limited by the handset
• Cloud — far more capable, but adds latency, needs a connection and bills per request

2. Battery and Thermals Are a Feature

A model that drains 8% of a battery in a minute will be uninstalled, however clever it is.

We profile on mid-range Android hardware rather than flagships, because that is what most Indian users actually carry. Sustained inference also throttles the CPU, which slows down everything else in the app.

• Batch requests instead of firing on every keystroke
• Cache aggressively — the same question often comes twice
• Quantise models so they fit comfortably in memory

3. Privacy Is Not a Checkbox

If user content leaves the device, you now have a data protection question to answer.

India's DPDP Act makes this a legal matter, not just good manners.

• Say plainly what is sent, and give a way to opt out
• Strip identifiers before anything is transmitted
• Do not log prompts containing personal data
• Check whether your provider trains on your submissions

4. Cost Discipline

Cloud inference is billed per token, and a popular feature can become the largest line on your bill.

We model cost per active user before launch, cap spend per account, and set a hard budget alert. A feature nobody has priced is a feature waiting to surprise you.

5. Design for Being Wrong

The interface has to assume the model will sometimes be confidently incorrect.

Our mobile app team builds these guardrails in from the first sprint rather than bolting them on after a bad review.

• Show the source or reasoning where it exists
• Make correcting the output easier than redoing it
• Never auto-commit an irreversible action
• Fail back to the manual path rather than a dead end