Ready, Not Perfect: Lessons in Building Systems, Managing Expectations, and Letting Go
By Kelvin Njenga | Digital Transformation Officer
June last year. That’s when this journey started — though if you’d asked me back then how long it would take, I would’ve guessed wrong in every direction.
We set out to build a volunteer and membership management system. Simple enough on paper. In practice, it meant leading a team through requirements gathering, mapping out exactly how the system should work, and trying to anticipate the needs of volunteers we hadn’t even spoken to yet.
For a long stretch, it didn’t feel like a project with an end date. It felt like a project that simply existed, indefinitely, somewhere just out of reach.
The hesitation nobody saw
Here’s the part I don’t say out loud very often: I almost didn’t roll it out.
I’m a perfectionist, and that’s not always a compliment. I wanted every workflow correct, every field validated, every volunteer’s first experience flawless before a single person logged in. In my head, “ready” meant “perfect,” and perfect kept moving further away the closer we got.
Looking back, that instinct nearly cost us the entire project. Waiting for perfection doesn’t get you to perfect. It just gets you to never shipping at all.
So I took a leap of faith. We rolled it out anyway, imperfections and all.
The UAT that almost broke me
The first round of user acceptance testing was rough. Not “a few bugs to iron out” rough — issues we hadn’t anticipated, in places we hadn’t thought to look, surfacing in front of the very volunteers we’d built this for.
I’ll be honest: there was a moment I wanted to give up. It felt like proof that I’d been right to be scared in the first place.
But I gave myself something to hold onto instead — the idea that we didn’t have to get it right before launch. We could get it right as people used it. The system didn’t need to be finished. It needed to be learning, alongside us.
Confidence built in rounds, not in one leap
So we kept going. More rounds of UAT. More issues surfaced, but fewer that caught us off guard. And something shifted — each round made the next one feel less like a threat and more like routine.
A few things that became true the more we did this:
- Every UAT round chipped away at the fear, not just the bug list
- Supporting users got noticeably easier each time, not because problems disappeared, but because we’d already seen most of them before
- The system kept improving in plain sight — visibly, with the people using it, not in a separate room before they were allowed to see it
- We’re still building it. It’s still not finished. And that’s no longer the problem it once felt like
The lesson I keep coming back to
We don’t need perfect systems. We need systems that serve the most basic need of the person using them — and the rest can come through improvement, in the open, over time.
That sentence sounds simple to write now. It took a near-breakdown during a UAT session to actually believe it.
A few things I’m carrying forward from this:
- Hesitation is data, not a stop sign. Mine was telling me to care more, not to wait longer.
- Ship the basic need first. Everything beyond that is a future improvement, not a launch requirement.
- Confidence isn’t found before you start. It’s built one round at a time, by actually doing the hard part.
- A good team makes “good enough” feel safe to launch. I had one, and I’m not sure I’d have made it through that first UAT without them.
The system isn’t finished. I’m not sure it ever will be, in the way I once imagined “finished” looking. But it’s serving people now, getting better in front of them instead of in spite of them — and that’s a version of success I didn’t know I needed to learn to accept.