SugarTrack and the case for offline-first apps in Sri Lanka
An offline blood sugar tracker with no account and no server just hit Hacker News. The architecture is the interesting part, and it's a pattern SL builders should copy.
An offline blood sugar tracker landed on Hacker News this week, and the feature list is not what caught my attention. SugarTrack is a free Android logbook for glucose readings, and its pitch is one line: free, no account, no internet, everything stays on the phone.
That last clause is the whole product. Most builders reach for a backend by reflex. This one didn't, and the result is cheaper to run, easier to trust, and better suited to how people in Sri Lanka actually use their phones.
🔍 What the app actually does
Per the project page, SugarTrack is Android-only, distributed as a v1.0.0 APK straight from GitHub rather than the Play Store, which means you have to allow installs from unknown sources. It's free and open source. The feature set is deliberately small:
- Log a reading with time and context: fasting, before/after meal, bedtime, or random
- Optional notes and meal photos attached to a reading
- Latest value on the home screen, colour-coded against your own target range
- History browsing plus a trend graph
- Medication and A1C result logging
- A daily reminder notification
- Export a doctor-visit report as PDF or CSV, plus a built-in backup
- Works in mg/dL or mmol/L with adjustable targets
Nothing there needs a server. That's the point I want to sit on.
Key takeaway: the single most valuable decision in this app is one that produced no feature at all. Choosing "no backend" removed an entire category of cost, risk, and legal obligation before a line of server code was written.
💰 The economics of shipping with no backend
If you are a student or a two-person team here, the reason side projects die is rarely the code. It's the monthly bill and the maintenance tax that arrives the moment you own user data.
| Concern | Cloud-backed app | Local-only app like SugarTrack |
|---|---|---|
| Monthly hosting | Free tier until it isn't, then USD-billed | Rs 0, forever |
| Auth system | Build, test, support password resets | None to build |
| Data breach exposure | Every user's health record, on your box | Nothing on your box to breach |
| Regulatory duty | Health data is sensitive personal data | You are not a data controller |
| Uptime obligation | Someone's pager, at some point | The phone is the server |
| Cost when 50,000 people install it | Scales up, sharply | Still Rs 0 |
The last row is the one that matters for a learning-budget builder. A local-first app has the same running cost at fifty users and fifty thousand. You can put it on GitHub, walk away for six months, and it still works for everyone who installed it. A Firebase-backed version of the same app is a bill you have to keep paying in dollars, from an LKR income, or the app dies and takes users' records with it.
🇱🇰 Why this fits Sri Lankan conditions specifically
Three things make local-first a better default here than it is in a market with cheap flat-rate data and near-perfect coverage.
- Connectivity is uneven and metered. A logbook you open four times a day should never wait on a network round-trip, and it should never quietly burn data allowance in the background. An app that syncs nothing cannot fail to sync.
- The clinic is where the data gets used. SugarTrack's PDF and CSV export exists because the real output of three months of logging is a sheet of paper you hand a doctor at a government clinic or a private channelling centre. That workflow doesn't need an account. It needs a printable file.
- Health data is the most sensitive category there is. Sri Lanka's Personal Data Protection Act (No. 9 of 2022) puts real obligations on anyone who collects health information, and the phased implementation details are worth reading yourself rather than taking from a blog post. The cheapest way to comply is to never hold the data. A local-only app makes that a design property, not a policy document.
If your app never transmits a reading, there is no transmission to secure, no retention schedule to write, and no breach notification to send. That is not a loophole. It is the strongest privacy position available.
If you're logging health numbers, our free BMI calculator and Sri Lanka medicine price lookup run entirely in your browser for the same reason. Nothing you type is sent anywhere.
⚠️ The tradeoffs you're actually accepting
I don't want to sell this as free. Removing the server removes real capabilities, and you should choose it with your eyes open.
| What you give up | Severity | Mitigation |
|---|---|---|
| Lose the phone, lose the data | High | Manual backup and export, which SugarTrack ships, but the user must remember to run it |
| No sync across phone and tablet | Medium | Export/import files by hand |
| No web dashboard for a doctor | Medium | PDF report replaces it |
| No crash telemetry or usage analytics | Medium | You're flying blind on what users hit |
| APK sideloading instead of Play Store | High for reach | Users must enable unknown sources, which most non-technical people won't do unaided |
That last one is the sharpest. Distribution outside the Play Store cuts your reachable audience severely, especially for an app aimed at older users managing a chronic condition. Being open source on GitHub is great for the fifty developers who read the code and bad for the fifty thousand people who just want to search "sugar log" on their phone.
🛠️ How to steal the pattern
If you're building something in the next month, run this check before you provision anything:
- List every feature that genuinely requires a server. Not "would be nice with", requires. For most personal-tracking apps the honest answer is: none of them.
- Push storage to the device. SQLite on Android, IndexedDB on the web. Both are fast and both work at zero cost.
- Make export a first-class feature, not a settings-screen afterthought. If the device is the only copy, the export button is your entire disaster-recovery story.
- Ship the file format users' institutions accept. Here that's PDF and CSV, not a proprietary sync link.
- Add a backend only when a feature forces you to, and price the ongoing LKR cost of it before you commit.
💡 What this means for you
The interesting move in SugarTrack is subtraction. No account, no cloud, no servers, and so no hosting bill, no auth surface, and no health records sitting in a database waiting to leak.
For a builder here, that's the version of a side project that survives. It costs nothing to keep alive, it works on a bad connection in a clinic queue, and it doesn't make you the custodian of data you never wanted to hold. Ship the local-only version first. Add the server later, if a real feature demands it, and if you can pay for it in the currency you actually earn.