Run on Cloudflare's free plan. Nothing we measured comes near its limits. If the app ever outgrows it, the next step up is about ₹450 a month, billed monthly, and we can drop back to free whenever traffic falls.
Yes, and without caveats.
Our server takes Cloudflare 1 millisecond to handle a request. Across thousands of test requests the slowest single one was 15 milliseconds, and nothing failed — not one request. We then increased the load eight-fold, from 10 requests a second to 80, and the response time did not change at all.
For a few hundred people, with most of the app's content already stored on the phone, this is comfortable overkill.
The only delay is distance. Requests currently travel to Singapore and back, which adds about 150 milliseconds. That is still perfectly fine for an app — people will not notice it — and buying a domain name should cut it by routing us through Delhi instead.
It is free at our size, and we will not come close to the limit.
100,000 requests a day. A request is one time the app asks our server for something — for example, pulling the shlokas for a festival.
Most of the app's content is built into the app itself and lives on the phone. The server is only involved for a small number of things. That is what makes this comfortable.
| Situation | People | Requests |
|---|---|---|
| An ordinary day at the ashram | ~200 | a few thousand |
| A festival day, our busiest | 500–600 | ~30,000 |
| What the free plan allows | — | 100,000 |
So even on the busiest day of the year we would use roughly a third of what is free. And festival content is saved onto the phone the first time it is opened, so the same person opening it again costs us nothing. Those festivals come once a year.
The paid tier is about ₹450 a month and covers 10 million requests a month — around 330,000 a day, or eleven festival days in a row. There is no contract and no minimum term; it is billed month to month and we can return to the free plan at any time.
For context, we would have to be running an app far larger than the ashram before this becomes a real cost.
That notice is about diagnostic logs — the notes the system keeps for us so we can find out what went wrong if something breaks. It is not app traffic, and it is separate from the 100,000 requests above.
If we ever pass it, we simply receive fewer of those notes for the rest of the day. The app keeps working normally and there is no charge.
This is not a brochure claim. We put the real server under real load and measured what happened.
What is a millisecond? One thousandth of a second. A blink of an eye takes about 150 of them. In the time it takes you to blink once, this server could answer 150 requests.
The real question is not “is it fast when quiet” — it is “does it slow down when crowded”. So we kept doubling the traffic and watched.
| How busy we made it | Time the server took | Failures |
|---|---|---|
| 10 requests every second | 1 ms | 0 |
| 20 requests every second | 1 ms | 0 |
| 40 requests every second | 1 ms | 0 |
| 80 requests every second | 1 ms | 0 |
That middle column never moves. That is the entire result. We made the server eight times busier and it answered exactly as fast as when it was idle. The slowest single request out of all 6,752 was 15 milliseconds — still a tenth of a blink.
For scale: 80 requests a second is roughly ten times busier than our busiest realistic moment, which would be a festival evening with everyone opening the app at once.
These timings come from Cloudflare's own record of each request, not from our stopwatch, so they are not affected by how good our office internet is.
When you tap something, you wait about 0.15 seconds. Almost none of that is the server.
Our requests currently fly to Singapore and back. That journey takes about 149 milliseconds. The server's share of the wait is 1 millisecond.
So if we ever want the app to feel snappier, the thing to fix is the journey, not the server. Buying a domain name is what fixes it — see below.
A domain name — roughly ₹1,000 a year.
Two reasons, both practical. Our traffic is currently being routed through Singapore rather than Delhi, which makes the app slower than it needs to be for people here. A domain of our own fixes that. It also lets us keep content stored on the phone for longer, which cuts our request count further and pushes the free plan even further out of reach.