I'm my own worst user

I’m my own worst user. I build apps I use every single day, which means I’m the one who notices every flaw, holds them to a standard no real customer would, and can’t be fooled for a second by my own marketing. It’s the most honest feedback loop I have. It’s also, as it turns out, the hardest part of the whole thing — and not in the way I expected.

This is the thinking underneath everything else I write here. The bugs I only find mid-workout and the rebuilds I talk myself into are the symptoms. This is the cause.

Everything I build starts as something I couldn’t find

I don’t build apps because I want to be an app developer. I build them because the thing I needed didn’t exist in a shape that fit how I think.

That’s most acute in my day job. As a platform engineer, almost every tool you pick up was built around the mental model of the company that made it — their idea of how the problem decomposes. The moment your problem is shaped even slightly differently, you spend your life working around the tool: glue code, workaround hacks, a layer of your own on top to make it behave. Every platform engineer knows the feeling of fighting the thing that was supposed to help. So when it matters enough, I build the version that fits the purpose instead of the version that fits someone else’s roadmap.

My apps come from exactly the same place — necessity, not ambition:

• SteelRep exists because there was no cheap, simple app that just let me follow a program, check my weights and reps, lift, tap to log, and get on with my day — with the progression and deloads handled for me instead of by a spreadsheet.
• LastLift exists for the days I go off-script, or just want to do something completely different and still log it in seconds without the app arguing with me.
• IronWolf comes from a different necessity. I coach, and I know a lot of coaches, and the online-coaching toolchain is genuinely broken. The data lives stranded across separate platforms with no way to join it up, and video feedback at any real client count is a nightmare — a WhatsApp full of clips you import, re-edit, annotate and draw on across two or three tools, then deliver back through a fourth. It eats coaches hours every week, sometimes days. That disconnect is the product.

None of these started as “I want to build an app.” They started as “why does this still suck, and why am I doing it by hand.”

The trap of building for yourself: you stop being a user

Here’s the part that genuinely surprised me. Building for myself is easy — I am the spec. But the moment I build something meant for other people, I have to climb out of the engineer’s head and into the user’s, and that turns out to be much harder than any of the code.

The clearest example is onboarding. I had never appreciated how much it matters, because my instinct as a backend and platform engineer is to skip onboarding entirely — close the tour, dismiss the dialog, and figure it out by poking at it. That’s how engineers use software. But for a normal person, onboarding is not a formality; it’s the entire first impression, the few screens that decide whether they ever come back. The part of the app I would personally never read is the part that determines whether anyone stays.

That’s the recurring tax of being the wrong kind of person to build consumer products: the things I find obvious are the things a user finds opaque, and the things I’d skip are the things that keep them. I can write the engine in my sleep. Learning to build for someone who isn’t me is the actual work.

Cool to build is not the same as useful to use

The other half of that trap is that engineers love to build things, and that love is a liability in a product.

The honest example is the Apple Watch app for SteelRep. In my head it’s a brilliant feature — glance at your wrist, see the next set, tap to log. I can picture exactly how I’d build it, and I’d enjoy every minute. Which is precisely why I don’t trust the urge. Because I have no data that anyone would actually use it. It might be wonderful. It might also be vaporware with a heartbeat — a thing that’s used once on the day it ships and then never again — and from inside my own enthusiasm I genuinely cannot tell which.

So I haven’t built it. Not because it’s hard, but because “I would love to build this” is not evidence that anyone needs it. The discipline I’m slowly learning is to build a little, ship it, watch what actually gets used, and let that tell me what to build next — instead of letting the most fun thing to engineer jump the queue ahead of the most useful thing to have. Restraint isn’t natural to me. It’s the skill I’m most deliberately practising.

Painkillers, vitamins, and why I keep a spine

The hardest version of that restraint isn’t about features. It’s about whole apps — about which ones get to exist.

I recently came close to shelving IronWolf, because building consumer apps like LastLift is simply more fun and more immediately rewarding. Then I made myself look at the actual shape of the assets rather than how much I enjoyed making them, and I had to get one piece of startup folklore straight in my own head: the old split between painkillers (things that solve an acute, must-fix pain) and vitamins (nice-to-haves). I’d been telling myself the fun consumer apps were the painkillers. The market says the opposite.

Fitness apps churn around 9% a month — the steepest of any consumer subscription category, with a brutal January spike-and-collapse where 40–60% of new subscribers are gone by February. Good B2B tools sit nearer 1–2%, with customers who expand rather than evaporate. So however much a consumer tracker scratches a real itch, in market terms it behaves like a vitamin: trend-exposed, high-churn, short-lived. The real painkiller is the unglamorous B2B tool that gives a coach back hours of their week — sticky, valuable, low churn. That’s the thing a business can stand on.

So IronWolf stays as the spine, and the consumer apps become side-quests — not because they’re worse, but because I learned to judge an asset by its shape, not by how good it felt to build. (That decision has more to it than fits here; it’s a post of its own.)

”Done” is allowed

SteelRep is finished. Built for me, and — if I’m honest — barely used by anyone else, almost certainly because I’ve done no marketing to speak of. And that is genuinely fine, because the value of SteelRep was never going to be its revenue. It was the learning: the migration that taught me to strip the backend out, the bug that taught me what tests can’t catch.

It’s also deliberately static. The programs don’t churn every month chasing a content calendar; the maths and the algorithms are solid for a year and will be solid in ten. If nobody uses it, I’ll add the features I personally want, when I want them. If organic growth ever shows up, wonderful. But an app is allowed to be done — to be good and to rest — and not every product has to be a treadmill of updates justifying a subscription. Knowing which of your things get to stop is its own kind of restraint.

The code was always the small part

Here’s the uncomfortable truth holding all of this together: building the app is the small part.

Nobody on the App Store cares how clean my code is, how elegant the engine is, or how many clever features I crammed in. They care whether the core experience is there — and they’ll never find out either way if I don’t put it in front of them. SteelRep is my own evidence for both halves of that: a solid engine and real programs, sitting almost unused, because I poured myself into the building and skipped the marketing. The thing I’m good at was never the thing that decides whether any of it matters.

So if there’s a method here, it’s this. Build from necessity, because the tools that fit how you think rarely exist. Then do the genuinely hard work of becoming the user you’re not. Judge what you build by what gets used, not by how much you enjoyed making it. Let things be done when they’re done. And never confuse shipping the code — the part I find easy — with the part that actually counts.

I’m my own worst user because I can’t lie to myself about any of that. It’s the most useful tool I’ve got. The rest of the work is just learning to act on what it keeps telling me — and you can see where it’s led so far in the things I build.