The work I would most want to be judged on at Cendra is something I never shipped. It is a small feature I built, tested, reproduced a fault in, and then deliberately removed, along with the note I left behind so that nobody would have to rediscover why.
I owned both mobile applications there. A single web codebase wrapped in two native shells, every commit to the ios/ and android/ projects across the repository's history, with a full release chain: push notifications, over-the-air update delivery, and publication through App Store Connect and Google Play.
The problem I was solving
Over-the-air updates let you ship a new web bundle to an installed app without going through review. Useful, and the useful part is the speed. The mechanism as it was configured applied a downloaded bundle on the relaunch after next, which produced a recurring and confusing failure. I would ship a fix, open the app to check it, and see the old build. Then close it, open it again, and see the new one. Multiply that across a small team and a support channel and you get a persistent low-grade uncertainty about whether anything you shipped has arrived.
So I changed it to apply on the next cold start. That is straightforwardly better and I would make the same change again.
It also opened a narrow window. Applying a bundle at cold start means there is a brief moment during boot where the app is swapping what it is about to render. Small, but visible if you are looking for it, and the sort of thing that reads as a broken app rather than as a fast update.
The update library offered a splash-screen feature for exactly this. Hold the launch screen until the new bundle is ready, and the window disappears. One configuration flag. This is the point in the story where the feature ships.
What happened on a real device
I enabled it, built it, and put it on a physical handset rather than a simulator, because that is my rule for anything touching launch behaviour.
The splash screen did cover the boot window. It also appeared on every background-to-foreground switch. Every time you switched away to check a message and came back, the app flashed its launch screen at you.
That is a much worse experience than the thing it was fixing, and it is worse in a way that compounds. The boot gap is paid once per cold start, by a user who is already waiting for an app to open and has some tolerance for it. A splash flash on resume is paid every single time anyone switches back into the app, by users who are mid-task and have none.
The obvious move at that point is to try other flag combinations until the symptom goes away. I have done that before. It produces changes I cannot explain, and those are the changes that come back. So instead I opened the plugin's own source and read the lifecycle handling.
The explanation was there. The configuration I had enabled mapped onto a mode in which the handler fires unconditionally on the relevant lifecycle event, rather than only on a cold launch. I had not misconfigured anything. That is simply what the mode does. No combination of settings would give me the cold-boot cover without the resume flash, because the library did not draw a distinction there.
So I reverted it. The narrow benefit was not worth degrading every app switch.
The part I would defend
Reverting was easy. The decision I think was the right one was what I did afterwards.
A removed feature leaves no trace. Six months later, or next week with somebody else on the team, the boot window is still there, the library still advertises a splash option, and the fix looks obvious. Somebody enables the flag, ships it, and the resume flash comes back as a mysterious regression with no connection to the change that caused it. That bug costs more the second time, because now nobody knows it is old.
So I wrote the reasoning into the configuration file itself, at the flag I had just turned off, including the source file in the dependency and the approximate line where the behaviour is defined. I did not put it in a ticket, a commit message, or a design document. I put it in the file where the next person will be standing when they have the idea.
The test for that kind of note is whether the person who is about to make the mistake will encounter it without going looking for it, and whether it is well written matters much less. A commit message fails that test. A comment three lines from the flag passes it.
Why this is the story I tell
I could describe larger things from that role. I rebuilt a web application and became its principal author, ran a release process across four repositories, and cut roughly nineteen thousand unnecessary push notifications a day out of the notification system. That figure was measured in production log telemetry over a ten-minute observation window against the prior baseline and scaled to a daily rate, a qualification I would rather state than have inferred.
But this one contains everything I believe about building software, in a small enough space to check.
The cost of a feature is paid by every session, while the benefit often goes to a fraction of them. The boot window affected cold starts. The splash flash affected every resume. Getting that ratio the wrong way round is one of the most common ways a well-intentioned improvement makes a product worse, and it is invisible if you only test the scenario the feature was designed for.
Real hardware matters more than a simulator here. The regression was a lifecycle behaviour, and simulators are honest about layout and unreliable about lifecycle. This is why I treat "verified in production" as a completion criterion rather than an intention. A change is done when I have watched it behave correctly in production logs, in the database, or on a real device, and a passing test suite does not count on its own. I adopted that rule after being wrong often enough to stop trusting a passing build.
Reading the dependency's source beat guessing. Reading produced an explanation and therefore a decision I can still defend. Shuffling flags until the symptom disappeared would have taken about as long and produced a decision I could not.
Deciding not to ship is a deliverable. It has no diff, so nothing in the tooling counts it, and it is the reason I would rather be asked what I chose not to build than what I built. The features I removed describe my judgement better than the ones I kept, because keeping something only requires that it works.
There is a second habit underneath all of this. None of it survives unless it is written down. That role produced 255 design specifications, 207 implementation plans and 17 production runbooks, and the runbooks in particular exist because release ordering across four repositories lived in one person's head, a single point of failure disguised as competence. The note next to a disabled flag is the smallest possible version of the same idea.
More on that role, including what I owned and what I did not: Cendra.