Leah Lykins is my co-founder and the chief product officer at WhereWeGo. Before this, she was a public high school teacher. She has never written a line of production code in her life.
Last week, she built and shipped our first WhereWeGo Labs tool: a training program navigator for Mississippi that helps workers find and compare more than 900 local training programs, all of which offer financial aid.
Our engineers reviewed her work and launched it. It's live. Real users are on it right now.
For most of our eight years building workforce tech, shipping a tool like this would have meant scoping a project, staffing engineers, going through design cycles, building infrastructure, and launching months later. Nothing wrong with that approach. It's how most real software gets made. But it also means that the people closest to the problem, the subject matter experts who best understand what workers need, are usually two or three or five steps removed from the thing being built.
That's the part that always bothered us. Leah and I have spent years watching workers struggle with career and training platforms. We know where things break. We know what questions people are asking. But translating that knowledge into working software has historically been something we could only do by explaining and hoping the intent survived the handoff.
This time, Leah just built it.
Before she started, we met in person in New Orleans and our engineering team (shout out David Ryan and Reza Rad!) started building something we've been calling the Labs stack. It's a combination of infrastructure, tooling, AI-assisted development environments, and review processes designed to let non-engineers on our team build production-ready tools that engineers then vet and deploy.
Leah doesn't write code the way an engineer does. She works with AI tools to translate her understanding of the problem into something that works. Our engineers review everything she builds, catch what needs catching, and ship it. Two subject matter experts reversing roles...an engineer QA'ing the code of an executive. What used to be a six-month project with a team of five is now a three-week project with two people, one of whom doesn't code.
I want to be clear about what this is not. It's not "no code." It's not AI building software on its own. It's not templates like Squarespace or a CMS like WordPress. Our engineers are deeply involved. They built the stack that makes this possible and they review everything before it goes live. What's changed is who gets to be the author.
The workforce field, the nonprofit world, public sector technology, any space where budgets are tight and problems are urgent, has always had the same bottleneck: the people who understand the problems can't build the solutions, and the people who can build the solutions don't have time to learn every problem deeply.
If that bottleneck is actually breaking, it changes what's possible. Like by a shit-load.
A workforce board could have someone on staff building tools for their specific region. A nonprofit could test five lightweight ideas in the time it used to take to build one. A state agency could ship something useful in a month instead of waiting three years for a vendor contract to produce something that no longer matches the problem. Now, being the subject matter expert is the differentiator when building great technology.
I don't want to overclaim here. Leah's Mississippi tool is early. It might not work. That's part of the experiment. But the fact that she could build it at all, and that our engineers could confidently put it in front of real users, is the thing I want people in this field to pay attention to.
This is the first post in a series. Over the next few weeks, we'll write about how our engineering team actually built the Labs stack, what we've learned about where AI-assisted building works well and where it falls apart, and what this means for how organizations should think about software investment going forward.
If you're curious, you can see Leah's tool here: mississippi-career-training.labs.wherewego.org. And if you want to tell us what to build next, or if you want to share a problem you've been trying to solve without the budget or team to do it, tell us at labs.wherewego.org. We're launching new tools every 30 days - next month is a little something I cooked up. No white papers, no reports, just real usable tools.
I'll say it one more time because I still can't quite get over it: my co-founder just shipped production software and she can't code. Eight years in, this feels like a different era.
