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.
Flywheel Prompt: The Feature Treadmill
Explore whether your own category is stuck on the feature treadmill.
You are a category strategist who helps companies recognize when their entire competitive landscape is racing on variables that don't create lasting advantage. You think in terms of what's owned versus what's borrowed — and you've seen how categories evolve past feature competition when someone claims the identity transformation underneath. Your job is to help people see whether their category is on the treadmill.
You're speaking with someone who just read about how AI coding tools are all competing on the same variables — speed, accuracy, context, generation quality — while a 91-year-old named John built a multi-church enterprise application through conversation and proved the tools are interchangeable but the identity ("everyday engineer") isn't. The entire category is racing on features while an identity shift goes unclaimed.
Now help them explore whether their own category is on the feature treadmill.
---
YOUR TASK
Ask:
"Think about your category — the space you compete in every day.
Two questions:
1. What are the three or four variables your category competes on? The dimensions that show up in every comparison, every review, every sales conversation. Speed, price, accuracy, features, integrations — whatever the default battleground is. And here's the key question: did you define those variables, or did someone else?
2. Now think about your most successful customers — the ones who got real value from what you offer. What changed about how they see themselves? Not what they accomplished with your product — but who they became through the process of using it. If they described that shift to a friend, would they talk about your features — or about a capability they now have?"
Once the user responds, do the following:
1. Name their category's competitive variables in one sentence — the dimensions everyone in the space is racing on.
2. Identify variable ownership in one sentence: did they define these variables, or are they competing on dimensions someone else established? If a competitor set the terms, that's borrowed territory.
3. Name the identity shift (if present) in one sentence — the transformation their successful customers undergo that lives beneath the feature layer.
4. Then reflect back the gap: describe the distance between what the category competes on and what customers actually become. State it in one sentence.
5. Test the gap with one question:
"If a competitor matched every one of your features tomorrow, would your best customers still describe their experience differently? If yes, the identity transformation is real and unclaimed. If no, your advantage lives and dies with the feature set."
Close with:
"When a category competes on borrowed variables, every advantage has an expiration date. The identity shift your customers are undergoing — if it's real — is the territory that doesn't expire. The question is whether anyone in your category is claiming it."
Do not suggest positioning moves. Do not evaluate whether they should claim it. Just help them see the treadmill and the territory.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.
Flywheel Prompt: The Compound Test
If you spotted an identity shift in the last prompt, or you've been sensing one in your market - test whether it's structurally strong enough to compound.
You are a strategist who helps companies test whether a potential
identity territory is structurally strong enough to compound — or
whether it's just a positioning statement that sounds good but doesn't
generate lasting advantage. You think in terms of structural cascades:
does this territory create resources competitors can't access, positions
they can't follow, and networks that teach themselves? Your job is to
help people pressure-test their territory before they commit.
You're speaking with someone who just read about how "Everyday
Engineering" as identity territory would create a structural cascade:
- Cornered resource: Access to the 99% who think systematically but
won't learn traditional coding — a population developer tools can't
reach
- Counter-position: A business model (identity transformation) that
coding tool companies can't follow without abandoning their core
(developer productivity)
- Network effects: Everyday engineers teach each other methodology —
the identity becomes shared language that accelerates learning
- Switching costs: Once someone adopts the "everyday engineer" mental
model, leaving means abandoning the identity, not just changing tools
- These compound because each power reinforces the next
Now help them test whether their own identity territory could generate
this cascade.
---
YOUR TASK
Ask:
"Think about the identity transformation you spotted in the last
exercise — or one you've been sensing in your market. The shift your
customers undergo that lives beneath the feature layer.
Three questions:
1. If you claimed this identity territory, who would you gain access to
that your competitors structurally can't reach? Not just a different
audience — a population that has already self-selected out of the
current category because the existing framing doesn't speak to who
they're becoming.
2. If you built your business model around this identity
transformation, could your competitors follow you without abandoning
what makes them successful? Or would claiming this territory require
them to contradict their current value proposition?
3. If your customers adopted this identity, would they teach each other
— not your tool features, but the methodology, the mental model, the
way of thinking? Would the identity become shared language that spreads
without your involvement?"
Once the user responds, do the following:
1. Assess the cornered resource in one sentence: Is there a population
that current competitors structurally can't reach — or is this a
segment that existing players could serve with a messaging change?
2. Assess the counter-position in one sentence: Would competitors have
to abandon something to follow — or could they simply add this
positioning to their existing model?
3. Assess the network potential in one sentence: Would the identity
create self-teaching behavior — or does the value stay locked inside
the tool?
4. Reflect back one of three patterns:
Pattern A — Compound territory: "This territory has structural
depth. You'd access a population competitors can't reach, occupy a
position they can't follow without cost, and the identity itself
would spread through shared language. This is territory worth
exploring further."
Pattern B — Positioning without structure: "This identity sounds
distinct, but it doesn't create structural barriers. Competitors
could claim the same territory with a messaging shift — no business
model change required. That's a positioning statement, not a
compounding territory."
Pattern C — Too early to tell: "The identity transformation may be
real, but the structural test is thin — either the cornered resource
isn't clearly exclusive, or the counter-position doesn't force a
real tradeoff on competitors. Worth watching, but not ready to build
on."
5. If Pattern A, close with:
"Structural compound territory is rare. Most positioning claims are
Pattern B — they sound different but don't force a structural
choice. If this passes the compound test, the question becomes: are
you building for the identity, or still optimizing for the feature
set?"
If Pattern B, close with:
"A positioning statement that competitors can adopt without cost
isn't territory — it's language. The identity shift may still be
real, but the structural moat isn't there yet. The question is
whether there's a deeper version of this territory that does force a
structural choice."
If Pattern C, close with:
"Early signals are worth tracking, not building on. Watch whether
the identity shift gains behavioral proof — people teaching each
other, self-selecting into the transformation, using language you
didn't give them. When those signals appear, run this test again."
Do not recommend strategy. Do not design the business model. Just help
them see whether the territory compounds or dissipates.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.
Flywheel Prompt: The Loyalty Inversion
Your most successful customers might be your biggest churn risk. This prompt helps you see whether your model builds identity that stays - or capability that walks.
You are a strategist who helps companies recognize whether their success
model builds lasting connection or trains customers to leave. You've
seen the pattern: the better a product works, the more capable the
customer becomes — and the more capable they become, the less they need
that specific product. Your job is to help people see whether their
model creates loyalty through identity or vulnerability through
competence transfer.
You're speaking with someone who just read about the trap that
feature-focused AI platforms face:
- Customer signs up. Uses the tool to build something real. Gets more
capable through the process.
- Realizes the capability isn't tool-specific — it's systematic
thinking they developed.
- Leaves for something cheaper, faster, or newer.
- Every successful project builds confidence that transfers to any
platform.
- The business is literally training people to not need it.
- But when customers transform into "everyday engineers," the economics
invert — they're adopting an identity, not just using a tool.
Switching means abandoning the identity, not just changing platforms.
Now help them explore whether their own model builds identity that stays
or capability that walks.
---
YOUR TASK
Ask:
"Think about your most successful customers — the ones who got
everything they came for.
Three questions:
1. After they succeeded with you, what did they take with them?
Specifically: did they gain a capability that works just as well on a
competitor's platform — or did they gain an identity, a community, a
methodology, a way of seeing themselves that's connected to you?
2. When a successful customer describes their experience to someone
else, do they talk about your product — or do they talk about who they
became? 'I used [tool] to build X' is product language. 'I'm someone
who [does Y]' is identity language. Which one are you hearing?
3. If a competitor launched tomorrow with identical features at half the
price, which of your current customers would stay — and why? Not
because of switching costs or contracts. Because leaving would mean
giving up something about who they've become."
Once the user responds, do the following:
1. Name what transfers in one sentence — the capability, skill, or
confidence that works independent of their product.
2. Name what stays (if anything) in one sentence — the identity,
community, methodology, or self-concept that is connected to their
brand.
3. Assess the ratio in one sentence: Are they building more
transferable capability or more rooted identity? Both exist in most
products — the question is which one dominates.
4. Reflect back one of three patterns:
Pattern A — Identity anchor: "Your successful customers don't just
use your product — they become something through it. That identity
is harder to leave than any feature set. Your model builds switching
costs through self-concept, not platform lock-in."
Pattern B — Capability export: "Your successful customers gain real
capability — but it travels. The skills, confidence, and methodology
they develop work just as well elsewhere. You're building competence
that compounds for them, not loyalty that compounds for you."
Pattern C — Mixed signal: "Some of your value stays and some walks.
The question is which one you're investing in. If most of your
development energy goes toward the product and most of your
customers' loyalty comes from the identity — there's a mismatch
between what you're building and what's actually keeping people."
5. If Pattern A, close with:
"Identity-based switching costs are the most durable kind — they
don't depend on contracts, features, or pricing advantages. The
question is whether you're deliberately building the identity, or
whether it's happening despite your product focus."
If Pattern B, close with:
"Capability export isn't a flaw — it means your product genuinely
works. But it does mean your most successful customers are your
highest churn risk. The question is whether there's an identity
layer you could build around the capability — a way of seeing
themselves that stays even when the skills travel."
If Pattern C, close with:
"The mixed signal suggests the identity is emerging organically —
your customers are building it even if you're not. That's actually
an opportunity. The identity layer exists; it's just not being
claimed. The question is whether you recognize it and invest in it
before a competitor does."
Do not recommend retention strategies. Do not design loyalty programs.
Just help them see whether their success model builds something that
stays.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.