Building a client app for a planning practice: what breaks first

The brief was two paragraphs long and sounded easy: a small advisory practice wanted a phone app where clients could see their upcoming meetings, upload a few documents and read the notes from their last review. Before quoting, I looked at how a firm offering Financial Planning presents that service on its own site, because the app has to match what clients already expect from the first conversation. Then I did what I always do with a brief like this: I wrote down everything that would break first.

This piece is that list, cleaned up. It is about the app, not about money. Nothing here is financial guidance, and the app you build should never pretend to give any either.

Contains affiliate links.

The problem: clients who open the app twice a year

Most apps I work on are opened daily. This kind is opened rarely, often right before a meeting or right after a letter arrives that a client doesn't understand. That changes almost every technical decision.

A rarely opened app meets the worst possible conditions. The session token has expired. The cached data is months old. The OS has updated twice since the last launch and quietly revoked a permission. The client has a new phone and restored from a backup that did or did not carry the secure storage over. And the person holding the phone is often slightly anxious, because they are opening it for a reason.

So the first rule I wrote in the spec was simple: every screen has to behave sensibly on a cold start after six months of silence. If you only test the app the way developers use it (opened fifty times a day, always logged in, always on office wifi) you will ship something that fails for every real client.

The constraints you can't design around

Some constraints come from the practice, not from you, and it pays to collect them before you sketch a single screen.

Compliance owns some decisions. An advisory firm usually has someone responsible for what may be shown to clients, how messages are kept and what counts as advice. Ask who that is in the first meeting. Do not guess what is allowed; ask them, in writing, and keep their answers in the project folder.

The app is not the system of record. The practice already has software for client files, meetings and documents. Your app is a window onto some of that, not a second copy. Treat the backend as the source of truth and your local storage as a cache you are willing to throw away.

Older clients, older phones. A practice like this tends to have clients across a wide age range, and some of them keep phones for a long time. Pick your minimum OS version with the practice, not by habit, and test on the oldest device you agree to support.

Nothing in the app should read as a recommendation. That sounds like a content problem, but it shapes the interface too. A push notification that says "Time to rebalance" is a very different thing from "Your review meeting is on Thursday." Keep the app's own words factual and administrative, and route anything that sounds like guidance back to a human at the firm.

The decisions, in the order I'd make them

Here is the build order I'd use, written as the steps I put in the estimate. It front-loads the parts that hurt most when they go wrong.

1. Authentication and the cold start. Design login for the client who forgot they had the app. Biometric sign-in is convenient, but plan the fallback for when the biometric data on the device has changed or the secure storage did not survive a phone migration. The fallback path should be calm, clear and short.
2. Session expiry that explains itself. When a token expires mid-task, say so in plain words and bring the user back to exactly where they were after signing in again. Losing a half-written message to an expired session is the kind of thing clients remember.
3. Read-only views of meetings and notes. Show what the practice chooses to share, clearly dated. Label every piece of data with when it was last updated, because a cached screen from three months ago can look current.
4. Document upload with a receipt. Clients will photograph letters on a kitchen table in bad light. Let them retake, crop and confirm, then show a clear "received" state only after the server has the file. A spinner that ends in silence is worse than an error.
5. Messaging, last. Secure messaging sounds simple and is not. It touches record keeping, notifications and what counts as advice. Build it after everything else is stable, and agree with the firm on response expectations so the app never implies an instant answer.

Each step gets its own test pass before the next starts. That costs a little time at the start and saves a lot at the end.

What breaks first, and how to see it coming

This is the list I keep on a sticky note next to the monitor for this kind of project.

• The basement problem. Clients upload documents from wherever they are, including places with one bar of signal. Uploads must survive a dropped connection: queue them, retry quietly, and keep the user informed without nagging.
• The flat battery. A large upload started at five percent battery will fail. Don't start big transfers when the OS says power is low unless the user asks you to.
• The restored phone. Secure storage behaves differently after a restore than after a fresh install. Test both. Then test a restore onto a different model.
• Time zones. A client traveling sees a meeting time in the wrong zone and turns up an hour late on a video call. Store times in UTC, display them in the device zone, and show the zone name next to any meeting time.
• Screenshots. Decide with the practice whether sensitive screens may appear in the app switcher preview. Hiding them is easy; the decision is not yours to make alone.
• Notification wording. A lock screen is public. "New document from your advisor" is fine. Anything with figures or names in it probably isn't.

Here's the small piece of upload logic I reuse, simplified. It is not clever; it just refuses to forget a file.

fun enqueueUpload(file: LocalDoc) {
    val work = OneTimeWorkRequestBuilder<UploadWorker>()
        .setConstraints(
            Constraints.Builder()
                .setRequiredNetworkType(NetworkType.CONNECTED)
                .setRequiresBatteryNotLow(true)
                .build()
        )
        .setInputData(workDataOf("docId" to file.id))
        .build()
    WorkManager.getInstance(context).enqueue(work)
}

The worker marks the document as received only when the server confirms it. Until then the screen says "Waiting to send", which is honest and, in my experience, much less alarming to people than a progress bar that freezes.

After it ships: keeping a quiet app healthy

An app that clients open twice a year needs more monitoring than one they open twice a day, because they will not report problems. They will simply phone the office, and the office will tell you weeks later.

Set up crash reporting with the practice's agreement and make sure no personal data goes into crash logs. Strip document names, client identifiers and message text before anything leaves the device. Then watch three things: failed logins after an OS update, upload retries that never complete, and cold-start crashes on the oldest supported devices.

Plan a check after each major OS release. Install the update on a test phone, open the app after it has been idle for a while, sign in, upload a document, read a note. It takes an afternoon and catches most of the breakage before any client sees it.

Finally, keep the content side honest over time. As the practice adds screens, it is tempting to add a "tips" section or a calculator. Before anything like that goes in, put it in front of the firm's compliance person. General information can be useful; anything that looks personal or specific belongs in a conversation with a qualified professional, and the app should point people there rather than try to stand in for it.

Where I'd start on Monday

I'd open a blank document and write the cold start story from the client's side: new phone, forgotten password, a letter on the table they want to send. If that story works end to end, most of the app is in good shape. Then I'd book thirty minutes with whoever at the practice handles compliance and go through the notification wording and the screenshot question before writing any code.

The rest is ordinary engineering done carefully. Test on old phones, assume no signal, and make every screen say how fresh its data is. Clients of a practice like this are trusting the app with paperwork that matters to them, and the least it can do is never lose a file.

Release notes

• Added: a cold start test after long idle periods, on the oldest supported phone.
• Added: upload queue that survives dropped signal and low battery, with a clear "Waiting to send" state.
• Fixed: meeting times now show the time zone name next to every time.
• Changed: notification text reviewed with the practice so nothing on the lock screen reads as advice.
• Dropped: the "tips" screen, until the firm's compliance person has signed off on it.