Case study
Eleven areas of everyday life, in one private workspace.
How LifeRoster was designed and built — one place for a household's spending and everything else it has to keep track of, what it took to keep those records private and usable with no connection, the trade-offs, and the numbers that came out of real hardware.
- Everyday life
- One workspace
- Spending, bills, vehicles, meters, health records, documents, notes and money split with others — eleven areas that would otherwise be eleven unrelated apps.
- Money
- One ledger
- Expenses, recurring bills and shared costs all land in the same place, so a total, a trend and a balance are worked out rather than kept by hand.
- Your records
- Encrypted
- Encrypted where they are stored and encrypted again on the way to your backup, and private to your account.
- Every module
- Works offline
- Your device holds the primary copy. Syncing gives you a backup and a second device; it is never what makes the app work.
Case study detail
Overview
LifeRoster is a personal life-management app for individuals and households, available on web, Android and iOS in 23 languages.
It covers eleven areas of everyday life — expenses, recurring bills, vehicles, electricity meters, family health records, documents, notes, a ledger that also splits bills and settles groups, cross-module reports, an assistant, and a reminders hub that gathers everything with a date on it.
The defining decision was to put your data on your device and treat the cloud as a backup. Everything works with no connection; syncing is what gives you a second device, not what makes the app function.
The problem
The practical records of a life are scattered across tools that were never designed to hold them.
Spending lives in a banking app that cannot tell you why. Health readings live in a notebook. A vehicle's service history lives in the glovebox. Money split on a trip lives in a group chat where everyone remembers a different number.
Each of those has a dedicated app, and installing nine of them solves nothing: they share no workspace, no design language, and no sense of what is due next. The obvious alternative — a general-purpose notes app — stores text, and text cannot produce a balance, a trend or a consumption figure.
The gap was never storage. It was structure: records with real shapes, so that a total, a trend and a balance can be worked out rather than maintained by hand.
Product vision
One private workspace where every area of life is a first-class module, and nothing needs a connection to work.
Three commitments shaped every decision. Offline first, because the moment you record a meter reading or an expense is exactly the moment you have no signal. Private by default, because health and financial records are the most sensitive data most people own. And identical behaviour across modules, because a product with eleven areas cannot afford eleven interaction models.
A fourth turned out to matter as much: the app targets modest Android hardware, on 3–4 GB phones. Smoothness there is treated as a correctness requirement rather than polish, and that constraint rejected several designs that would have been perfectly fine on a flagship.
Design decisions
One design system, one interaction model, and rules strict enough to survive eleven modules.
Every module is described in exactly one place — its name, its one-line summary, its icon and its colour — so it can never be presented two different ways on two different screens. Each module owns a single colour for its whole life, no two modules share one, and the colour has to suit the subject: electricity is an electric cyan, not an amber that would read as a sibling of Notes' yellow.
A row is a way in, not a control panel. Tapping a row opens the record; rows carry no delete button and no edit pill, because a mis-tap in a scrolling list is how people lose things. Every record has exactly one place it can be deleted from, destructive actions always confirm first, and records with history attached refuse deletion with an explanation instead of quietly taking their children with them.
Every surface has four required states — loading, empty, error and content — and a flash of 'nothing here' before the data arrives is treated as a bug, not a cosmetic detail.
Nothing is a magic number. Colour, spacing, corner radius and animation timing all come from one shared set of values, and a one-off button size is a rule violation rather than a judgement call.
The approach
Put the data on the device, and work every figure out from the records behind it.
Because the device holds the primary copy, the app is fully usable in a basement, on a plane, or on a prepaid phone with no data left. Syncing exists so a second device and a reinstall both work — it is additive, never load-bearing.
The second principle did more for correctness than anything else: derive, never duplicate. A ledger balance comes from its entries. Electricity usage comes from consecutive readings. A bill's payment history is the spending it produced. Wherever a number is worked out rather than stored beside its source, it becomes impossible for the summary and the history to disagree — an entire category of bug simply stops existing.
The same thinking governs deletion. Records with history refuse to vanish silently, and a deletion made on one device can be recovered from another, because losing data is the one failure a personal record-keeper cannot come back from.
Challenges
The hard parts were protecting existing data during a security upgrade, adding sharing without weakening privacy, and a performance problem that was not where it looked.
Introducing encryption for data already on people's devices meant upgrading real health and financial records in place, with no acceptable outcome other than keeping every one of them. The upgrade was built so the original stays intact until a complete, verified replacement exists, and so an interruption at any point — a crash, a dead battery — leaves the device recoverable rather than half-converted.
Adding sharing was the other delicate one. Letting people split a bill with a friend meant introducing the first data in the product that concerns more than one person, without loosening anything about how the rest is isolated. Sharing stays deliberately narrow: it is always explicit, it never reaches into your own records, and seeing what someone shared with you changes nothing until you choose to bring it in.
The performance work was the biggest surprise, and it is the one worth telling properly.
Keeping it yours
Privacy that stays abstract is worth very little. These are the parts you can see, switch on and undo yourself.
Your records are encrypted on the device whatever you do, but a phone gets handed to a child, a colleague or a repair shop. So the app can sit behind a lock of its own — a PIN, or your fingerprint or face — and it asks again when you come back to it. It is optional, and it changes nothing about how the records underneath are protected; it changes who can look at them over your shoulder.
Every device signed in to your account is listed where you can see it, and any of them can be signed out remotely from the device in your hand — the one thing you want to be simple about a phone you no longer have. Signing out clears that device's copy, so a handed-on phone carries nothing forward, and signing back in restores it. Deleting the account is a normal action in the app, not an email to support.
The last one is easy to overlook until it is missing. Every screen stays current on its own: record an expense and the month's total, the category breakdown and the reminders list have already moved by the time you are back on them. Nothing has to be pulled to refresh, and no screen shows a figure that a screen behind it disagrees with — the direct benefit of working every total out from the entries rather than storing it beside them.
- App lock
- PIN, fingerprint or face
- An optional lock in front of the whole app, for the phone that gets passed around at home.
- Your devices
- See them, remove them
- Every device signed in to your account is listed, and any of them can be signed out remotely from the one in your hand.
- Handing a phone on
- Signing out clears it
- Switching accounts wipes the local copy, so the next person finds nothing. Signing back in restores it.
- Every screen
- Updates as it happens
- Save something and every list, total and chart that depends on it moves at once — no refresh, and no figure left out of date.
Performance
Measurement overturned the plan. Four waves of work had optimized the wrong thing.
A full audit ranked six likely causes of slowness and four waves of fixes shipped against them: faster list rendering, work deferred until a screen is actually visible, an editor rebuilt so typing a character no longer redrew the screen, and less loaded at startup.
Then the work was measured on a real 3.6 GB Android phone, and the result was not what the plan predicted. While scrolling, the app's own logic was reported as causing zero slow frames — everything four waves had optimized was no longer the bottleneck. Drawing the frames was: 9 ms against a 16.7 ms budget, the signature of too many overlapping layers being painted on top of each other.
The fix was to recognize the device rather than the code. On phones under 4 GB the resting shadow beneath each card is dropped, while the cards keep the hairline border that actually separates them; deeper shadows stay where they carry meaning. Because every component reads its depth from one shared place, that was a single change covering the whole app. Measured again on the same phone, scroll jank fell from 15.5% to 10.5% and frame time from 9 ms to 6 ms.
Startup was then measured end to end for the first time, and it reframed the remaining work too: the parts that looked expensive — unlocking, upgrading and loading the stored data — accounted for only a small fraction of the time. Most of it was already spent before any of the app's own code ran. That closed off a whole direction of micro-optimization that would have produced nothing.
- Scroll jank
15.5%10.5%32% lower
- Measured on the same 3.6 GB Android phone before and after the fix, on a release build.
- Frame time
9 ms6 ms33% lower
- Median time to draw a frame, against a 16.7 ms budget for smooth scrolling.
- Cold start
- ~745 ms
- From tapping the icon to a usable screen, on a release build with real synced data.
- Warm start
- 42 ms
- Returning to the app when it is already in memory — what most people mean by 'instant'.
Quality
Conventions enforced mechanically, because a rule that is not checked is a rule that erodes.
Anything that gets stored is defined once, in one place, and the labels people read are derived from that definition. It is why the app can ship in 23 languages without a translation ever changing what is actually recorded.
Updates to the app are only ever additive where your data is concerned. Discarding records to make a change convenient is prohibited outright, and the upgrade path is tested by replaying every historical version in sequence — so an install that has been through two years of updates is exercised, not assumed.
Isolation between accounts is verified continuously rather than reviewed once, and re-verified after any change that touches sharing.
One testing lesson was learned the expensive way and then written down: tests prove your own side of an agreement, never the other side's. Four real bugs passed every check and were caught only by running the thing for real. Anything that depends on an outside party now gets a live check, not just a simulated one.
Across screens
Phone, tablet and desktop, with the whole app on every one of them.
Every screen is laid out for the size it is shown at. At desk width navigation sits in a persistent sidebar and forms open as centred dialogs; on a phone the same work happens through a tab bar and sheets that rise from the bottom. Nothing is dropped on the way down — every module is available on web, Android and iOS.
Type and icons scale with the screen and respect the font size set on the device, so a small phone does not look oversized and a large accessibility setting does not break the layout.
Lessons learned
Four that changed how the rest of the project was built.
Measure before optimizing, then measure again afterwards. Four waves of work targeted a bottleneck that real hardware later proved was not the bottleneck. The work was not wasted, but the ranking was wrong until something other than intuition produced it.
Derive, do not store. Every figure computed from its history instead of kept alongside it is a place where two numbers can never disagree.
Constraints are more useful than preferences. Committing to a modest phone as the target rejected designs early that would have been quietly slow, and committing to offline-first settled a dozen architectural arguments before they started.
Decide what you will not claim, and write it down. Being explicit about the limits of the product's security — internally, next to the work itself — is what makes it possible to describe it publicly without exaggerating.
Result
A shipped app on three platforms, in 23 languages, with its limits stated as clearly as its features.
Eleven areas of everyday life are built and in daily use. The app runs on Android, iOS and the web, works entirely offline, and syncs when it can.
The parts that are not finished are listed as not finished. Reading text from scanned documents is designed and not built. Home-screen widgets are catalogued and not started. The assistant understands the most common entries without a connection and is still learning the rest.
Saying so is part of the result. A product that is honest about its edges is easier to trust about everything else.
What comes next
What is unfinished is not hidden. Every unbuilt item is listed with its real status — designed, in progress, or planned — beside what has already come off the list, because a roadmap that only ever grows says nothing about whether the plan is real. It is kept in one place rather than repeated, so there is a single version of it to trust.
See the roadmapSee the modules it produced.
Eleven areas of everyday life, each built for what it actually holds — and each with its own page.
- Use it nowOpen the web app
- Coming soonGoogle Play
- Coming soonApp Store