Tides is a companion app for people on peritoneal dialysis — a kidney treatment that patients do at home, multiple times a day. It’s one of the most technically demanding and emotionally significant things I’ve built.
What peritoneal dialysis is
When kidneys fail, the body can no longer filter waste products from the blood. Dialysis does this job artificially. There are two main types: haemodialysis, done in a hospital or clinic using a machine, and peritoneal dialysis (PD), done at home using the peritoneal membrane — the lining of the abdomen — as a natural filter.
In PD, dialysis fluid is infused into the abdomen through a catheter, left to dwell for a set period while it absorbs waste products from the blood, then drained. The process is called an exchange. Patients typically do four to six exchanges a day, every day, for as long as their kidneys remain in failure — which for many people is years.
This is a life-sustaining treatment. Not doing it — or doing it inconsistently — has serious consequences. The people using Tides are, in a very real sense, depending on it.
Why patients need a tracking tool
Every PD exchange involves variables that matter clinically: how much fluid went in, how much came out, how long the dwell lasted, the appearance of the drained fluid, and whether there were any symptoms. Patients are expected to log this information and share it with their renal care team at each clinic appointment.
In practice, many patients use paper diaries, which are easy to lose, hard to review, and almost impossible to share digitally. Others rely on memory, which is unreliable when you’re doing the same thing four times a day while managing fatigue, dietary restrictions, and everything else that comes with kidney disease.
Tides gives patients a clean, structured way to log each exchange as it happens, review their history, and track patterns over time. The data lives with them. It’s legible. It can be shared.
The emotional weight of building for this use case
I thought carefully about who uses this app and when. Someone doing a dialysis exchange at 3am is often tired and uncomfortable. They don’t want to wrestle with a complicated interface. They don’t want to read instructions or find settings buried in a menu. They want to log what just happened and go back to bed.
That constraint — design for someone who is unwell, tired, and doing something they’ve already done hundreds of times — is clarifying in a way that most design briefs aren’t. Every tap that isn’t necessary is a tap too many. Every label that isn’t clear enough is a failure. The emotional weight of the use case becomes a forcing function for genuinely good UX.
Technical challenges
Data accuracy was the central technical concern. When you’re recording medical data, the difference between 1,800ml and 1,900ml of drain output isn’t a rounding error — it’s clinically meaningful. Input validation and sensible defaults had to be handled carefully, and the app needed to surface anomalies rather than silently accept them.
I also had to think carefully about offline behaviour. PD happens at home, sometimes in areas with poor connectivity. The app cannot depend on a network connection to function. All logging works offline, with synchronisation handled gracefully when connectivity returns.
Building Tides changed how I think about software. It’s not the cleverest thing I’ve built, or the most technically complex. But it’s the most carefully built — and I’m proud of it for exactly that reason.
Leave a Reply