You didn’t go solo to rebuild the job you left.

Your version works until you show it to someone, and stops the moment they touch it.

You started using AI in your work to move faster. Then you started using it to build something more—an automation, a tool, maybe a packaged product. And it worked. Not perfectly, but enough.

Enough to feel something new. A kind of power. You could create your own—no hiring a software engineer, no team, no approvals. An idea that had only ever lived in your head was suddenly real. Maybe you’d never thought of yourself as a builder before. For a minute there, you were one.

Then it stopped.

The thing works, but only when you babysit it. When you show it to someone else, or take it one step past what you built it for, and it falls apart. The automation runs clean for three days, then fails. The prototype demos beautifully, but confuses the first real person who uses it.

AI is good at the broad strokes. The fine details—the edge cases, the constraints your domain takes for granted—are where it falls down. And that’s exactly where your expertise lives.

You’ve tried Claude Code, Lovable, Replit, and whatever technique came across your feed this week. You can’t tell whether the problem is the tool, the prompt, the idea, or you.

You thought you’d get there on a few quiet Friday afternoons. The nights and weekends and early mornings you’ve poured in were supposed to be the way out. Your freedom from the “job.”

You’re absolutely confident in your domain expertise. Twenty-plus years of it. That’s not the problem.

But that confidence doesn’t translate into a product that other people can actually use. With these AI tools, you’ve been down in the detail, acting as the software engineer. What’s missing is product architecture.

This isn’t a knock on technology. Product architecture is about shaping the technology: understanding who’ll use it and what they’re trying to get done, then crafting how they move through it to get there. Right now, your solution is built around how you work. It has to be built around the person on the other end.

That’s the part the AI can’t do for you. Point it in any direction, and it’ll hand you something plausible, endlessly. But it has no stake in your user, your market, or you. It can’t tell you which version is right; it just keeps giving you more of what you’re already sure about. The judgment is the missing piece, and you have to provide it. That’s the product architect’s job.

Let the AI be the engineer. I’ll teach you to be the architect.

And you can’t iterate your way out of this one. The thing you built and the thing you ultimately need aren’t the same product. You have to come up and out, look at it again from your user’s perspective, and reimagine it from there.

Twelve weeks, one-on-one. We sit on the same side of the table. You bring the thing you’re trying to build, I bring the product architect’s eye, and together we get you unstuck. Along the way, I teach you to be the architect, so you can move forward on your own.

The thing you’re building doesn’t have to be something you sell. A lot of the time, it starts as internal tooling—the automations and efficiencies that make your own practice run better. That counts. Refine it on your own work; maybe it becomes something you package for a client or two on retainer; do that enough times, and maybe it’s something you sell more broadly, someday.

This is for you if:

• You’ve got a consulting or fractional practice that’s working, paying the bills. But somewhere in that success, it became the job you left.
• You’ve been building something in the cracks. It probably started as a way to make yourself more efficient, and now you can see it turning into a real product.
• You learn fast. You’re curious, you ask the hard questions, and you hold your ideas loosely—you can hear “this is the wrong thing” or “you’re going down the wrong path” without shutting down.

This isn’t for you if:

• You’re a technical founder. You already have what you need to build.
• You want a yes-man. Someone to confirm your ideas and come along for the ride.
• You’re married to the idea, and already have all the answers.
• You want someone to build it for you. This isn’t outsourced product development.
• You think you’re a couple of AI prompts away from being the next billion-dollar unicorn founder. (I love the energy. It’s not how this goes.)
• You’re shopping for one specific skill—a UX person, a prompt expert, a growth-and-revenue person. That’s not how I work.
• You’ve already broken through on your own. Keep going—you don’t need this.

The hours spent are the obvious cost. The real impact is where they come from: the evenings, the weekend mornings, the family time, the clients you didn’t chase because you were heads-down on the build. The product was supposed to buy back all of that. That was the goal. Every month it doesn’t happen, the more it stings.

Years ago, I helped build a board-prep product for radiology residents. The founders were radiologists—practicing doctors, textbook authors, the actual experts. They knew exactly how a resident should study, and we built it that way. The residents hated it. They didn’t want to prep the way the experts thought they should; they wanted to prep their way, and we hadn’t paid enough attention to that. The boards run once a year, so it was a mad dash to rework the experience. We leaned on expertise rather than the real user, and it cost us.

The lesson applies equally well whether you’re a startup with expert founders or a solo operator building with AI. Someone I know—sharp, been building on his own with these tools—poured months into a product concept without once stepping back to think through how users would actually show up and pay. I asked him early: What’s the business model? There wasn’t one. The plan was for the users to just show up. He built it anyway. They didn’t.

Different situations, same cost. Confident hours, spent on the wrong version of the thing, while the payoff stays out of reach.

The click is when you can finally come up out of the details—out of the minutiae, out of your own expertise—and see the shape of a product emerge from your concept. You can picture the user, not yourself, moving through it. Your expertise is delivered through the product to people you’re no longer serving, one at a time. You’ve baked it in. Others get the benefit without you in the room.

Before, you could only see yourself and how you work. Afterward, you can see others working that way.

