The Ghost in Your Stack

Why we're building the AI App Platform— and why every enterprise already has a shadow software problem they refuse to name

There's a piece of software running in your company right now that nobody owns.

It started as a spreadsheet. Someone in operations needed to track vendor onboarding, and Excel was the path of least resistance. Then a macro got bolted on. Then a sales engineer wrote a small Power Automate flow to email the spreadsheet to the legal team. Then someone — probably an intern who has since left — spun up a Zapier integration to push approvals into a Trello board nobody remembers granting permissions to.

Multiply that by a thousand. That's your stack.

We call this ghost software: applications that run real business processes, hold real customer data, make real decisions — and exist entirely outside the boundary of anything your security, compliance, or platform teams can see. They didn't show up on a procurement form. They don't have a runbook. They have no owner of record. And when the person who built them leaves, the institutional knowledge of how the thing actually works leaves with them.

The instinct, for two decades, has been to fight this with policy. Thou shalt not write shadow IT. All internal tools must go through the platform team. File a ticket. It hasn't worked. It will never work. The reason it hasn't worked is the reason we started building the App Factory Platform.

The economic case nobody wants to say out loud

The SaaS bubble is not popping. It is being slowly, deliberately exhaled.

Look at the public comps. Look at the multiples on workflow tools, project management suites, and internal collaboration platforms that were trading at thirty times revenue in 2021. Look at what Asana, Monday, and a dozen others are worth today. The market figured something out: a lot of what gets billed as SaaS is, structurally, just a hosted database with a form on top and a permissions table. It's commodity software wearing a subscription price tag.

That's not a critique of the founders who built those tools. They built useful things. But the next decade is going to be defined by a question their CFOs are already asking, even if their boards aren't:

Why are we paying $24 per seat per month for software that, functionally, our own engineers could replicate in a sprint — if only we had a safe way to let them?

The answer, until now, has been: because building it yourself is more expensive than the license. That math is changing. Generative AI hasn't quite collapsed the cost of writing software to zero, but it has collapsed the cost of writing the boring 80% of software — the CRUD, the forms, the role checks, the audit logs, the export-to-CSV button — to something close enough to zero that the calculus inverts.

The bottleneck is no longer can we build it. The bottleneck is can we build it without it becoming the next ghost.

The two failure modes

Every attempt to solve this has fallen into one of two ditches.

On one side: low-code platforms. Powerful, opinionated, governable — and intolerable to anyone who has ever written real software. You hit the limits of the visual builder around day three. The "extensibility" story is always a custom JavaScript snippet in a textarea, with no version control, no real debugger, and a runtime you can't reproduce locally. Low-code makes the easy things slightly easier and the medium things impossible.

On the other side: vibe coding. A developer with Cursor, a Claude tab, and a cloud account can produce a functioning internal app in an afternoon. The output is real software — actual code, in a real framework, deployable anywhere. But there's no platform around it. No tenant isolation. No identity federation. No row-level security. No audit log. No approval workflow. No way for the CISO to answer the question "who has access to customer PII through this tool?" without auditing every commit by hand.

One produces software you can govern but nobody wants to use. The other produces software people love but nobody can govern.

The App Factory Platform is the thesis that this is a false choice. That the right primitive is a governed runtime for AI-generated applications — a platform that lets developers (and, eventually, operators) describe what they need in natural language, and produces real .NET applications, deployed into a tenant-isolated runtime, with identity, RLS, audit, and approval workflows baked into the substrate rather than bolted on at the end.

What we mean by governance

When platform teams hear "governance," they hear committee meetings. When CISOs hear it, they hear control matrix. When developers hear it, they hear the thing that will slow me down.

We mean something more specific, and more architectural. Governance, in the App Factory model, is a four-layer gateway that every change — every generated app, every schema migration, every deployment — must pass through:

