As a product manager, AI made some of the projects I poured my heart into obsolete. Others, it gave new life to.
This is one of the latter. For the last two to three years, I’ve volunteered with a nonprofit that serves Neighbors who need the dignity of meals, hygiene services, and a path toward stability. What started as a small contribution took on a life of its own, shaping both my future and the future of an organization that trusted me to understand their mission and guide their solutions.
In the first year, we built a demo that worked. It delivered real, measurable results.
But natural growth has driven us toward a more complete solution: scaling it into a SaaS platform for nonprofits. That’s the work that led me to build The Playground, and to start experimenting with AI on my own. Join me as I share my experience.
The challenge
Change brings its own unique problems
We had earned trust with the first version of the product. Now the challenge was how to evolve it, without losing that.
The problem I needed to solve
How do you test interface changes quickly when your users aren’t always around, and your backend is changing at the same time?
That’s the short version. Here’s the longer one.
Our volunteers are transient. They’re spread across Central and South Florida. Their ages range widely, and so does their comfort with technology. Some have spent careers inside enterprise software, some have never used a tablet for anything beyond reading the news.
Most SaaS products are designed for the opposite kind of user. Daily power users. People who can be trained, who sit through onboarding, who get better at the product over time. None of that applies here.
Every event is, for some volunteers, day one all over again.
The existing UX testing tools on the market didn’t fit this reality. Too slow. Too expensive. Too heavy for a volunteer base that can’t be put through hour-long research sessions. So I gave myself four days to build something that did.
The history
Why the original app got us this far
The first version of our app was built on a low-code, cloud-based platform, focused on resource management of services at events. That was the right call for what it needed to be: a fast, workable tool that could get in front of volunteers and start producing outcomes.
The outcomes were real.
Every minute saved means more Neighbors helped. Hygiene is a direct path to stability.
Those numbers are why the demo wasn’t the goal. The demo was the proof. And the proof opened a much harder problem.
The design problem
The new design problem
Every feature we added was, in theory, a win. More functionality. More flexibility. More of what Neighbors had been asking for. But every feature was also a risk to the thing that mattered most: the 95% adoption rate.
New features meant more options, more noise. Capturing more information on showers meant volunteers moved from single taps to actively managing our Neighbors’ time in and out. How do we introduce more without overwhelming volunteers, or worse, stripping the dignity from the moment of service?
This is the trap that kills a lot of second-version products. You inherit the success metrics of the first version, and then you slowly destroy them by giving everyone what they asked for.
What's next
What comes next
This is the first post in a five-part series about that build, and about a bigger experiment it’s leading into.
But that’s for later. For now, the story starts with a tool that needed to exist and didn’t, and four days to build something that would.