[CantoGo](./cantogo.html) taught me that code can help my family. Tick-Tock Clock taught
me something harder: a tool your family uses every day is never really “done” — and
that’s not a failure of planning. It’s how real needs work.
When my sister first asked for a clock, I treated it like a normal project: gather the
requirements, build to spec, ship, close the ticket. But her needs didn’t arrive in one
message. They surfaced one by one, while she actually used the thing — “can the timer
behave differently during exam week?”, “this button feels wrong at 7 a.m.”, “could it
also do this?” At first I resisted. Every new request felt like a hole in a plan I had
already finished. I wanted the requirements to hold still so I could declare the project
complete.
What I understand now is that those changes weren’t scope creep. They were the
requirements maturing in front of me. A person can’t fully specify what they need from a
daily companion until they’ve lived with a version of it. Each “actually, can it also…”
was not an interruption of the work — it was the real work. My sister wasn’t moving the
goalposts; she was showing me where the goalposts actually were.
So I stopped treating change as an enemy of completion. I started to expect it, plan
around it, and even welcome it. A request that arrives after shipping is not a bug in
the process; it’s feedback from reality. The shift was simple and difficult at the same
time: from “please stop changing things” to “tell me what’s missing.”
Once I made that turn, the project stopped feeling like a backlog I was failing to
close, and started feeling like a conversation I was lucky to be part of.
This is the lesson I’m carrying forward: good family tools are not designed once and
delivered. They grow through use, revision, and a willingness to be wrong early.
Embracing requirement change doesn’t mean having no plan — it means holding the plan
loosely enough that the person you’re building for can actually reach it.
