A practice going digital, not a demo
Replate is a real clinical nutrition practice for women — PCOS, insulin resistance, thyroid conditions, pregnancy — going digital. It was already a working, one-on-one practice before I touched it; my job was to build the product around it, not invent the need for it. By the middle of this year, most of that build was done. Booking is real. Authentication is real, built natively rather than bolted onto a third-party identity vendor. Vitals tracking works. Plan management works. Five of six build phases were shipped.
I am telling you this up front because the honest version of this story is not "the build failed." The build mostly succeeded. What failed was everything downstream of the code that needed me, specifically, to make a decision — and kept not getting it.
What actually stalled, and what didn't
The clearest example is small on purpose. The marketing side of the launch stalled on a choice between three hook angles for a single social post. Not a strategic decision. Not a hard one. A pick-one-of-three that sat unmade for weeks, because nothing forced it to get made.
The more serious version of the same pattern sat on the operational side. A launch like this carries obligations that live outside the codebase entirely — the data-handling agreements a health product needs before it can responsibly hold real patient information, the operational safety net around a production database that stores real health records. That work does not announce itself as blocking the way a failing test does. There is no red build. There is just a task that sits there, undone, looking exactly as urgent on day one as it does on day ninety, until the day it isn't. I let that category of work sit unprioritized for longer than I am comfortable admitting, given that the data involved was never mine to be careless with — it belonged to real people who trusted the practice with it.
The real root cause
At the time, I was running six simultaneous roles at once — building and directing work across five client engagements plus my own ventures. Five of those six had a paying client attached, and every paying client comes with someone else's deadline, someone else's quarter, someone else's calendar forcing the next step. Replate had neither. It was the sixth role, and it was mine alone to prioritize.
Here is the part I got wrong, stated as precisely as I can state it: it was never that I decided Replate mattered less. I never decided anything about it at all, for months at a stretch, and an unmade decision does not show up anywhere as a risk. It doesn't appear on a tracker. It doesn't get raised in a status update. A venture with no external deadline does not lose a fair contest for my attention against work that has one — it loses by default, silently, without anyone including me ever consciously choosing that outcome. That is a worse failure mode than a bad decision, because a bad decision at least leaves a decision to learn from. This one left nothing but a gap that widened on its own, unattended — the same shape of failure I wrote about in checking a system narrower than its name promises, except here the unchecked thing was my own calendar rather than a piece of software.
Reprioritizing by irreversibility
Once I actually looked at where things stood — properly looked, not the glance-and-move-on I'd been giving it — the fix was not to work harder within the same six-role structure. It was to change what "next" meant. I reordered the backlog by irreversibility rather than by whoever was asking loudest, and the operational work protecting real people's data went to the front of that list, ahead of every visible, demoable feature still sitting in the queue. A feature not shipped this month can ship next month at no real cost. Data handled carelessly, or a compliance gap left open on a live system, does not have that kind of do-over. Once I named that difference explicitly, the ordering stopped being a debate.
I want to be precise about what that rule is, because it is easy to state and easy to get wrong in practice: irreversibility, not urgency-as-perceived-by-whoever-is-loudest. A client asking for a status update feels urgent. It usually is not irreversible. The operational work that protects real people's information — the unglamorous kind, with no demo attached — does not feel urgent on any given Tuesday, because nobody is asking about it. It is exactly the kind of work a "loudest voice first" queue will never surface, because there is no voice.
Where this actually stands
I would rather write this down than ship a quiet relaunch that implies nothing was ever wrong. What changed is not a burst of effort — it's that I now treat "nobody is forcing this" and "this doesn't need doing" as two entirely different statements, instead of letting the absence of a deadline quietly stand in for a decision I never actually made.
What I do now
- I separate "no external deadline" from "no priority" explicitly, in writing, for every venture I run alongside client work — the first is a fact about the calendar, the second is a decision I have to actually make.
- I rank open work by what can't be undone before I rank it by who is asking, especially for anything touching another person's data.
- The operational work that protects someone else's data — not the features, the unglamorous safeguards underneath them — gets scheduled the same way a feature does, with an owner and a date, not left to survive on urgency it will never generate on its own.
- I check the real state of a stalled venture on a fixed cadence, not when something finally makes noise, because the ventures most likely to drift silently are exactly the ones with nobody else's calendar forcing a check-in.
- When I find a gap like this, I say what changed and what is still open, in that order, rather than waiting until everything is resolved to say anything at all.