From Tinkerer to Builder (Leveling up with AI)
My Messy Path to Becoming a Builder
I’ve written before about the user guide to AI adoption - the journey from Level 1 (skeptic) to Level 2 (tool user) to Level 3 (builder). The gap between Level 2 and Level 3 isn’t about technical knowledge or coding ability. It’s about something harder: the willingness to fail, iterate, and keep building anyway.
This is the story of how I started to cross that gap in the second half of 2025. It started with a spectacular failure.
The Nashville Flight Tracker That Wasn’t (Q3 2025)
I had what felt like a perfect first project. I’m always looking for travel opportunities around the dates my kids come off school. The problem was clear: I’d go look at Metro Public Schools calendars, then I’d look at the airlines I like flying based off loyalty information, then I’d look at what’s non-stop or one-stop. Not too far mind you, because I’m not trying to spend 12 hours on a plane with my kids for one week. I wanted something to pull all that information together and give me flight deals if anything dropped to surround some of these dates for cool international locations from Nashville. Just send me an email.
Perfect use case, right? Specific problem, clear requirements, high personal value.
I worked with ChatGPT to write a PRD and turn that into code. Created a GitHub account. OK, I’m going do this! I found a service with flight search APIs and hooked them up to go pull flight search details. After 15 hours of working on this over the weekend…. it just didn’t work. The workflow was firing, and I’d get a daily digest email, but it was never completing the searches based off the parameters. I tried to diagnose using AI to figure out what the errors were, sort through the errors. Still didn’t work.
Finally I was like, screw it. This is too much work, and the use case wasn’t valuable enough for the level of effort.
I stopped there (at least for the time). Pivoted to leaning in on Claude skills, projects, and building semi-automated workflows to help do the things I did most regularly.
The Reframe (Q4 2025)
In Q4, I came across a podcast with Jason Lemkin from SaaStr talking about building AI agents that actually worked. He wasn’t talking about revolutionary products or perfect code. He was solving really specific use cases for himself. Obviously not perfect solutions, but he was able to ship them and they worked well enough to be useful.
That reframed everything for me. I’d been thinking about building the way I think about production software at Checkr - robust, scalable, handling edge cases. But Jason was building like someone solving Tuesday’s problem by Wednesday morning.
I decided to give a couple of new tools a try. Start stupidly simple. Solve one specific thing.
The Breakthrough Sequence
The Baby Grumpiness App
I started with Lovable. I was thinking about a very specific, very dumb problem: when my daughter Daisy, who’s about 15 months old, is really grumpy for a few days, we go on this investigation. What could it be? We generally start with the baby horoscope, Wonder Weeks - if you’re a parent, you know what I’m talking about! Then, I go to baby teething charts — maybe she is getting teeth right now? Really, you’re just trying to find some rational reason that your baby is more grumpy than normal.
I thought….okay, what if I could just build an app where you’re able to type in your baby’s name and date of birth, it pulls all this information, and is contextually aware?
I had this idea on a run; then pulled up Wispr Flow on my phone and talked about it for 10 mins. Back at my computer, I dropped the idea into Claude, and leveraged a requirements skill builder that one of my teammates built that helps write good PRDs to draft a PRD around this concept.
It’s now 6:30 am, and I create a free Lovable account with the attitude…"Okay, let’s see what happens”. And, you know what? I got something visually appealing with most of the functionality that I asked for within 10 minutes.
My first reaction was, holy shit, this is great. Obviously it wasn’t solving a big problem. But it was a fun, specific problem. I went back and forth for a couple of hours building out and tweaking new features of the app. I was hooked.
The Director’s Workflow Tool
Fast forward. A director on my team talked in a 1-1 about a new workflow that we launched, and how our agents are manually calculating dates in the future using third-party tools online. This stuff happens ALL THE TIME in operations teams — you need to do something new to cover a gap, and ops tools don’t get built to help.
During the conversation, I was thinking… can I build that with lovable? It’s a pretty defined use case. Something that engineering probably will never have time for because it’s so small, but meaningful to actually improve quality in a really consistent way and make the team’s job easier.
I did the same thing the next morning. Used Wispr Flow to talk about the problem, built a PRD, spent a little bit more time going back and forth on the requirements, dropped it in Lovable. Later, I added some other features to address the team’s feedback (ie. like what happens if we have multiple dates? Do we want an auditing function that lets you see what’s been run?)
As an operator, it was absolutely incredible to see how quickly (and easily!) you can go from “Hey, I have a problem” to having a viable solution.
The Social Sentiment Dashboard
By this point, something had shifted. I have been in operations my full career because I LOVE solving problems, and this felt like a superpower. I saw someone had built a social sentiment dashboard with Lovable on Linkedin, and my immediate reaction was remembering that our social tool took 2 weeks, 2 WEEKS respond to my inquiry about our social sentiment only to give me a generic report. My next reaction was…“I could build that.” So I did.
Solving a bunch of $100k problems
A few weeks later, Daniel and I were talking over lunch about how we enable this sort of building across Checkr. What’s an easy entry point to building, Replit or Lovable? How do we start to proliferate this across the org? We could do training, but a lot of this is highlighting the art of the possible internally and getting people really excited about it.
The magic starts to happen when you as a leader share that excitement with others, and teams show each other what they’re building. Each person starts getting inspiration from the next best use case. Pretty soon, everyone is excited and building!
What I get most excited about is that this is how we start to solve a bunch of $100k problems. The things that are never quite big enough to shift engineering resources onto them, but really painful for the frontline teams doing them. Becoming builders really enables a full team to tackle those sets of problems.
What Actually Changed
The difference between Q3 and Q4 wasn’t that I got better at coding. I’m still not a developer.
What changed was my approach:
Scope ruthlessly small. The flight tracker tried to solve scheduling, loyalty programs, route optimization, international destinations, and pricing all at once. The baby app answered one question with one input. The workflow tool solved one specific calculation problem our agents faced. Start there.
Iterate faster. After 15 hours on the flight tracker, I hadn’t shipped anything functional. The baby app took maybe 10 minutes to get to a working version, then a couple hours of iteration to make it better. That tight feedback loop is everything - you learn what works before you’ve invested too much in what doesn’t.
Solve specific problems. “Flight deals for my family” is actually a huge problem space. “Why is Daisy crying right now” is a specific question with a bounded answer set. “Calculate dates 45 days in the future for this workflow” is a defined calculation. The narrower the problem, the more likely you can actually build a solution.
Use the right tools. The combination of Wispr Flow for capturing requirements, Claude with the requirements skill builder for creating PRDs, and Lovable for actually building the app created a workflow that just worked. Each tool did what it was best at.
Recognize the “engineering will never build this” opportunity. Some problems are too small to prioritize in a formal roadmap but meaningful enough to improve quality and make people’s jobs easier. These are perfect building opportunities - high impact for the team, low risk if it doesn’t work perfectly. These $100k problems add up fast.
Show, don’t tell. Training on tools helps, but what really spreads building culture is people seeing what their colleagues built and thinking, “I could do that too.” When a director sees another director ship something useful, or when a team member sees what’s possible over a weekend, that’s when the compound effect kicks in.
The compound effect of these small wins is real. Each one builds pattern recognition. You start seeing which problems are “buildable” and which aren’t. You develop intuition for what’s a 2-hour project versus a 15-hour rabbit hole. And then it spreads, and suddenly you have a team of builders tackling problems that would have sat in the backlog forever.
What Level 3 Actually Means
Level 3 isn’t about technical mastery. I’m still googling basic syntax. I still hit walls where the AI generates something that doesn’t work and I can’t figure out why.
Level 3 is about seeing problems differently. It’s the shift from “someone should build that” to “I could build that.” It’s understanding that “good enough to solve my problem” is actually the right bar, not “good enough to sell as a product.”
It’s also about seeing the opportunity space differently. When a director mentions a manual workflow, you start thinking, “Could I build that?”
And crucially, it’s about building things that make other people think they could build too. That’s the real transformation - not just becoming a builder yourself, but helping create a culture where building is a normal response to problems.
Postscript: Why This Took So Long to Finish
I started writing this post weeks ago. I had the arc, the examples, the lessons learned. But I kept not finishing it.
The reason? The new models (hi, Opus 4.6!) got so good that all my free time went to playing around with them instead of writing about them. I started to play with Claude Code, and suddenly I’m building stuff in my terminal instead of in a browser. The feedback loops got even tighter. The “I could build that” reflex got even stronger.
Last night, my 8-year-old daughter Lucy wanted to build something. We used Replit to make a Taylor Swift coloring app - basically MS Paint but themed - with a bunny who pops up every few minutes to tell jokes. She told me what she wanted, we wrote it down as a prompt in Replit, and had a lot of fun building, playing, tweaking.
If Lucy can build an app, anyone can.
That’s not hyperbole or inspiration-speak. That’s just what’s possible now. The gap between having an idea and having something working is collapsing so fast that by the time I finish writing about what’s possible, something new is already possible.
So here’s my real closing thought: don’t wait to become a builder until you feel ready. Don’t wait until you’ve taken the course or read the tutorials or learned to code properly. Just start. Build something dumb. Show someone. Build the next thing.
The journey from tinkerer to builder isn’t about the big ambitious project that proves you can do it. It’s about the accumulation of small, imperfect wins that teach you that you already can. And then it’s about showing others that they can too.