TIMEKEEPING APP / RELIABILITY
Why the finish line kept moving.
The app already worked. Making it something I could safely own meant repeatedly asking harder questions about updates, corrections, backups, and recovery.
The app was working. The system wasn't finished.
This timekeeping app began with a practical goal: record work reliably, even when the connection was unreliable. That part became real. It was tried in the actual workflow, and an in-place update preserved the information already on the device.
That could have been the ending. Instead, it became the first of several finish lines.
A working feature tells you the happy path exists. Ownership begins when you ask what happens after a mistake, a failed update, or a lost system.
Every answer exposed the next question.
Once recording time was dependable, the next question was correction. If someone made a mistake, an administrator needed a way to fix it without quietly rewriting history. That led to a correction process with previews, acknowledgements, and a visible trail.
Fresh review then found subtler cases: an old confirmation could survive after the underlying information changed, or a correction could appear ready when it no longer matched what had been reviewed. The feature worked, but its proof could go stale.
Fixing that did not end the sprint either. It simply revealed the next ownership question: if the whole service disappeared, could I recover it without depending on the same system that had just failed?
A backup is not the same as recovery.
The first recovery plan assumed more outside infrastructure than this project needed. So the design changed: make a coherent backup, encrypt it under owner control, keep a separate copy, verify what was written, and restore it into a fresh isolated environment.
The last step is the important one. A file can exist, have the expected size, and still be useless when it matters. Only a clean restore rehearsal can show that the data, structure, access rules, and application expectations still fit together.
A backup says, “I saved something.” A restore rehearsal says, “I can get the system back.”
Green checks still left trust questions.
The backup and restore tools passed their automated checks and completed a disposable rehearsal. A separate review still found ways the evidence could be more convincing than the reality.
01 / A failed final step could leave a backup looking complete.
The safe result was not merely to report the failure. The incomplete result also had to be impossible to mistake for a usable backup.
02 / A system could identify itself instead of being independently identified.
If the source supplies its own identity, the check may only prove that the same claim appeared twice. Recovery needs an authority outside the thing being checked.
03 / “No error” could be mistaken for proof of a second copy.
Starting a transfer without seeing a failure is not the same as confirming that a complete, readable copy arrived.
04 / “Verified” could appear before every safety check was complete.
The wording had to follow the evidence. Authentication, isolation, and restore checks could not be treated as details after the success message.
The useful decision was to stop.
Some findings could be fixed directly. Two could not: the design had not yet defined an independent source of truth for the production system's identity, or a durable record connecting each complete backup to a successful restore.
Writing more code would have hidden that gap behind an implementation choice. The better result was to stop the remediation, preserve the valid work, and send those decisions back to the design stage.
That is the rework I find most interesting. It is not polishing the same feature again and again. It is allowing evidence to move the plan backward when the plan has skipped a trust decision.
Why this still feels like progress.
The earlier evidence has not vanished. The app still records time, the update still preserved existing information, and the correction work still solved real problems. The open questions belong to a newer operational layer.
That separation matters. It prevents one unfinished piece from erasing everything that has been proved, while preventing earlier success from lending false confidence to something that has not.
Ownership is not having the source code. It is knowing how to change, verify, recover, and stop safely.
The ending is still open.
The recovery design now needs clearer answers about trusted identity and restore history. The tooling then needs another independent review and a fresh operational rehearsal.
So this is not a victory lap. It is a note from the middle of the work—after several things became real, and just before the next definition of “done.”
Want the nerdy details?
The app, correction workflow, and recovery tooling were evaluated as separate layers. Evidence from one was not used to declare another complete.
The recovery work used automated checks, disposable local rehearsals, and a separate AI review. The review identified both implementation defects and design questions that code alone could not settle.
The current recovery candidate is not being presented as operationally ready. Contract clarification, remediation, independent re-review, and a real rehearsal remain open.
Identifying details, private operational data, service names, device names, and infrastructure providers have been left out or generalized.