Becoming Viable — Viable Coder

01 Six Situations

Recognize yourself in any of these?

Most of the founders, leaders, and teams who reach out arrive in one of these six situations. Open the one that sounds like yours. The smaller tags at the bottom of each card name the long-game questions that situation raises — click any to see how it's defined and tracked on Remaining Viable.

Internal Talent Worth Developing A promising individual — or a small team of change-makers — already inside your company, who you'd rather develop into real product owners than replace by hiring outside.

The Situation

You have seen something in this person — or in two or three of them. Maybe this one is in customer support and keeps proposing better workflows. Maybe one is in operations and built an internal tool with AI that actually works. Maybe it's a self-taught generalist who keeps finding ways to be useful in roles that didn't exist before. Sometimes it's a single standout. Sometimes it's a small group of change-makers — the handful who, if developed, would shift how your company actually builds. You don't want to lose them to a bigger company that develops talent faster, and you don't want to keep paying outside vendors when the right rawness to own the work is already on your payroll.

Every outside engagement builds capability that leaves with the invoice — the gray line resets each time. The person you develop compounds instead, and crosses the rented peaks for good. The work is the transfer: real faculty moved into named people, without ownership dropping in the handoff.

The Fear Underneath

"I'll spend money on outside help again and still not have anyone internal who can own this. And eventually these people will leave because we didn't invest."

What You're After

A multiplier on people you already trust. Capability that stays inside the company. A clear, structured path that doesn't require your employee — or your small bench — to disappear into a bootcamp or quit to attend a program. You want to be the leader who developed someone, or a handful of someones. That's a meaningful identity.

Also raises long-game questions

Identity Vocational Differential

SaaS Vendor Dependency The operational stack your business runs on is rented from SaaS vendors — at rising prices, with a fit that never quite matches your workflow.

The Situation

Your operational stack is a portfolio of monthly subscriptions — CRM, billing, support, analytics, workflow. Each solves a real problem. Each charges more this year than last. Each shapes your workflow rather than fitting it. You watch the line items grow and wonder when the math turns — when the rent on someone else's general-purpose product exceeds the cost of building exactly the tool your team needs. The 2026 "SaaSpocalypse" framing in the press makes it sound binary. In your business it's a question of which subscription, which year, and what would replace it.

The rent compounds every renewal; what it costs an owner with agents to build and run the same slice keeps falling. Somewhere the two lines cross — quietly, one line item at a time, not the stack all at once. The audit is deciding which subscriptions have crossed, and which are commodities you keep renting on purpose.

The Fear Underneath

"I'm paying premium prices for software that doesn't fit, locked in by switching costs that compound every quarter. The longer I wait, the more I owe to the lock-in."

What You're After

A clear-eyed audit of which SaaS line items are insourceable now, which aren't, and what internal capability would have to exist to replace them. A staged path that doesn't require a "rip and replace" moment. The tailored fit and pricing leverage that comes from owning the tools you depend on.

Also raises long-game questions

Economic Judgment Differential

External Dev Dependency Your product is built by an outside agency or contractor. You pay for development without owning the capability.

The Situation

Your product lives at an outside shop. Every change is a negotiation. Every timeline is a hope. Every invoice is a small grief. The agency holds the keys, the context, and increasingly, the power. You built the company; someone else owns the engine.

Every invoice raises the top line. None of them raises the bottom one — the decisions about your product, and the answering for it, live on someone else's payroll. If the relationship ends, you keep the lower line. The work is moving origination and answerability back in-house without stalling the product on the way.

The Fear Underneath

"I don't actually own my product. If this vendor relationship ends, I have nothing."

What You're After

Control. Leverage. Sovereignty. The ability to say "we'll handle that internally" and mean it. To stop discovering pricing changes in invoices. To know — for the first time — what's possible without asking permission.

Also raises long-game questions

Differential Epistemic Economic

Legacy Software Debt Mission-critical software the original developers built years ago, and nobody currently on the team fully understands.

The Situation

The software runs your business. It works, mostly. But every change request feels riskier than it should. The team maintaining it inherited it from people who left. The documentation is partial. The knowledge is lossy. Every quarter brings a new "we should probably modernize this" conversation that gets tabled because the path forward is unclear and the risk of getting it wrong is enormous.