Once you can see the product’s shape, you can see what’s wrong with what you built. Pieces that were never needed. Places where you assumed the user already knew how it works, because you do—your expertise blinding you to what they’d never figure out on their own. The parts that are missing entirely. You’ve got a map of the whole thing now, and it shows the gap between what you built and what a real solution needs. So you know where to go next.

That shift comes from getting out of your own head and talking to actual users—real or potential ones—to see how they work, rather than how you’ve always done it. That’s signal. You gather it from the market and map your expertise onto a solution to a broader set of problems.

And the tools for that—talking to users, gathering signal, testing, iterating, mapping it against the product you’re building—are the same ones that let you keep going without me. I’ll have walked you through a few cycles by then, gotten you past the awkward part. After that, the slices and the map are yours. They’re also what let you work with the AI: you can describe the next piece, because you can see how it fits the whole. Let it be the engineer. You’re the architect now.

The click is the real thing. It doesn’t stay in your head as a feeling, though—it shows up as work you can hold, and tools you keep. Here’s what’s in your hands at the end:

A validated concept

Your idea, thought through and tested against real users, so you know it’s worth building before you sink more time into building it. Not finished code, not ready for market—that’s bigger than this engagement. What you get is the confidence that you’re building the right thing, or an honest read that you’re not.

The map of your product

Who it’s for, what they’re trying to get done, and how a real person moves through the thing. This is the part you were missing: the overhead view that lets you see the whole product rather than just the piece in front of you.

A way to talk to the machine

The language to describe what needs building, so the AI builds the right thing instead of more of the wrong one. The same language works with a freelancer if you choose that path.

Your own way of working

The cycle and the tools, run enough times that they’re yours. So you keep building after I’m gone, and keep evolving the product without needing me back in the room.

A read on your gaps

The two to four skills worth sharpening from here, so you know where to put your effort next.

Underneath all of it: proof that the path out is real, and that you can walk it on your own. That’s what you’re paying for. The artifacts are evidence.

One sync every other week—six sessions across twelve weeks. You walk me through what you built, we look at what worked and what didn’t, and we set the next slice. Between syncs, we work async—messages and short video or audio reviews of what you’re making. The sync is where we make decisions. The async is where most of the building happens. Plan for at least half a day a week on your side. One to two focused days is better. Less than half a day, and the loop stalls.

Weeks 1–2: Diagnose and plan

Some pre-work, then a working session. We do forensics on what you’ve already built, map who you’re actually building for, and scope the first small iteration. The point is to get the vision and direction right while rebuilding the momentum you’ve lost.

Weeks 3–10: Four loops

Build, test, adapt. Same structure every time: you build a meaningful piece; we get input on it (from real users, from the thing running on real cases, from me, or all three); we fold in what it taught us, and we set the next loop. Two weeks a loop, because finding real users and getting real reactions out of them takes longer than the building does. This is the engine. It’s also where you learn to gather signal from real users instead of guessing from inside your own head.

Weeks 11–12: Capper

What we learned, what’s worth keeping, and where you go from here. Plus, a read on your skill gaps.

Along the way, patterns in the signal tell you whether to keep building, change direction, or stop. Build, pivot, or kill. I’ll give you the straight read, because a pivot in week three is better than wasting more time on the wrong thing.

And when I see you resisting the part that matters—testing with real people, accepting a shift the data is pointing at—I’ll name it, and we’ll dig in there.

AI prototyping and coding are fast. The twelve weeks are for finding and accelerating the right thing.

I’ve spent twenty-plus years working deeply in software engineering, user experience, and product management. I’m at home in all three, and I move between them instinctively.

The harder part to explain is what happens in my head when you describe the thing you’re stuck on. I’m pulling from all three disciplines, reflexively, and doing a few things at the same time:

Reframing the problem

Someone told me their data automation kept failing: one flow ran clean, the other broke at random. I asked why they were automating the by-hand data manipulation steps at all—just connect the two systems. The whole conversation changed. The problem didn’t get solved. It dissolved.

Finding the actual user

Watching a demo or a mockup, I’m looking for who’s really on the other end. Not “a home buyer”. A specific person. Why are they here? How do they solve their problem today—without this tool? Generic answers won’t do.

Simplifying the stack

When three tools and a pile of techniques are stitched together to do one job, I want to know if one tool does it more simply.

I look at all of it at once, because none of it stands alone. Move the user experience and the business model shifts. Change the business model, and the architecture evolves.

A specialist goes deep in one of those. AI answers confidently for any one of them. But the product lives in the connections between them—that’s the messy part, and that’s where I work. It’s the product architect’s job, and it’s the part that doesn’t come from a tool.

I won’t sell you a framework with a trademark and a five-step diagram. I’ll sit on the same side of the table, tease the problem apart with you, and help you see it. That’s the fun part for me.

$8,000. I’m taking on a small number of clients to prove this engagement out.

The next step is a thirty-minute conversation. You fill out a short form—what you’re building, where it’s stuck, where you’re headed—so we spend the half hour on your problem instead of catching me up. Then we get on a call and work on something together.

One honest warning: my curiosity runs the show, and I tend to give too much away on these calls. Your gain. You’ll walk out with at least one thing clearer, whether or not we ever work together.

The wall isn’t a sign you’re in the wrong place. It’s where the builder becomes the architect.