Most founders think they’re building a product. They’re actually debugging a system they never fully loaded.
The Bootloader Protocol is how I model PMF — not as a milestone, not as a state you achieve and then have, but as a layered system that either boots correctly or doesn’t boot at all.
Four layers, sequenced bottom-up. Each one depends on the integrity of the layer below.
Skip a layer and every layer above runs on a foundation that was never validated. The system looks like it’s running. Until it doesn’t.
What I want to do here is go one level deeper than the architecture. Each layer has a specific failure mode. Each failure mode surfaces two layers above where the skip actually happened.
That gap — between where the symptom appears and where the cause lives — is why the same companies keep applying the same fixes and watching the same metrics drift.
Layer 1: The Kernel
Nothing is being built here. That’s the point.
The Kernel is where you establish whether the problem you identified actually exists at scale outside your own experience. Whether the market is structured to support a solution like the one you’re proposing. Whether the buyers you’re targeting are the ones actually living the problem — and whether their specific circumstance, the situation that triggers them to go looking for a solution, has been understood at sufficient depth to anchor everything that follows.
The Kernel is the most-skipped layer in early-stage tech. Not because founders don’t know it exists. Because the deliverables look small relative to shipping something.
Interview notes. Problem definitions. A clear buyer circumstance. None of it feels like progress. So founders run a few conversations, hear that the problem is real, and call it done.
That’s not Kernel work. That’s conviction with a sample size.
The validation work at the Kernel is interview-driven and observation-driven. Open-ended conversations with buyers in the relevant circumstance. Observation of how those buyers currently solve the problem — or fail to solve it, or work around it.
You’re not asking whether people want your product. You’re establishing whether the problem exists consistently enough, in a market structured enough, with buyers defined specifically enough, to support a business.
When the Kernel doesn’t load, the failures don’t announce themselves as Kernel failures.
The product gets built — sometimes well. It solves a problem. Just not the problem the buyer needs solved badly enough to pay for, consistently, at a price that sustains the business. The symptoms appear at the MVP layer. Retention drops. Usage is flat. Churn arrives early. The instinct is to fix the messaging. Rewrite the positioning. Run a new campaign. All of it applied two layers above the actual cause.
The Kernel is where most Invisible Burn Rate originates. It’s also the layer you can’t go back and load retroactively without stopping, which is why founders resist the diagnosis.
Layer 2: The Driver
Still no building. This is the most commonly skipped intermediate layer, and the skip has a specific cost.
The Driver is where you test solution shapes with buyers before code starts to congeal into commitments. Not a feature list. Not a roadmap slide. A solution shape — something the buyer can react to with their behavior, not just their words. Where they hesitate. What they reach for that isn’t there. What they try to do that the design didn’t anticipate.
The discipline here is to listen, not to seek validation. Buyers describe symptoms. The job underneath the symptom is almost always different from what the buyer named.
A buyer who asks for three new features this week, when pressed through Five Whys, is usually solving for “this would be nice to have.” Not a must-have. Not a deal blocker.
The Driver layer is where you find that out before engineering hours are committed, not after.
One important exception for AI founders specifically. If you are building an AI product, the Driver layer artifact is not a Figma file. You cannot show a buyer a mockup of an LLM- powered workflow and get meaningful signal.
The value of the output only becomes real when the model is actually running.
The Driver layer artifact for an AI product is a functional thin slice — a single working inference on a single real buyer input, built specifically to validate whether the solution shape fits how the buyer thinks about the problem. A screenshot of where the output would appear tells the buyer nothing. A working call on their actual data tells you everything.
When you skip the Driver and move straight from Kernel work to building the MVP, you discover only after engineering hours are spent that the solution shape was wrong.
The cost of pivoting after the product exists is structurally higher than the cost of pivoting before.
Every hour spent at the Driver is hours not spent re-architecting something that already shipped.
Layer 3: The Shell
Now the product is being built. Deliberately ugly. Simple. Intentionally minimal.
The Shell is PoC and prototype — the command line before the graphical interface, to use the computing analogy. This is where a Concierge MVP can legitimately live. Solving a few clients’ problems yourself, using your own tool, until the product reaches PMF, is a valid early-stage move.
The trap is not running a Concierge MVP. The trap is what it becomes if the product never gets intuitive enough for the buyer to use without you in the room. That’s the Consulting Trap.
The product is so misaligned with how the buyer actually works that buyers ask you to do the work for them. You oblige, because it produces revenue and case studies. The team looks busy. The deck has logos. Every signal reads as traction.
What’s actually happening is that you’re delivering outcomes with headcount, not with product. The unit economics you were funded against do not apply to the business you’re actually running.
The P&L tells the story before anything else does. In a healthy early-stage SaaS business, gross margin on subscription revenue runs 65–75% and improves as you scale — because the product gets more efficient to deliver, not more expensive.
In the Consulting Trap, gross margin compresses as you grow, because every new customer requires delivery headcount to onboard, run, and retain. If your blended gross margin is below 50%, or your services revenue is exceeding 20% of total revenue, you’re almost certainly in it.
The early warning signals are specific. Buyers won’t go live without a dedicated onboarding call that runs longer than 90 minutes. Your team is building customer-specific features that never make it into the core product. CS is doing work that your documentation should be doing. Revenue per customer is high but headcount per customer is high and growing.
The reason founders don’t notice they’ve crossed the line is that the Consulting Trap feels like traction.
By the time a VC asks about gross margin on your next fundraise and the answer is below 60%, the conversation goes somewhere you don’t want it to go.
The fix is not to fire the CS team. The fix is to go back to the Driver layer and ask the question you skipped: does the solution shape actually match how the buyer thinks about their problem?
If the product requires you in the room to work, the Shell was built on a Driver that was never properly validated.
Layer 4: The OS / MVP
The MVP is what emerges from the layers below being properly loaded. It is not what you start with.
Most founders treat the MVP as the entry point of the work. It is the exit point of the work that actually matters.
Post-launch, the validation doesn’t stop. The OS layer has its own work: whether the product, in real use, does the job the buyer hired it for. Whether the buyers actually using it are the ones the previous layers identified. Segment-level analysis. Continued user research. Patching and debugging against real use patterns.
The signals that tell you the OS layer is healthy are retention and usage. Not signups. Not month-one MRR. Not NPS scores from users who are too polite to churn yet.
Retention tells you whether the Bootloader actually loaded. If retention is dropping and usage is flat, you haven’t found PMF. And if you haven’t found PMF, scaling acquisition compounds the problem — not the traction.
The bottom-up diagnostic
When something breaks at the OS layer — retention collapsing, signups not converting to use, churn arriving before you expected it — the instinct is to fix the MVP.
Rewrite the onboarding.
Redesign the dashboard.
Run a win-loss analysis on the last ten churned accounts.
None of that is wrong. But it treats the symptom at the layer it appears. The cause is almost always two layers down.
The diagnostic question isn’t “what’s wrong with the product?” It’s: which layer below the symptom didn’t load?
Product solves the wrong problem: Kernel.
Solution shape doesn’t match how buyers think: Driver.
Delivering outcomes with people instead of product: Shell.
Start from the bottom. Fix the layer where the cause lives. Everything above it follows.
If you are sitting with a specific layer and not sure whether it actually loaded — that
uncertainty is the diagnostic. Uncertainty at the OS layer usually means the Kernel.
Uncertainty about why traction has stalled usually means the Driver. The layer that feels most uncomfortable to go back to is almost always the one that never loaded.
Founder’s Stack Trace is a field guide for technical founders pre-seed to Series A who need to know what is breaking before they decide what to fix. Each issue goes one layer deeper into the two operating systems your company runs on.
The full Bootloader Diagnostic — with pass/fail criteria for each layer — is in the Founder’s Stack Trace Field Guide.
If you would like a free copy, you can reach me at ayse@elvtadvisory.com
By Ayse Guvencer · ELVT Advisory
Top comments (0)