I'd noticed people consistently complain about not consuming enough drinking water during the day. The topic was a frequent favourite at work, particularly because we bounced from meeting to meeting with few breaks in between. Coffee and tea were excessive replacements.

Folks would bring in their personal bottles, a few with volume markers. They had every good intention of hitting their target. But even the best laid plans tanked. The trouble with those bottles was that most people spent most of their time away from their desk.

None of this had much to do with why I built a hydration tracker. I simply wanted a weekend project and an opportunity to prove that the PRD still mattered - a subject of much debate and anxiety on LinkedIn.

Now, I've built prototypes without a scaffold before, and I know how frustrating those experiences can be. It's for good reason that the latest build processes like Spec-kit and AI-DLC depend on good specifications.

The project (HYL01) was simple enough to scope (or so I thought). It's meant to calculate a sensible daily target from personal bio-data, track water intake during the day, and remind me when I'm behind. Nothing that hasn't been done before. So I wrote a PRD like I would any other.

It's built in React Native. I underestimated the complexity of a hydration calculator. Biomarkers, activity, climate, medical history, health circumstances, and other variable factors all pull on the number in different directions. Additionally, the research behind how they interact with each other is not something I have any real grounding in.

I settled on a formula that's reasonable. I can't call it validated. But it covered planned activity for the day and local weather conditions. Integration with personal tracking devices was left out of scope.

Tech stack

Layer	Technology
Framework	Expo 57 and React Native 0.86 (React 19, TypeScript)
Navigation	React Navigation
Graphics	react-native-svg
State	zustand
Local data	SQLite (expo-sqlite)
Sign-in	Google OAuth (expo-auth-session) with expo-secure-store
Reminders*	expo-notifications
Location	Google Places
Backend	None

What the App Does

HYL01 works out a target that fits you. It also provides multiple ways to record consumption, and makes it fun while doing so.

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. That still needs someone who understands the dynamics better.

The most important thing to come out of this project was confirming that a well-prepared PRD with articulated stories and acceptance criteria drove down development time significantly over my previous "decide while doing" projects.

The PRD is an absolute necessity even if it's just a prototype or proof of concept you're going after. You need some sort of a compass. Skipping it, particularly in complex builds, opens the doors to misalignment and rework.

So, I'll stay clear from the predictions of gurus and pundits claiming the PRD is optional. Or that a prototype is the new PRD. I guess, if you don't know where you are going, any road will take you there. And while I do appreciate an adventure, time is important to me.

My commute to the office was short, but never calm. Every morning, the roads offered the same experience. Horns without reason. Vehicles threading gaps that didn't exist. An ambient aggression that nobody seems to notice anymore, because it's just how things work now.

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 had been experimenting with AI-assisted coding at work, as a product manager. I was curious about the possibilities when building stops being the bottleneck. So when this idea surfaced, developing something to address it felt natural. This wasn't just a side project. It was more of 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 stop to breathe anymore. 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.

I built it with Claude Code with React Native, TypeScript and Expo, with smooth native animations and fully on-device data storage.

What surprised me wasn't the sheer speed of going from concept to working MVP. 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 your breathing, 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. Designed with light and muted shades, chosen from colour psychology, it's focused on an assuring calm without the distraction.

While the MVP provides the elementary layers, the project is being extended to voice-enabled features, to remove dependency on visual cues. Haptics were already introduced as state change evidence but it relies on human awareness of exercise stage.

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.

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 as much as I was thinking prediction modelling in general.

At the time I was exploring conditional probabilities like Markov's chain and logistic regression at work. So the football conversation seemed like a worthy enough excuse to try something.

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 ball 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. 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.

Tech stack

Layer	Technology
Language	Python 3 (backend and model), JavaScript (web frontend)
Rating engine	World Football Elo (custom, src/elo.py)
Match model	Elo gap → expected goals → Poisson scoreline model (src/simulate.py)
Simulation	Monte Carlo knockout-bracket simulation (10,000+ runs) with extra time and penalties, using numpy 1.26
Data handling	pandas 2.2
Web app	Custom single-page “Match Outlook” app in vanilla HTML, CSS and JS, with inline SVG graphics. There is no frontend framework.
API	FastAPI, served by uvicorn. It also serves the static frontend and handles CSV uploads (python-multipart) and request validation (pydantic).
Data source	Kaggle international results dataset via kagglehub, or a direct results.csv upload
Local storage	Flat CSV files, plus in-memory state in the API. There is no database.

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 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 judgement the tool couldn't supply.

I think this is exactly where product management is heading. AI will amplify PMs, but only as far as the product sense they've developed already extends. It won't hand anyone the judgement 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.