The Blue Collar Builder’s AI Trap
I have spent nearly thirty years around blue collar businesses and the software built to serve them. I understand exactly why so many founders, owners, and operators are going hard with ChatGPT, Claude, Lovable, and everything else they can get their hands on. For the first time in a long time, a capable builder can create real tools, real workflows, and real internal systems without waiting on a budget, a dev team, or somebody else’s permission.
Some of what I am seeing is genuinely impressive.
Some of it is also heading toward a trap.
The trap is not that these founders are behind. Many of them are already waist deep in building. They are already in love with their apps, their tools, and their projects. That is exactly why the questions need to get harder.
The more excited you are about the thing you built, the more aggressively you should test whether it is capturing real company know-how, merely preserving your current habits in shinier form, built on sound ways of working or simply tuned to get the result you wanted, and whether it was truly shaped for an AI-ready future or merely built with AI as the latest power tool.
In more ways than most people realize, building software and building a house are the same kind of test.
A person today, with enough grit, internet access, AI help, and a reckless amount of confidence, can probably build an entire house alone. He can learn footings on Tuesday, framing on Thursday, roof pitch over the weekend, and by next month he has strong opinions on vapor barriers, stair rise, service panels, and the moral failings of local inspectors. ChatGPT helped him think through the sequencing. Claude helped him compare options. YouTube carried him through the awkward parts. A few forums got him through the weird parts. Somewhere along the line he learned just enough to become dangerous, then just enough more to become productive, and by sheer force of will he got the thing standing.
And to his credit, he did it.
The foundation may have gone in after three redesigns and one midnight change of plan, but it went in. The framing may include a few places where the house had to be persuaded rather than built, but the walls are up. The plumbing takes an imaginative route through the structure, the electrical panel reads more like a confession than a diagram, and the HVAC leaves one room feeling like Miami and another like a monastery in February, but technically the system is operational. The lot pitched wrong, so he invented a drainage solution no textbook would recommend but that appears, for now, to be working. A beam delivery got delayed, so he redesigned half the span from his phone while sitting beside a stack of wet lumber. The duct run would not fit, so a closet lost an argument with physics. None of this stopped him. “But hey, I did it anyway” became not just his explanation, but his method.
For a brief moment, the house feels like a triumph. The paint dries. The pictures look great. He walks through it with the satisfaction of a man who has bent reality to his will. Every room carries the memory of a problem solved. Every compromise has a backstory. He does not experience the house as a collection of oddities. He experiences it as a chain of victories.
Then, no sooner than the paint is dry, the problems begin to show up.
Not major failures at first. Just the kind of problems that make every tradesman stop and squint.
A cabinet installer pauses too long in the kitchen. An electrician squints at the panel as if trying to understand a dead language. A plumber opens a wall and goes quiet. An HVAC tech studies one zone for a full minute and then says, “Well, that’s one way to do it.” The trim carpenter can finish the work, but only after accepting that the house does not fully subscribe to the idea of square. Every trade can continue, but none can proceed without first reverse-engineering the mind of the man who built it.
That is when the deeper problem emerges. The house works, but only in the presence of its author.
Its logic is real, but private. Its patterns are consistent, but only to the person who invented them. Its exceptions are survivable, but only because he remembers why they exist. The knowledge is not in the structure in any clean, teachable way. It is still stored in the builder.
And that means, for all practical purposes, he may be the only person who can ever comfortably live in this house.
He knows that if you shut off that valve first, the other issue never happens. He knows that the third switch in the mudroom should never be touched during heavy rain. He knows which crack matters and which one does not. He knows which door sticks in August, which drain needs coaxing in January, and which outlet shares a circuit with something nobody would ever reasonably expect. None of this feels alarming to him because he carries the whole map in his head.
It all holds together until the day comes to sell the house.
Now the problem is no longer whether it can function. The problem is whether it can be understood, trusted, serviced, valued, insured, inspected, taught, and handed off. A buyer does not buy your backstory. A buyer buys a house. The bank does not finance “it makes sense once he explains it.” The next owner does not want to inherit a dwelling whose operating manual is a living human being.
The market punishes private logic.
That is the danger with a lot of founder-built tools in the AI era. They can be useful, clever, and genuinely impressive. They can absolutely work. But if the logic is private, the assumptions are hidden, and the system still depends on the builder to explain it, then the thing may be a lot more like that house than its creator wants to admit.
That is why one question still matters more than the rest: what happens if you get hit by a bus?
If the answer is that the company slows down, gets weird, starts leaning on side texts and rescue calls, and quietly depends on your memory to keep functioning, then be careful what you call progress. You may not have built lasting company know-how. You may have built a house that only you can live in.
Here’s a short list of techniques that have worked well for me as I build features, demos, and apps. None of this is magic.
Study the segment before you start designing.
Before I push too far into a feature, demo, or app, I like to probe what the AI knows about the niche, the competitors, and how similar products actually work under the hood. The math, the logic, the workflow, and the handoffs all matter. A cleaner build usually starts with a better map of the territory.
Start with real evidence.
I have found it very useful to begin with drawings, screenshots, PDFs, real data sets, and other concrete materials from the actual domain. Real evidence keeps the build grounded. It reduces guesswork, sharpens the prompts, and makes it much harder for the feature or demo to drift into software theater.
Begin with the end in mind.
A lot of times I already have a strong sense of the outcome I want, which might be the dashboard I want a user to rely on at scale, the screen where the work will really happen, or the surface that should make better decisions easier. Working backward from that helps me avoid a lot of wasted motion.
Use one AI to plan, another to build, and another to critique.
I have found it very useful to split the work across multiple AIs instead of letting one model do everything. One helps shape the plan. Another executes. Another reviews the result. That back-and-forth exposes weak logic, missing steps, and false confidence much earlier.
Build the load-bearing spine early.
Once I understand the terrain, the evidence, and the likely destination, I try to establish the core structure early so later features have something solid to hang off of. When the spine is right, new surfaces, workflows, and helpers can be added without constantly tearing the whole thing apart.
Check the build against best practices, not just best outcomes.
A build can feel great and still be wrong in important ways. I have found it helpful to ask AI to review the workflow, structure, and logic against best practices, not just whether it got me the result I wanted.