Written with the editorial assistance of Claude (Anthropic).
In Part 1, I laid out the trap: every new feature was a risk to the 95% adoption rate we earned with the MVP. Add too much, too fast, in front of a transient volunteer base, and we risk losing the very thing that made the product work.
I had already built eight prototypes around our core user types. Testing the UX and socializing new designs with coordinators and repeat volunteers would give us critical insight into the next version of the app.
But prototypes weren’t the bottleneck.
The reframe
I didn’t have a design problem. I had a design validation problem.
Budget constraints around new software still existed, but the larger issue was that we had no consistent workflow for observing volunteers and collecting behavioral insights early enough to protect adoption.
The real question
How do you validate design changes against real volunteer behavior, quickly, with a transient user base that can’t participate in formal research?
The existing tools didn’t fit. Neither did the budget.
An ad about building websites in 15 minutes kept replaying in my head. I didn’t expect to build a complete solution that quickly, but it pushed me toward a different question:
Was building our own solution actually more feasible and more cost-effective than buying one?
I started pressure-testing ideas with Claude.
The stack
Eight tools, four days, and a working system
I knew I needed tools I already understood if I wanted to move quickly.
That narrowed the field immediately.
I landed on Netlify. I had previously worked with AstroKit, a lightweight framework built on Astro by Shawn Sandy, Chief Technologist at Say Hello Neighbor, designed for rapidly building websites.
I also wanted an analytics layer. Several options came up, but I ultimately chose Microsoft Clarity after both Claude and Shawn recommended it independently. Even while using AI heavily, I still rely on the judgment of subject matter experts before making final decisions.
Claude helped draft the initial timeline, but the plan quickly became more complex than the moment required.
I’ve found that AI models can sometimes get locked into a particular line of thinking. Bringing in another model can completely reframe the problem.
So I took the plan into ChatGPT and worked through simplifying it. ChatGPT agreed that the original timeline was over-engineered.
From there, I moved the PRD into Claude Design, which generated the first webpage concepts.
By that point, I had three core assets: a PRD, generated HTML, and the AstroKit design system.
I brought everything back into Claude and VS Code and refined the experience piece by piece.
The full stack:
- Claude for PRD drafting, refinement, and code generation
- ChatGPT for model triangulation and simplification
- Claude Design for initial webpage concepts
- AstroKit for the design system and framework
- GitHub for version control
- Netlify for hosting and deployment
- Microsoft Clarity for behavioral analytics
- VS Code for refinement and assembly
What it actually cost
| Tool | Cost | Notes |
|---|---|---|
| Claude | $100/mo | Existing subscription already used in our workflow |
| Claude Design | Included | Generated initial webpage concepts |
| ChatGPT | $20/mo | Existing subscription already in use |
| GitHub | Included | Sponsored by Shawn Sandy |
| AstroKit | Free | Open framework built on Astro |
| Netlify | Free | Free tier covered deployment |
| Microsoft Clarity | Free | Free analytics platform |
| VS Code | Free | Editor |
No additional software costs were introduced for this project.
Every tool was already part of the existing workflow.
That’s the part I want nonprofit leaders and PMs to hear clearly: the barrier wasn’t budget. The barrier was realizing a stack like this could support a real project from idea to deployment.
The build
It wasn’t effortless
The push to get Playground live was intense.
I wasn’t writing code directly, but I spent hours reviewing changes, testing localhost development servers, catching ideas I had missed, and removing features that drifted beyond scope.
Even with highly specific artifacts and requirements drafted ahead of time, I still didn’t fully trust Claude inside VS Code to execute the complete MVP cleanly.
My instincts weren’t wrong.
I constantly had to reel Claude’s ambitions back in. The AI often wanted to expand the solution beyond what the moment required. Sometimes the suggestions were genuinely strong. Other times, they introduced unnecessary complexity that would have hurt velocity and adoption.
Still, the process was worth it.
Four days later, Playground was live, well ahead of the timelines both Claude and ChatGPT initially suggested.
It wasn’t effortless. It took multiple 10-hour days of iteration, refinement, and repeatedly simplifying the experience until it felt right.
After taking a short break to reset, I came back on the fourth day to finalize the remaining details.
By then, Playground was ready.
Ready to test every UI planned for the July 2026 release.
The constant question
The constant question remained: did I actually need to build this?
Honestly, if I had a dedicated UX researcher on the team, I could have justified purchasing Maze or one of the other platforms.
But that wasn’t our reality.
While the application had been designed with support from a UI designer, we still needed to validate whether the interfaces and workflows were actually effective for volunteers in real-world use.
I understood some UX research methodologies, and I could interpret the reports and findings coming out of them. But designing and executing effective UX experiments is an entire professional discipline I wasn’t formally trained in.
Most of the platforms were built for dedicated UX researchers and designers, and I knew we would only use a fraction of the functionality they offered.
At the same time, July was approaching quickly. We were preparing for a soft launch of the platform, and I needed validation now.
I needed volunteers to see the interfaces, click through workflows, react naturally, and tell us where friction existed.
That would give me actionable insight faster than spending weeks learning tools we weren’t operationally prepared to maximize.
Those instincts turned out to be more accurate than I realized.
What I actually built
By the time Playground went live, I felt I had created something that solved a genuine problem.
A tool for somebody who believes in UX but doesn’t have the budget to staff a UX designer and researcher.
It was a simple, repeatable workflow. One that could maintain the goodwill the SERVE513 app had earned.
Stay tuned for the results of the testing.