From Sticky Notes to Software
There's a story I keep coming back to. At a vibeathon – a hackathon focused on building with AI – a sheet metal worker showed up. He'd been signed up by his wife. He was six months from retirement and had never touched a line of code.
He listened to the opening presentation and said, "Well, I don't think this is really for me."
Then a software engineer approached him. "I can code, but I don't know the problems. You know the problems. Let's partner up."
They teamed up. The sheet metal worker described the workflow inefficiencies he'd seen every day for 30 years. The engineer used AI tools to build solutions. They finished second place.
Not because the code was elegant. Because the problem description was so good that the solution practically built itself.
The expertise that matters has changed
For decades, building software required one specific expertise: coding. If you couldn't code, you needed someone who could, and you were at their mercy to interpret your vision correctly.
That's no longer true. The expertise that matters now is problem expertise. Understanding the pain. Knowing the workarounds people use. Seeing the gaps that existing solutions miss.
And who has that expertise? The people living the problem every day.
What this looks like in practice
Consider a childcare director who manages a waitlist of 200 families using a spreadsheet and sticky notes. She knows:
- Which families are likely to accept vs. which are shopping around
- That parents want weekly updates but she only has time for monthly ones
- That the state requires specific documentation she currently tracks by hand
- That tour scheduling is a nightmare because parents want evenings but the center closes at 6
No developer would know these details. No product manager would discover them without weeks of research. But this childcare director could describe them in a ten-minute conversation.
With AI coding tools, that conversation is the product specification. Describe the problem, describe the user, describe what "solved" looks like – and the AI builds it.
The pattern: domain expert + AI = better software
The best software has always been built by people who understand the problem. The difference now is that those people don't need a technical co-founder or a $50,000 development budget to act on that understanding.
Here's what the successful path looks like:
1. Start with what you know. You've been doing this job for years. You know what's broken. You know the workarounds. You know what your colleagues complain about.
2. Validate before building. Not everyone who's frustrated by a problem will pay for a solution. Research the market. Understand the competition. Figure out if this is a "nice to have" or a "need to have."
3. Describe the simplest version. Don't try to build the whole vision at once. What's the one thing that would make the biggest difference? Start there.
4. Build iteratively. Show it to someone. Get feedback. Adjust. This is the natural cycle of problem-solving – you've been doing it your whole career. Software is no different.
It's not about the code
The sheet metal worker didn't write a single line of code. He described problems. He gave feedback. He said "that's not how it works on the shop floor" when the solution didn't match reality.
That's the most valuable contribution anyone can make to a software project. And it's the contribution that's been missing from most software – because the people who know the problems weren't in the room.
Now they can be. Not as consultants or advisors or "stakeholders" who get a 30-minute interview. As builders. As the people steering the ship.
Your domain expertise is a superpower
If you've spent years in healthcare, education, construction, retail, manufacturing, food service, real estate, or any other field – you have something developers don't. You have thousands of hours of pattern recognition about how things actually work (and don't work) in your domain.
That knowledge used to be locked up. It could only become software if you could convince a developer to listen, understand, and translate it correctly. That translation always lost something.
Now you can go direct. Describe the problem. Watch it become software. Give feedback. Iterate. The translation layer is gone.
Getting started is the hardest part
The technology is ready. The tools work. The only barrier is the decision to try.
And I get why that's hard. You might think "I'm not a tech person." You might feel like building software is for someone else – someone younger, someone with a CS degree, someone who grew up with computers.
It's not. It's for the person who knows the problem. That's you.
Start with a problem you understand. Research whether it's worth solving. Then describe what "solved" looks like. The rest is a conversation.
Step Zero is built for exactly this moment. You describe the problem, AI helps you research and validate it, and you walk away with a clear plan for building – including the exact prompts to give AI coding and design tools. Your expertise is the starting point. We just help you prove it's worth building.