Why We Build With Training Wheels
A prototype isn't there to prove we're right. It's there to discover where we're wrong.
There is a moment that shows up in almost every software project.
It usually happens right after someone says, “I think we've got it.”
Then we hand the prototype to someone who actually has to use it.
Five minutes later, everything changes.
And honestly? We hope it does.
Progress Comes From Conversation
Years ago, one exchange has stayed with us far longer than any product announcement ever could.
During the return of Steve Jobs to Apple, he was challenged publicly over why Apple was pursuing Java instead of OpenDoc. It would have been easy to defend every decision, dismiss the criticism, or explain why Apple knew best.
Instead, Jobs did something much more interesting.
He acknowledged that the question was fair.
He explained that incredibly smart people had arrived at different conclusions because they were solving different problems from different perspectives. Good engineers weren't disagreeing because they were uninformed. They were disagreeing because they cared.
Then he shifted the conversation away from defending technology choices and toward building products that solved real problems.
That humility left an impression on an entire generation of builders—not because he had every answer, but because he understood that progress comes from conversation.
We think about that exchange a lot. Especially when someone tells us our prototype doesn't make any sense. Those are usually our favorite meetings.
People Use Software the Way Their Day Unfolds
One of the internet's favorite software memes shows a QA tester being asked to fit different geometric shapes into the matching holes.
The circle goes into the square. The triangle somehow ends up in the bridge-shaped opening. Everything fits… eventually.
It's funny because we've all watched software users do exactly that—not because they're doing it wrong, but because they're trying to accomplish something the software designer never imagined.
If there's one lesson we've learned after hundreds of conversations with business owners, teachers, administrators, technicians, and office managers, it's this: people rarely use software the way software companies think they should. They use it the way their day unfolds.
That's Why We Build Prototypes
Not polished products. Not perfectly branded experiences. Prototypes. Training wheels.
They wobble. They're unfinished. Sometimes they're held together with digital duct tape. And that's exactly the point.
Imagine Trying to Buy Shoes for Someone You've Never Met
You know their height. You know their profession. You know roughly where they live. But you've never watched them walk.
Would you feel confident buying them hiking boots? Running shoes? Steel toes? Probably not.
Software is surprisingly similar. Every business has its own rhythm. Every team has shortcuts they've developed over years. Every owner has little habits they barely notice anymore because they've become second nature.
Those details don't appear in requirements documents. They only appear when someone sits beside you and says, “Oh… that's not how we actually do it.” Those six words are worth weeks of planning meetings.
The Button That Doesn't Exist
One of our favorite moments happens when someone reaches for a button that doesn't exist. We didn't ask them to. We didn't suggest it. Their instincts simply told them it should be there.
That's feedback no survey could ever collect. It's a glimpse into how their mental model differs from ours. And every one of those moments makes the software better.
“Can I Try Something?”
Some of our biggest breakthroughs have happened because someone interrupted our demo.
“Can I try something?”
Please do. Click everything. Break it. Ignore the instructions. Take the scenic route. Show us where it feels awkward.
The prototype isn't fragile. Our assumptions are.
Software Is Never Finished Learning
There's an old saying that software is never finished. We think there's a better version: software is never finished learning.
Every prototype teaches us something. Sometimes it's a tiny wording change. Sometimes it's realizing we've built an entire feature that nobody actually needs. Occasionally it's discovering the real problem wasn't the one we were trying to solve at all. Those are wonderful days.
Polish Can Hide Problems. Conversation Reveals Them.
That's why you'll often see unfinished ideas from us—sketches, clickable mockups, half-built screens, paper prototypes, conversation starters.
Some people wonder why we don't wait until everything is polished. Because polish can hide problems. Conversation reveals them.
You're Not Testing Software. You're Teaching Us.
To everyone who has spent an hour with us—who clicked through an unfinished screen, who told us a workflow made no sense, who laughed when something broke, who patiently explained how the job really works—thank you.
You're not testing software. You're teaching us. Every prototype carries pieces of those conversations forward.
A Curious Side Quest
When children learn to ride a bicycle, we don't celebrate the training wheels. We celebrate what they make possible.
The same is true for prototypes. They're temporary. They're a little awkward. Sometimes they're even a little embarrassing.
But they give us permission to fall over before the stakes are high. And when enough people ride alongside us, eventually the training wheels come off. That's when the adventure really begins.