My app costs less than my phone contract to run. Here is exactly how.
Budgets, guard rails and AI tokens. How I keep a free support app lean without ever pulling the plug on people who need it.
Adrian Davies
Last month Solaces cost me £9.42 to run.
That is not luck. It is the whole design.
Solaces is a free, anonymous peer support app. You tap a button and a real person, an everyday volunteer listener, can pick up and talk. No subscription, no adverts, no premium tier with the good bits locked away. Free only stays honest if the thing behind it is cheap to keep alive, so I built it lean from the first line of code.
It runs in a browser today. And as I write this, the iPhone version is sitting in Apple's review queue. If Apple clears it, people will be able to download it straight from the App Store. I mention it because it shapes everything below. Whatever goes into that app has to justify its cost before it earns a place.
I spent years building enterprise cloud and DevSecOps for large organisations. Terraform, GCP, AWS, pipelines, the lot. The most useful thing that experience taught me was what to leave out.
1The bill, in black and white
Here is the whole £9.42, line by line.
- The database, which holds every chat, note and setting£8.80
- AI safety checks on messages, billed per use£0.51
- Live chat updates, so messages arrive as they are sent£0.06
- Data going back and forth, sounds and pictures included£0.03
- Small background jobs that wake, do one job and sleep£0.02
- Total£9.42
Nearly all of it is the database. The AI, the part people assume must be expensive, came to about fifty pence.
Since Solaces launched, 624 conversations have happened in it. Spread last month's bill across all of them and each one cost about one and a half pence. Every one of those people paid nothing at all.
The £9.42 does not include the £79 a year Apple charges for the developer account that gets the iPhone app into the App Store. I will carry that one whether the app has ten users or ten thousand.
There is no clever trick behind any of this. It is what happens when every part of the design has to answer one question before it gets built. Does this earn its keep?
2Pay for what happens, not for what might
Most apps pay for servers running flat out whether anyone shows up or not. Solaces does the opposite. When nobody is reaching out, almost nothing is running, so almost nothing costs money. The pieces that do cost something wake when someone taps the button, do one small job, and go back to sleep.
It is like only paying for electricity while the kettle is on.
The website and the app share one codebase, so a fix made once works everywhere. The sounds in the Calm section of the app are real, free to use nature recordings. Nothing is stored that does not need to be.
3The stack, and why each piece earns its place
I pay for the infrastructure behind Solaces by use, not by the month. Partly because I know that world well after years in it, but mostly because of how it charges. Put the same setup on big always on servers and I would have been paying several times as much before a single person signed up.
Every change starts in my GitHub repository. When I finish something, it goes from the repo to the live app automatically, no manual steps. That connection earns its keep twice. Each change stays small, so if something breaks I know which change did it. And it keeps publishing cheap in every sense. No servers for me to babysit, no evening lost to deployment chores. It also keeps the bill predictable, which matters when the whole design leans on knowing what things cost before they happen.
GitHub is also my whole development process, not just storage. Every change goes in as a commit with a note explaining why. When AI writes code, I read it in a pull request before it lands. And if anything breaks, I can put the app back to the last good version without drama. That safety net is what makes it possible for one person to keep something like this healthy.
4Budgets and alerts from day one
I did not bolt the money side on afterwards. Monthly budgets and alerts were part of the setup, so as spending passes each mark, an email reaches me well before anything becomes a problem.
Think of it as the low fuel light on a car. It comes on with plenty left in the tank.
5Guard rails, not kill switches
This is the part I think most founders get wrong.
The easy option is a hard cap. Hit the budget, switch everything off. For a shopping app, fine. For an app where someone might be reaching out at two in the morning, that is not an option I am willing to take.
So the guard rails are there to give me time, not to pull the plug. The bill grows with use, in steps I can see coming. More people means more messages, more checking, more storage. Scaling here looks like a slope, not a cliff. And if growth ever outpaced the budget, the first move would be to find the money, not to switch people off.
6The AI, and what it really costs
AI shows up twice in this story, and people assume it is the expensive part. It is not.
The AI inside Solaces checks messages for safety. Each call is a handful of tokens and only runs when it is needed. Billed per use, it grows with the number of people, so the same guard rails cover it. Before choosing any model I worked through what each option would cost in practice. Gemini came out as the sensible fit for the job.
The AI I build with, mostly Claude Code, is a different animal. It does not scale with users. Whether ten people or ten thousand show up tonight, the tokens behind the code cost the same. It belongs on the building side of the ledger, not the running side.
That distinction matters more than any clever optimisation.
Cost that grows with users needs guarding. Cost that does not is just a tool.
Managing Claude Code is mostly restraint. Small, specific requests rather than throwing the whole codebase at the model. I read everything before it goes near the live app. And lean architecture compounds. One shared codebase means less for the AI to write, fewer tokens, smaller bill.
7The question that kills features
When a new idea comes up, my first question is not "how fast can we ship it?" It is "what will this cost to run for the next year?"
That question has quietly killed more features than any bug. I have deleted more than I have added, and the app is better for it.
Where the savings go
Keeping costs down is not about getting rich. Nothing is coming in yet. It is about keeping Solaces free for the person who needs someone at two in the morning and cannot stretch to another subscription.
Will it stay this lean? Honestly, I do not know. If many more people find their way here, the bills will grow with them. But the principle stays. Solaces should cost as little as possible to run, so it can cost you nothing to use.
Small bills. Careful choices. A door that stays open.