Future Proof Tech Briefing · September 2026
What I Threw Away
Three weeks after “The Target Audience Is Me”: part of the app I wrote about no longer exists. That is not a mishap — it is the actual news.
Geri, two generations. Soldered on the left, bought on the right. The radio protocol has stayed the same.
On September 13, I deleted the Yazio integration from IDUN. For good. Months of work, a clean import, a running cron job — and then a single commit that removed all of it from the project. In its place is a nutrition module of my own: barcode scanning, a nutrition database available offline, an import of my own history. Four days of work.
It wasn’t the only thing. Around 95 commits and 9,300 lines of Swift in three weeks, and a substantial share of that replaced something that had already been working.
Well tested and still wrong
In the last installment, I wrote that the tools lower the cost of implementation, not the demands on judgment. Three weeks later I have the proof, and it cuts against me.
The sensors on my wrists measure how much movement velocity drops off within a set. For squats or bench presses, that works cleanly. For flys and lateral raises, it doesn’t. I didn’t notice it in the code but in the gym, because the numbers didn’t match what I felt. Fifteen recorded sets later, it was clear: in rotational movements, wrist velocity is not a usable measure of load. There, the model was simply wrong.
It wasn’t in the tests. Tests check whether the code does what I wanted. They don’t check whether I wanted the right thing.
The new analysis based on angular velocity is better than anything I could have planned in August. Not because I got smarter, but because the discarded version delivered the data that made the error visible.
The decision that only pays off later
Geri and Freki, the two sensors from the last installment, were hand-soldered. At the end of August, I replaced them with off-the-shelf hardware. On paper, that is the more expensive option.
On paper. Add in the hours that soldering, testing, and reworking cost, and the comparison flips. And the finished modules bring things I didn’t even need when I bought them: a display, audio output, a microphone. The display has since become a rep counter with a tempo band on my wrist. The audio output became a metronome for the set. Neither was a requirement at purchase — just an open door.
That was exactly the strategic decision: not the cheapest solution to today’s problem, but the one that allows more tomorrow. The radio protocol, by the way, stayed unchanged. That is why the app survived a complete hardware generation change without being rebuilt.
What goes to the test next
The second measurement axis comes from the iPad’s camera. As of this week, it no longer captures a flat silhouette but seventeen joint points in space, scaled by my body height from the profile. From that, each set yields the range of motion per joint, the deviation between the left and right side, and the path the wrist traces over the set. No image leaves the device; only numbers go into the analysis.
That gives me two independent measurements of the same rep. The wrist sensors deliver the load, the camera delivers the execution. Only together do they say whether a set was heavy or just sloppy.
To be honest: as of today, this is theory. I have built and tested the 3D analysis, but not yet held it up against reality in a single real workout. That happens over the next sessions — and after everything in this text, the odds are high that I’ll delete something again afterward.
What this means for IT
On a small scale, what I am doing here is nothing other than application modernization. Old idea out, new one in, and the new one gets better because of what the old one taught. The difference from everyday enterprise life is not the technology but the permission.
In enterprise IT, being wrong is the most expensive event there is. Not because the correction is laborious, but because it is visible: a written-off investment, an explanation to the steering committee, someone who owned the decision. So nothing gets discarded; it gets extended, encapsulated, and dragged along. That is exactly where the DigitalWasteland grows from. Not from bad decisions, but from good ones that nobody was allowed to reverse when the situation changed.
So there are three things I would take away from these three weeks.
Cutting away the old is not failure. A component that gets replaced by a better one was not a bad investment. It was the precondition for recognizing the better one at all.
A proof of concept is an instrument of discovery, not an acceptance procedure. Its value lies not in confirming a decision that was made long ago, but in finding out what really matters strategically. Fifteen sets of my own clarified more than any upfront analysis.
Some investments only pay off later, and that is fine. Clean interfaces, decoupled layers, and portable formats cost more today and only pay off at the moment something has to be swapped out. My unchanged radio protocol turned a complete hardware change into a side issue. At a larger scale, that is exactly what swappability means — and it is the real return on modernization.
The tools everyone is talking about lower the cost of building. Anyone who leaves the cost of discarding where it is has only bought the ability to grow their wasteland faster.
The flip side
The last installment said that without a fixed scope, nothing stops on its own. Three weeks later, I can say which point really bites, and it is not the one I expected. The scope is holding, because every replaced module is also one that no longer needs maintaining. What has grown is the review work. Building has become cheap. Judging has not.
And the repo?
Still private. A substantial part of the code I would have published in August no longer exists — and publishing is irreversible, which this project expressly is not.
What there is instead is the smaller path suggested in the comments on the last issue: I am looking for a handful of contributors I know personally, to collaborate or to use it as the basis for an app of their own. One LinkedIn comment pointed out that, unlike the RAMmageddon installments, this issue is interesting for private users too. That is exactly the point. The code doesn’t have to be public to be passed on.
Last time I asked which tool you would build for yourself if effort no longer mattered. The best answer came from the LinkedIn comments, and it wasn’t hypothetical: one follower had built their own step-counting app rather than keep paying a subscription for someone to count their steps and analyze their heart data.
Today, the less comfortable follow-up question: when did you last delete something that worked?
Jens Klasen writes in the Future Proof Tech Briefing about the upheaval in enterprise IT. You can find all previous installments in my newsletter and at klasen.ai.