Built a Posture Detection App: One year, two very different builds, and what actually changed
Last year I spent several weekends building a posture detection app. This year I rebuilt it, better and cross-platform, in an afternoon. Same problem. Very different world.
The First Build
My first job out of school, I was a software engineer building gesture-based apps using Kinect, Google Glass and Leap motion ( this specifically tracks your hand motion). I knew those SDKs well, so when I wanted to build something that could flag posture issues in real time for those of us working long hours at a desk, Kinect felt like the obvious starting point.
The idea was simple enough: capture live skeletal data, run posture heuristics locally, normalize everything into a score, and pass that to an LLM to return something actually useful: A plain-English summary on what was wrong and what to fix.
Getting there took much longer than I expected.
Kinect has this quirk where the sensor reports as alive but returns no tracked skeleton. Lighting, positioning, distance, tracking mode. Each one a variable. I used AI to help me debug throughout, and some of it was useful. But I also remember asking it to update the code to call a function, it would say “good catch, let me fix that,” and then not fix it. I’d have to catch it myself, go back, try again. That loop got old fast.
I eventually had a working Windows app. But the part I actually wanted to build next, swapping Kinect for the laptop webcam, kept getting deferred. Camera SDKs weren’t something I had worked with before. And the Kinect was never going to scale anyway. It gave me coolness points. That’s about it.
The Second Build
This year I came back to the same idea with Claude Code.
The target was more ambitious: cross-platform, webcam-based, five posture metrics tracked live with a skeleton overlay drawn directly on your body, a system tray icon that shifts color as your posture deteriorates.
A few hours later, it existed.
PostureGuard tracks 33 body landmarks at 30fps. Posture is computed from angles, how far your ear-to-shoulder line deviates from vertical, for example. Five metrics feed a live composite score. The UI tells you exactly what’s off, in plain language, in real time.
The engineering underneath wasn’t trivial. MediaPipe had dropped its entire documented API between versions. macOS camera access has threading restrictions that fail silently, no error, no camera light, just a black frame. The app kept defaulting to my iPhone over the built-in webcam because macOS treats it as a valid camera device.
I kept the scope tight when it started pulling in things I hadn’t asked for. I caught where the experience broke( even when it was not obvious)-whether it was bugs in the code, or the user experience itself, and fed that back clearly. I pushed on UX affordances until it felt intuitive, so it worked (and failed) in ways that are easy for the user to understand. That’s a different kind of contribution than building something from scratch for weekends. But it is still critical to what the experience ends up being.
What changed. What didn’t.
How we build has shifted exponentially, even from just last year. That’s exciting. It’s also unsettling. But it’s here, and the only real option is to understand it well enough to help shape it.
A few things stand out from building both of these:
Judgment and taste matter more than ever: When you can build everything, what you choose to build becomes the whole game. Product sense, knowing what’s worth making and what the experience should feel like, that’s not something the tool gives you. It’s what you bring to it.
Working well with AI is its own skill. Context is everything. Giving it enough to understand what you’re actually trying to do, while keeping it scoped so it doesn’t go solve problems you didn’t ask for, is active work. So is knowing when to trust the output and when to push back. The need to verify, to evaluate, to catch the gaps yourself, that’s not going away just yet.
Building something is not the same as building something that creates value:
We now have broad access to the first. But this is where I’d push back on the narrative that the hard part is now solved. The ability to ship has genuinely been democratized. But product-market fit, user empathy, knowing what problem is actually worth solving and what the right form of the solution is, none of that has been automated. If anything, as more things become buildable, the quality of the underlying thinking matters more. Anyone can generate features/products. Fewer people can generate the right things at the right time.
The gap between last year and this year isn’t incremental. It’s a different world entirely. The question worth sitting with is what the human-in-the-loop is uniquely contributing when the building gets easier. My answer: Judgment. Taste. Context on needs and human behavior. Product sense. Knowing what to build, who it’s for, and whether it’s working.
Those skills aren’t diminished by better tools. They’re just more exposed.