There's something counterintuitive about making your AI system slower on purpose. But that's exactly what we did with Kelly, our AI-powered product development system, and it might be one of our smartest moves yet.
The "Build First, Ask Questions Later" Problem
Kelly was like that eager intern who dives headfirst into every project. Someone would feed her a product idea, and off she'd go—coding, building, shipping. The enthusiasm was admirable, but the results? Well, let's just say we were getting a lot of "technically correct but completely missing the point" products.
We realized we had fallen into the classic trap of optimizing for speed over understanding. Kelly was building fast, but she wasn't building right.
Teaching Kelly to Think Before She Builds
So we hit the pause button and redesigned her entire workflow. Now, instead of immediately jumping into development mode, Kelly does something revolutionary: she asks questions.
We've implemented a human-in-the-loop system where Kelly conducts deeper analysis before writing a single line of code. She'll probe the market opportunity, question assumptions, and build out comprehensive context around what she's actually trying to solve. Only then does she start building.
It's like the difference between a contractor who starts hammering based on a napkin sketch versus one who asks to see the blueprints, checks the foundation, and understands the neighborhood first.
We're calling these "one-shot builds"—the goal is to get it right the first time instead of iterating our way out of fundamental misunderstandings.
From Black Box to Blueprint
The bigger shift happening here is how we think about project-level building. Before, Kelly's decision-making process was essentially a black box. She'd take inputs, do her AI magic, and output a product. When something went wrong, we'd shrug and say "AI gonna AI."
Not anymore. We're working to define everything upfront—the market analysis, the user research, the technical requirements, the success metrics. Every decision Kelly makes now has a paper trail, and every assumption gets validated before it becomes code.
It's more work upfront, but we're betting it'll create dramatically better builds over time. Think of it as moving from "spray and pray" to "measure twice, cut once."
Our First Open Source Adventure: FeedbackFlow
While we've been teaching Kelly better habits, we've also been cooking up something special for the community. Meet FeedbackFlow—our first open source product, and honestly, we're pretty excited about it.
FeedbackFlow is all about making feedback collection and bug squashing painless. We built it because, well, we needed it ourselves. When you're building products at the pace we are, traditional feedback loops become bottlenecks fast.
The best part? We're releasing it to the wild soon, and we can't wait to see what the community does with it. There's something nerve-wracking but thrilling about putting your code out there for everyone to see, use, and probably improve in ways you never imagined.
A Little Easter Egg Hunt
Oh, and if you haven't checked out our new website lately, you really should. We're pretty proud of how it turned out. Pro tip: keep an eye out for the IMOS easter egg—because who doesn't love a good hidden surprise?
What's Next: Going Open Source
The next few weeks are going to be interesting. We're preparing to release FeedbackFlow into the community, and there's that familiar mix of excitement and terror that comes with shipping something new.
We hope you'll love it as much as we loved building it. But more than that, we hope it becomes something bigger than what we originally envisioned—that's the magic of open source, after all.
Building in public means sharing the messy middle along with the victories. Kelly's getting smarter, our processes are getting better, and we're about to find out what happens when we give our work away for free.
Stay tuned—things are about to get interesting.