Everyday Engineering: The AI Category Vibe Coding Companies Are Missing
How a 91-year-old who never coded revealed the billion-dollar category no one's claiming
A 91-year-old built a multi-church enterprise application in 5 hours for $170.
And never written a line of code.
Meet John Blackman. He spent his career as an electrical engineer at Kansas City Power & Light, became the first in his department to learn AutoCAD in the 1980s, and was brought out of retirement to help launch Google Fiber.
Earlier this year, John had a problem. His church runs ‘impact weekends’ - community events offering free haircuts, eyeglasses, car washes, and food to local neighborhoods.
John handled registrations, which meant managing everything by hand: writing names on sticky notes, tracking services with paper forms, coordinating volunteers across multiple churches.
“I said it’d be nice to have that in the computer somehow,” John told his grandson Brett.
So they sat down at 10pm on a Friday night. John described what he wanted - registration flows, multi-church administration, service tracking, volunteer management, automated oil change lookups by VIN number, PDF passport generation, email automation with attachments.
They finished at 3am. The application worked.
Role-based access for system administrators and church leaders. Real-time reports showing who registered for which services. QR code generation for mobile registration. Signature capture for liability waivers. Integration with OpenAI’s API for VIN lookups that automatically determine which oil and filters each car needs.
“Brett says it would probably take his programmers six months to do,” John explained.
Total cost: $170.
When asked how he learned to code, John is matter-of-fact: “I just talk to it like it’s a person.”
He used Claude to write requirements and user stories. Then he fed those requirements into Replit Agent, which generated the application. When something didn’t work, he told the AI to fix it. When it went ‘off on a rabbit trail,’ as John puts it, he’d reset to a working version.
The application now serves multiple churches, handles hundreds of participants, and automates everything from supply ordering to follow-up ministry.
“It’s just like AutoCAD,” John reflects. “A lot of my friends didn’t want to learn AutoCAD, and so when I retired in ‘94, I was still working in 2018. I was still having fun. That’s another reason to learn this technology - if you learn it, you can be having fun well into your seventies, eighties, and nineties.”
Here’s what almost everyone is missing about John’s story:
The tools don’t matter. John used Claude and Replit, but he could have used anything with a conversational interface.
He’s not a “user” of AI coding tools. He’s not doing “vibe coding.” He’s engineering solutions. The tools just happen to use conversation instead of command lines.
John is an avatar for the everyday engineer - someone who solves problems through systematic thinking amplified by conversational interfaces.
And almost no one in the AI tool category is positioning for people like him.
The Revolution Nobody’s Positioning to Own
John’s story isn’t an outlier. He’s the sign of a revolution.
The “How I AI” podcast—where John’s story first surfaced—is seeing hockey-stick growth. Its premise, chronicles stories of people building production level applications through chat interfaces.
The guests prove the pattern: individuals making fitness trackers, small businesses creating inventory management tools, educators building custom learning platforms.
Besides podcasts, YouTube is exploding with tutorials:
“Turn AI into Agents in 90 minutes”
“Build an SaaS product with zero coding experience.”
”Vibe-code your first app this weekend.”
The format is always the same—someone describing what they want to an AI, watching it build, iterating through conversation.
The platforms themselves tell the story in user numbers. Lovable, Bolt, Cursor, Replit—all seeing massive adoption. Not from developers adding AI to their workflow. From people like John who never had a coding workflow to begin with.
LinkedIn recently added “Lovable” as a platform skill you can list on your profile.
But here’s what nobody’s adding: ‘vibe coder’ as a job title.
Try it. Imagine John at a church social: “What do I do? Oh, I’m a vibe coder.” It doesn’t work. The term describes a method, not an identity.
Without category language, people borrowed from what they knew. “Vibe coding” entered the lexicon—a mashup of “vibes” (the casual, intuitive feel) and “coding” (what traditional developers do). Some platforms leaned into it. The term spread.
The success of platforms prove market demand. But not for better autocomplete. Not Smarter context windows. Not Faster generation.
That all screams feature, feature, feature.
Meanwhile, millions of everyday engineers are solving real problems. They’ve reached the summit. They just don’t have language for where they’ve arrived.
The transformation is happening. But nobody’s claiming the territory.
Why Identity Positioning Wins
When you position as “better AI coding assistant,” you’re renting a position in the market until someone one-ups you.
You build a breakthrough feature—maybe context awareness that actually works, or generation that rarely hallucinates. Launch day, everyone’s impressed. Six months later, three competitors ship the same capability.
You build another feature. They copy it. You build faster. They build faster too.
This is the feature treadmill. You’re competing on dimensions that traditional coding platforms already defined: speed, accuracy, context. Every advantage you create becomes tomorrow’s baseline.
Compare that to John talking about what he does.
When asked which platform he prefers, John’s answer revealed something: “Whatever works for the problem.”
He’s tool-agnostic. It could be Replit today, Claude tomorrow. The tools are interchangeable. The identity isn’t.
Feature competition forces you to react to every competitor move. They add this, you need that. Your roadmap is written by watching what others do.
Identity positioning lets you define what matters. Not ‘fastest generation’ but ‘systematic thinking capability.’ Not ‘better autocomplete’ but ‘confidence to solve real problems.’ Not ‘developer tool’ but ‘engineering for everyone.
Engineering. Everyday.
How Everyday Engineering Creates Compound Advantage
Hamilton Helmer’s classic 7 Powers framework maps how companies build lasting advantage.
The traditional starting point? Process Power or Scale Economies.
AI just commoditized both.
Process Power? AI compresses efficiency advantages toward zero. What took six months now takes two days.
Scale Economies? AI drops marginal costs toward zero. John built a multi-church application for $170. A competitor could match that with similar effort.
So where does competitive advantage come from now?
Start with the resource competitors can’t access: identity territory.
The Cornered Resource
When you position as “the platform for Everyday Engineering,” you own access to the 99% who think systematically but won’t learn traditional coding.
Not the 1% who already code. Not the 10% interested in becoming developers.
The 99% who want to solve problems without stumbling through codebases. Church administrators like John. Small business owners automating inventory. Teachers building custom learning tools. Operations leaders who see the solution clearly but can’t implement it.
That population’s transformation is your cornered resource. Competitors focused on “better coding tools” can’t access them—those people already self-selected out of the developer category.
Now watch what that resource enables.
The Counter-Position That Can’t Be Followed
You’re not just claiming different territory. You’re adopting a business model that coding tool companies can’t follow without abandoning their core business.
Coding tool companies monetize developer productivity. Their value proposition: “Ship faster, build more, reduce developer costs.” Their customers are technical teams optimizing output.
Everyday Engineering monetizes identity transformation. The value proposition: “Solve problems you couldn’t solve before. Become the engineer you didn’t know you could be.” Your customers are people discovering capability they didn’t have access to.
This opens completely different revenue streams:
Education and certification: Teaching systematic thinking, not just tool features
Community and methodology: Pattern libraries, peer teaching, solution templates
Transformation consulting: Helping organizations identify which problems everyday engineers can now solve
Identity economics: People pay more for becoming something new than for working faster
A coding tool company can’t easily move here. If they position for “non-coders,” they confuse their developer audience. If they build education for systematic thinking, they’re admitting their tool requires more than developer intuition.
Your business model works because you serve identity transformation. Their business model only works by staying focused on productivity optimization.
They can’t follow you without abandoning what made them successful.
The Network That Teaches Itself
Now everyday engineers start finding each other.
John doesn’t just use the tools. He teaches his methodology: “Start with an outline. Get requirements working. Talk to it like a person when something breaks.”
Someone in his church sees what he built, asks how, learns the approach. They build something for their small business. Show someone else. The methodology spreads.
This creates network effects that feature-focused tools can’t match. Better autocomplete doesn’t teach itself to other users. But an identity—”I’m an everyday engineer”—becomes shared language that accelerates learning.
Each new everyday engineer makes the next one more effective. Not because of platform lock-in. Because of shared methodology, common language, and proven patterns.
The Mental Model That Locks In
Once someone adopts the mental model of everyday engineering, changing becomes expensive.
Not because they’re locked into a platform. John proved tools are interchangeable.
But because they’ve invested in thinking systematically. They’ve learned to describe problems clearly. They’ve built confidence in their engineering judgment.
Switching isn’t “try a different tool.” It’s “abandon this identity and go back to depending on developers.”
That’s switching cost without platform lock-in. The most durable kind.
The Scale That Matters
Scale economies compound because you’re serving the largest addressable market.
The developer tools market? Millions.
The everyday engineering market? Hundreds of millions.
That scale creates advantages in training data, community support, partnership opportunities, and content creation that feature-focused tools can’t match.
The Process Advantage That Emerges
Here’s where Process Power returns—but as a result of identity territory, not a foundation.
Once you own the “Everyday Engineering” category, you develop methodology that serves that identity. Template libraries for common problems. Systematic prompting frameworks. Pattern libraries of solutions.
This process advantage emerges from knowing your users’ identity, not just their feature requests. You’re not competing on “what works best for developers.” You’re building “what helps everyday engineers think systematically.”
The Brand That Becomes Definitional
Eventually, “Everyday Engineering” becomes synonymous with your platform. Not because of marketing spend, but because identity territory claimed early becomes definitional.
When someone asks “What’s everyday engineering?”, the answer becomes “It’s what [your platform] enables.”
This is what Prime Positioning creates: cornered resource that enables counter-positioning, which generates network effects, creates switching costs, develops process advantages, compounds through scale economies, and crystallizes into category-defining brand.
Not seven separate moats. One foundation that makes the others inevitable.
And right now, “Everyday Engineering” sits unclaimed.
The iPhone Playbook
Apple proves you can be a category leader without shipping cutting-edge features first.
Face ID? Android had facial recognition years earlier.
5G? Late to market.
Foldable screens? Still not there.
Yet Apple maintains premium pricing, customer loyalty, and market dominance.
Why? Because iPhone claimed identity territory: “Technology for the rest of us.”
That positioning lets Apple move later than competitors while maintaining advantage. They’re not racing to ship bleeding-edge features. They’re ensuring features work for their identity—accessible, intuitive, designed for people who don’t want to tinker.
This is the everyday engineering business model already proven in consumer tech.
When you own identity territory, you stop racing on features. An Everyday Engineering platform doesn’t need fastest generation speed. It needs clearest error messages. Not smartest context windows. Most accessible systematic thinking support.
Competitors racing to ship better autocomplete are playing a different game. You’re building for identity transformation. Different metrics, different timeline, different economics.
Apple spent fifteen years building that foundation. Now they can enter new categories—watches, headphones, services—because the identity travels with them.
“Everyday Engineering” creates the same foundation. Once you own the transformation from “depends on developers” to “engineers solutions through conversation,” everything else becomes expansion opportunity rather than existential competition.
The playbook works. Apple proved it in consumer tech over fifteen years.
The question is whether someone claims “Everyday Engineering” in the next sixty days.
The Race Is Already Running
Right now, platforms are all competing on features. Better generation. Faster builds. Smarter context.
Here’s what’s actually happening with feature-focused platforms.
Customer signs up. Uses your tool to build something real. Gets more capable through the process. Realizes the capability isn’t tool-specific—it’s systematic thinking they developed.
Then they leave for something cheaper. Or faster. Or newer.
This is the trap. Your business model has an expiration date built in: successful customers become churn risks.
Every tutorial teaches them they don’t need you specifically. Every successful project builds confidence that transfers to any platform. You’re literally training people to not need you.
That competition creates an opening.
When customers transform into everyday engineers, the economics invert. They’re adopting an identity—the methodology, the community, the mental models all reinforce “I’m an everyday engineer” as how they see themselves.
Switching tools means abandoning that identity. Not just changing platforms—rejecting the transformation they’ve invested in.
Someone is reading this right now and thinking: “We should claim this.”
Maybe it’s a founder seeing money left on the table. Maybe it’s a marketer seeing category language sitting unclaimed.
The question is: who claims it first?
Because in category creation, first mover advantage isn’t just real—it’s definitive. The platform that positions as “Everyday Engineering” first doesn’t just win the initial marketing cycle. They define what the category means for everyone who follows.
If you’re a founder or marketer reading this: you have maybe two weeks before someone acts on this analysis.
If you’re reading this as an observer: you’re watching category formation in real-time. “Everyday Engineering” will exist as claimed territory within months. The only question is whose name becomes synonymous with it.
If you’re reading this as an everyday engineer like John: the platforms don’t know what to call you yet. But they will. And when they do, the one that positions around your identity transformation—not their tool features—will win your loyalty.
The market John represents is hundreds of millions of people. The transformation is real. The capability is proven.
The category language is sitting there, unclaimed.
Not for long.