Personal Projects

A running log of experiments, ideas, and apps built with AI-assisted coding to test the boundaries of what's possible.

A Weekend Developing a Hydration App

A weekend project on tracking water intake, and the domain knowledge no app can substitute for

I'd noticed people consistently complain about not consuming enough drinking water during the day. The topic was a frequent favourite at work. Folks would be sure to bring in their personal bottles and plant them on their desks. Some even sported bottles with tracking indicators. The trouble with that sophisticated piece of tech was that most people spent a lot of their time away from their desks.

None of that had much to do with why I built this. I just wanted a weekend project, the way some people spend a weekend gardening or fixing a bike. No brief, no user research, no ROI conversation with myself. Just an idea and a couple of days to see how far I could take it.

Hydration app screens: Daily Tracker, Dashboard, and Reminders

Hydration seemed like a reasonable place to start. It's simple enough to scope in a weekend, and personal enough that I'd actually use it. Track water intake, calculate a sensible daily target from basic bio-data, remind me when I'm behind. Nothing that hasn't been done before. That wasn't the point.

I built it with Expo and React Native, targeting Android first, with the same stack able to stretch to web and iOS later. Local storage instead of a backend. Google sign-in without a native module. On-device reminders and a small gamified layer.

What I hadn't fully appreciated before going in was how quickly a "simple" hydration calculation stops being simple. Biomarkers, activity, climate, and a many other variable factors all pull on the number in different directions, and the research behind how they interact is not something I have any real grounding in. I built a formula that's reasonable. I can't call it validated. But, it covered planned activity and local weather conditions. Although, integration with personal tracking devices would have been a better way to go.

That's really the lesson of this one. I could build the app. The interface, the state management, the reminders, the mechanics, all of it came together in a weekend. What I couldn't build my way past was domain knowledge I simply don't have. That still needs someone who actually understands the physiology, and right now, that isn't me.

That said, I might decide, if time permits to take it a further. For now, I'm just happy working with Claude Code and Codex to build experience before taking on something serious.

Building a World Cup Predictor

A weekend experiment in Elo ratings and Poisson distributions

Last week I sat in on a conversation between friends, all neck deep in predictions, numerical tables, and gut feelings about the FIFA 2026 World Cup. I wasn't really following the match talk. I was thinking about a Clinical Inbox prediction model I'd been sketching at work for a while — one I'd shelved because I couldn't justify an ROI consistent with the effort it needed.

Shelving it professionally didn't stop me from wanting to build something, though. And the football conversation seemed like a worthy enough excuse.

I want to be clear about the intent here. This wasn't an attempt to compete with the serious forecasters, or with Paul the octopus, for that matter. Real prediction models are a different order of complexity entirely — big data, machine learning, supercomputers, statistical modelling weighing thousands of variables: injuries, form, tactics, fatigue accumulated over a tournament. That's a different game.

Mine was a small subset of that. I pulled historical international football results off Kaggle, then layered Elo ratings and Poisson distributions on top — exactly the kind of mathematics I wish I'd paid more attention to in school. In less than an hour, Claude Code and I had a working model.

Match Outlook app screen

It doesn't weigh fitness, form streaks, or any of the finer variables the advanced models factor in. It works to the extent that my own knowledge permits, and not further. That turned out to be the real lesson. I got some experience out of the exercise, sure, but the sharper takeaway was seeing the exact boundary of my own competence.

I'm not a data scientist. I'm not a mathematician. If I were good at either, I'd have used the same hour to build something closer to what the people who do this professionally build — maybe even rivaling it. I'd have known which variables mattered, what to tweak, what to clean up, what algorithm actually fit the problem. That's domain knowledge, and no amount of AI substitutes for it. AI didn't close that gap for me. If anything, it made the gap easier to see. Every decision in the build still needed a level of judgment the tool couldn't supply.

I think this is exactly where product management is heading. AI will amplify PMs, aspiring ones included, but only as far as their product sense already extends. It won't hand anyone the judgment or expertise they don't already have. That will become obvious as roles start to blur. Quality "AI-powered" work is really just a reflection of how much sense the person behind it brings to the table — and I suspect, at least in the near term, we're quietly building an age of pseudo-competence, where we assume the tool covers for whatever we're missing.

Building Hush: A Break From the Noise

What a chaotic commute in Pune taught me about building a wellness app that does less, not more

I used to work in Pune, India. It's a tier 2 city, which means it carries all the chaos of a metropolis without quite enough infrastructure to absorb it. My commute to the office was short, but never calm.

Every morning, the roads offered the same education. Horns without reason. Vehicles threading gaps that didn't exist. A kind of ambient aggression that nobody seems to notice anymore, because it's just how things work. It struck me at some point that nobody stops. Not physically, not mentally. There's a pressure baked into ordinary life that most people have simply accepted as normal.

I didn't want to accept it.

I'd been experimenting with AI in my work as a product manager, curious about what becomes possible when you remove friction from thinking. So when this idea surfaced, building something to address it felt natural. This wasn't just a side project. It was more a question I wanted to answer: could I build something real, by myself, that might actually help?

Hush started from a simple premise. People are overwhelmed. They don't breathe. And most wellness apps make that problem worse. They are noisy, gamified, full of nudges designed to keep you inside them longer. I wanted the opposite. A space defined by what it leaves out.

Why Hush

I built it with Claude Code.

What surprised me about building with Claude Code wasn't the speed, though that was real. It was how the collaboration changed the nature of building itself. I managed the intention, the philosophy, the feeling I wanted the app to convey, while Claude helped me execute it. The result is eight evidence-based breathing techniques, canvas animations timed to breath, and a recommender that matches technique to emotional state. All of it designed to disappear once you're in a session.

The visual language followed the same logic - Minimal and Spacious. If the interface is doing its job, you stop noticing it.

I don't think one app changes a culture. But I think individuals can choose, moment by moment, to slow down. Hush is my attempt to make that choice a little easier. To offer a pause in a world that's forgotten how to take one.