Why Profitable Systems Can Still Have No Real Value

*Applying insights from **Good Strategy / Bad Strategy** to real-world software businesses*

Introduction: Profit Is Not the Same as Value

Many software founders proudly say:

“Our product makes money.”
Related Posts
NumPy Broadcasting Rules: Why `(3,)` and `(3,1)` Behave Differently — and When It Silently Gives Wrong Answers
What Tools Do AI Coding Assistants Actually Use? (Claude Code, Codex CLI, Aider)
Will AI Replace Software Development Agencies in 2026? The Brutal Truth for Enterprise Leaders
How to Build an Enterprise System Using Open-Source + AI (2026 Practical Guide)
AI-Powered Software Development — Built for Business, Not Just Code
Building an OCPP 1.6 Charging Platform A Practical Demo Guide for API, Dashboard, and Real EV Stations
Skill Evolution in Software Development (2026)

But Richard Rumelt, in Good Strategy / Bad Strategy, challenges this assumption with a powerful thought experiment — the famous “UFO machine” that produces $10 million per year.

The twist?

The machine may generate cash, but it has little strategic value once sold to another investor.

This idea is uncomfortable — and extremely relevant — for software businesses today.

The UFO Machine, Reframed for Software

Imagine this scenario:

A SaaS product earns $1M per year
It has customers and steady usage
Anyone with a similar team can rebuild it in 6–12 months

On paper, it looks valuable.

Strategically, it may not be.

Like the UFO machine, its profits exist without a defensible reason.

Why Profit Alone Is a Weak Signal

Traditional business thinking equates value with:

Revenue
Growth
EBITDA
Multiples

Rumelt argues that strategy asks a deeper question:

Why does this profit exist — and why hasn’t competition erased it?

If the answer is vague, the value is fragile.

Transferability Test: A Simple Value Filter

A powerful way to test real value is this:

Does the advantage survive a change of ownership?

If selling the software means:

Customers leave
Margins collapse
Differentiation disappears

Then the software was never the source of value — context was.

Boring Value vs. Interesting Value in Software

Boring Value

Generic CRUD SaaS
Feature-driven differentiation
Easily copied UX
Competes mainly on price

This is UFO-machine value: profitable but strategically thin.

Interesting Value (Rumelt’s Idea)

Interesting value comes from asymmetry:

Knowledge others lack
Position others cannot take
Frictions others cannot cross

In software, this often looks like:

Deep integration into operations
Accumulated domain-specific data
Workflow ownership
Regulatory or cultural specificity

Real Software Examples of Interesting Value

1. Embedded Workflow Software

Software that becomes part of how work is done:

MES inside factories
Accounting systems tied to local regulations
Industry-specific operational tools

Replacing it is painful — that pain is value.

2. Data That Improves the System

When usage creates data that:

Improves predictions
Refines workflows
Increases switching costs

The value compounds over time and cannot be sold as code alone.

3. Relationship-Centered Platforms

Some systems work because of:

Trust
Long-term support
Operational knowledge

The software is only one layer — the value lives in the relationship.

Why Many Profitable SaaS Still Struggle

Founders often optimize for:

Feature velocity
Short-term MRR
Investor narratives

Instead of:

Durable advantage
Strategic position
Long-term defensibility

The result?

A profitable product with no moat — easy to replace, easy to ignore.

graph LR
    A["Profitable System ≠ Strategic Value"]

    A --> B["Cash Flow"]
    B --> B1["Revenue"]
    B --> B2["EBITDA"]
    B --> B3["Short-term Profit"]

    A --> C["Boring Value"]
    C --> C1["Generic Software"]
    C --> C2["Copyable Features"]
    C --> C3["Price Competition"]
    C --> C4["UFO Machine"]

    A --> D["Interesting Value"]
    D --> D1["Asymmetry"]
    D1 --> D1a["Unique Knowledge"]
    D1 --> D1b["Unique Position"]
    D1 --> D1c["Unique Context"]

    D --> D2["Embedded Systems"]
    D2 --> D2a["Hardware + Software"]
    D2 --> D2b["Operational Workflow"]
    D2 --> D2c["Physical Constraints"]

    D --> D3["Data & Learning"]
    D3 --> D3a["Accumulated Data"]
    D3 --> D3b["System Improvement"]
    D3 --> D3c["Switching Cost"]

    D --> D4["Relationships"]
    D4 --> D4a["Trust"]
    D4 --> D4b["Long-term Support"]
    D4 --> D4c["Consulting Know-how"]

    A --> E["Strategy Test"]
    E --> E1["Transferability"]
    E1 --> E1a["Ownership Change"]
    E1 --> E1b["Does Advantage Survive?"]

    E --> E2["Defensibility"]
    E2 --> E2a["Moat"]
    E2 --> E2b["Friction"]
    E2 --> E2c["Replacement Pain"]