The system keeps carrying weight while the understanding walks out one departure at a time — the frame isn't abdicated, it's missing. The gap announces itself as fear: a change that should be small, and nobody who can say what depends on what. Comprehension can be rebuilt from the code itself — and that rebuild comes before any modernize, leave-alone, or replace decision, not after.

The Fear Underneath

"This codebase is a liability and nobody can touch it without breaking something. Eventually it will fail in a way we can't fix."

What You're After

First: stability. Second: an honest assessment of what you actually have, what's realistic to keep, and what isn't. Third: a path forward that doesn't require ripping everything out and starting over. You want clarity before action.

Also raises long-game questions

Epistemic Judgment Economic

AI Development Gap A developer team that hasn't made AI a deliberate, owned capability — whether through stalled adoption, evaluation paralysis, not having started, or shipping code with AI "blindly," faster than anyone can verify it.

The Situation

The gap shows up in two shapes, sometimes both in the same organization. The first is the team that hasn't moved. You have developers. Some bought Copilot seats. Some tried Cursor. Some haven't seriously evaluated any of it. None of you are operating AI-native — none of you are working meaningfully differently than you did three years ago. Meanwhile, every week brings another LinkedIn post from a competitor claiming 10x gains. You can't tell if those posts are real, exaggerated, or true and yours is the problem. You feel behind and don't know how far.

The second shape is the opposite-looking team that turns out to have the same gap. AI is producing plenty of working code. PRs land fast. The team looks like it's adopted. But you fear — and you're right to — that the code is being shipped without anyone fully verifying or explaining it. Velocity is up. Standing behind what shipped is down. Either way, AI is not yet an owned capability: either you haven't taken it up, or you've taken it up without owning the half that matters.

Two teams that look like opposites — one hasn't moved, one ships faster than anyone can read what shipped — and the gap is the same: the distance between AI in the workflow and AI as a capability you hold both ends of. Velocity isn't the measure; what you can stand behind is. The same kit reaches both shapes.

The Fear Underneath

"We're either falling behind in a way we can't measure, or we're racing ahead in a way we can't answer for. By the time either one shows up — in our financials, or in a customer-facing failure — it'll be too late."

What You're After

Competitive parity first. Genuine advantage second. You want someone who can look at your team — whichever shape you're in — and say, with credibility, "here's what's actually possible, here's what isn't, and here's what we'd need to change so you own the capability, not just the output." You are exhausted by hype and starved for honest specifics.

Also raises long-game questions

Differential Judgment Temporal

Prototype-to-Production Wall Built it on a no-code, low-code, or AI-assisted tool — in 2026 that means Lovable, Base44, Replit, Bubble, and their kin. It looks amazing. Demand showed up. Scaling is not happening — and you can feel the wall.

The Situation

You went into this thinking the new tools had removed the engineering time and cost from the equation. And in a way, they had. You built it — often in days or weeks, not months. It looks amazing. Real users showed up. Maybe revenue. Maybe enough revenue to quit your day job. And now you're staring at the gap between your Lovable build, your Base44 app, your Replit-spun service, or your Cursor-vibe-coded thing and what it would actually take to serve 10x the users, integrate with real systems, pass a security review, or be acquired. The prototype was the easy part. The thing underneath wasn't built to hold. You feel both proud and exposed.

The speed is real. So is the cliff — it arrives at the gates the platform never owned, all at once. Nothing is wrong with what you built; what's missing is the half of the lifecycle nobody sold you.

The Fear Underneath

"What I built isn't real. I'm one outage, one security question, one big customer away from being exposed."

What You're After

Legitimacy. The transformation from "I made a thing" to "I run a software business." You want to keep the speed you discovered but stop feeling like an imposter. A path that doesn't require throwing it all away and starting over with a traditional team.

Also raises long-game questions

Epistemic Identity Cognitive

These six situations aren't just how I sort inquiries — they're where the Playbook's configuration starts. And what configuration produces, you carry out: a kit mapped to your situation and your ambition, and a shop compiled to travel with you.

For founders, leaders, teams, and emerging builders crossing the threshold into AI-native product ownership.

Recognize yourself in any of these?

Three ways into this side.

Mentorship →

Resources →

The Playbook →

Recognize yourself in any of these?

Three ways into this side.

Mentorship →

Resources →

The Playbook →

Sign up for the newsletter.