• A Risk Engine that scores the blast radius of a proposed change. A new read-only dashboard is not the same risk as a new write path into the customer table.
• A Policy Engine that encodes the rules of your organization — data residency, retention, separation of duties — as evaluable predicates, not PDFs.
• An Approval Engine that routes decisions to the right humans, with the right context, at the right time. Not every change needs a human. The ones that do, get one.
• An Authority Engine that determines, at the moment of execution, whether the agent or operator on the other end of the request actually has the right to do what they're trying to do.

None of these are novel as concepts. What's novel is the claim that they belong inside the codegen loop, not on top of it. The agent that writes the code is the same agent that consults the gateway before writing it. Governance is not a deployment-time afterthought; it is a generation-time constraint.

This is the part of the architecture that we believe will look obvious in five years and looks strange today.

Why agents, and why now

There is a fork in the road right now in enterprise software automation, and the industry has not yet decided which path it's on.

Path A: deterministic workflow automation. Connect SaaS A to SaaS B with classical API plumbing. Zapier, Workato, n8n, the workflow tier of Salesforce. Predictable, debuggable, brittle. You can prove what it does. You cannot easily extend it.

Path B: agentic execution. A reasoning loop that picks tools, plans steps, and recovers from failures. Powerful, flexible, opaque. You can describe what you want in English. You cannot, today, prove what it will actually do.

The App Factory bet is that the right answer is both, behind a single governance plane. Deterministic when determinism is what you need. Agentic when the work doesn't fit a flowchart. And — this is the part that matters — the same policy, identity, and audit substrate underneath either path, so the CISO doesn't have to learn two control models.

We think of the platform less as a code generator and more as an MCP governance proxy: every tool the agent can invoke, every API the generated app exposes, every data path that flows through it — all of it goes through one place where access can be denied, redacted, logged, and explained.

What this series is going to be

This is the first piece in a series. The intent over the coming months is to walk through, in order:

1. The ghost software problem and the economic case for governed self-service. (This piece.)
2. The platform topology — Organization, Tenant, Workspace, and why those words mean something specific.
3. The agent pipeline — Orchestrator, Primary Agents, Hidden Agents, and the artifact-based contract between them.
4. The four-layer governance gateway — what it actually checks, and what it lets through.
5. The runtime — AssemblyLoadContext isolation, hot-swap, resource watchdogs, and why we build on .NET instead of Node.
6. The memory architecture — four-layer taxonomy, RRF fusion, and why "what the agent remembers" is a governance question.
7. The MCP proxy thesis — turning every internal app into a governed, agent-callable surface.
8. The economics of build-vs-buy — when the App Factory replaces a SaaS line item and when it doesn't.

Some of these will be technical. Some will be strategic. The intent is not to publish a marketing document and not to publish a research paper, but to write honestly about a thesis we're committing real engineering years to — and to do it publicly, in the open, with the assumption that you'll push back.

The wager

The wager is simple. Pick whichever framing lands for you:

• For the CTO: you are going to be asked, in the next budget cycle, why you're spending eight figures on a portfolio of SaaS tools that your engineers could replicate. The answer "because we can't govern the alternative" is going to stop being acceptable.
• For the architect: the right primitive isn't a low-code builder and isn't a chat-to-code IDE. It's a control plane that treats AI-generated software as a first-class artifact and governs it the way you'd govern any other production code path.
• For the developer: the ghost software in your company exists because the official path to building internal tools is too slow. Make the official path the fast path. The shadow goes away on its own.
• For the investor: the displacement opportunity in the next SaaS cycle is not "build a better Asana." It's the platform layer that lets enterprises stop buying Asana.

The AI App Platform is our bet on what that platform layer looks like. The next post in this series digs into the topology — why we model the world as Organization → Tenant → Workspace, and what each of those means when an agent is writing code on your behalf.

If any of this resonates — or, more usefully, if any of it strikes you as wrong — say so. The whole point of writing in public is to find out where the thesis is weak before the architecture commits to it.