Why the next enterprise apps will be generated, not bought

The problem

Enterprise procurement is a machine built for a specific reality: software was expensive and slow to make, so the rational move was to buy it from someone who had already paid that cost. Everything downstream of that assumption — the RFP, the vendor shortlist, the security questionnaire, the multi-year contract, the seat-based license, the renewal — is optimized for a world where building was the expensive option and buying was the cheap one. The whole apparatus exists to de-risk a large, irreversible purchase of something you couldn't easily produce yourself.

That reality is ending, and procurement hasn't noticed yet. When a capable model can generate a working internal application — an intake system, an approval workflow, a tracker for whatever your business moves — in an afternoon, the economics that justified the buy-a-license reflex invert. The expensive option is no longer building. It's the eighteen-month procurement cycle you run to avoid building. Somewhere in the next few years, a growing share of enterprise software stops arriving as a signed contract and starts arriving as a generated app configured against a platform you already trust. The question is what that platform has to guarantee for that to be a responsible way to run a company, rather than a reckless one.

What procurement was actually buying

It's worth being honest about what a software purchase really was, because it was never just the features. When an enterprise bought a SaaS product, it was paying for a bundle: the functionality, yes, but also a set of guarantees the vendor absorbed on the buyer's behalf. That the data was isolated from other customers. That there was an audit trail if a regulator or an auditor came asking. That access could be scoped by role. That someone was patching the thing. That if it broke, there was a contract and a throat to choke.

Strip a typical internal enterprise app down and a surprising amount of it is generic — a form, a list, a status field, a report, an approval step. That part is now generatable. But the guarantees underneath it — isolation, audit, access control, a bounded and observable place to run — are exactly the part that a good prompt does not produce. This is the same relocation of value we described in the end of the CRUD app as a product: generation got cheap, but running software safely did not, so the value moved from the artifact to the substrate. For procurement, that means the thing worth vetting is no longer each individual app. It's the platform the apps run on.

Vet the platform, not the app

This is the shift that should reorganize how a serious buyer thinks. In the buy-a-license world, you ran a security review per product, because each product was a distinct vendor with distinct infrastructure and distinct risk. That doesn't scale to a world where your teams generate a new internal app every few weeks. You cannot run an eighteen-month vendor review on something that took an afternoon to produce; the review would cost a thousand times more than the app.

The answer isn't to skip the review — that way lies a data breach with your name on it. The answer is to move the review up a level. Vet the platform once, hard: does it enforce tenant isolation structurally, does it keep an immutable audit trail, does it bound what any given app can do regardless of who or what authored it, can it run where your data is legally required to stay. If the platform earns that trust, then each app generated against it inherits those guarantees by construction. You've replaced a per-app trust decision with a per-platform one, which is the only version of this that survives contact with the volume of software your organization is about to start generating.

Notice what this does to the RFP. The interesting questions are no longer "does the product have feature X" — you can generate feature X. The questions become "what can't an app on this platform do, even if it were actively hostile," and "can you prove, after the fact, exactly what any app did with our data." Those are governance questions, and they're the right ones.

How FastYoke approaches it

FastYoke was built around the idea that operational software is naturally described as data — states, transitions, guard conditions, field definitions. That turned out to give us exactly the properties a buyer needs to trust apps they generate rather than purchase, because we needed those same properties to safely run logic that tenants authored themselves.

A database per tenant, not a shared table. Isolation is the first thing procurement asks about, and in FastYoke it isn't a tenant_id column you trust every query to filter correctly. Each tenant's data lives in its own database. Two customers' records physically cannot cross paths regardless of what any generated app tries to do, because the boundary is the storage engine, not a filter someone hopes is applied everywhere.

An append-only audit ledger. Every state change a record makes lands in an event log — who did it, when, what changed — that is never edited and never deleted. Whether a transition fired because a person clicked or an automated actor drove it, the record is identical and permanent. When an auditor asks what a generated app did with regulated data last quarter, the answer is a query against an immutable ledger, not a reconstruction from logs someone hopes weren't rotated.

Every app runs inside an explicit state machine. Business logic isn't opaque control flow; it's a finite-state machine with named states and guarded transitions. A generated workflow is a graph a reviewer can render, inspect, and diff — you approve it by looking at it, not by reverse- engineering imperative code. That's what makes reviewing a generated app tractable at enterprise scale.

Logic runs in a sandbox, not as raw code. Nothing is interpreted as a raw string — guard conditions run through a declarative predicate evaluator, and heavier tenant scripts run inside a WebAssembly sandbox with a fuel budget, a memory ceiling, no inherited network sockets, and no filesystem. A generated rule's blast radius is capped by construction, so "an app we generated" can't become "an app that phoned home with our data." We wrote up that model in why FastYoke chose WebAssembly.

Apps install as data, and the UI comes from the schema. A marketplace app installs as rows — schemas, workflow definitions, seed records — into the tenant's own database, and the screens render dynamically from that same schema. Adding an app grants no new access to the host process, and there's no separate hand-built UI to drift out of sync.

One binary, deployed where your data must stay. FastYoke is a single Rust binary that runs identically in our cloud, in your own data center, or fully air-gapped. Data-residency and sovereignty requirements — the questions that used to sink a procurement cycle — become a deployment choice rather than a negotiation.

Vet those properties once, and every app your teams generate against them inherits them. That's the whole argument: the trust boundary moves from the contract to the platform.

What to watch out for

The failure mode here is euphoria. "We can generate our apps now" curdles fast into "so we skipped the review," and the platform-level guarantees are precisely what let you skip the per-app review without skipping governance altogether. If you adopt a runtime that doesn't enforce isolation, audit, and boundedness structurally, you haven't modernized procurement — you've just removed the vendor who used to absorb that risk and kept none of the protection. Regulated buyers should hold generated apps to a higher bar, not a lower one, because a model can't be interrogated about its choices the way a vendor's engineers can under a contract. The framework buyers already know from records law — the eIDAS Regulation, which makes electronic signatures and seals legally provable — is a useful reminder that the enduring value has always been provable guarantees around data, not the interface sitting on top of it.

There's also transition cost. Rewiring procurement from per-product contracts to platform governance is organizational work — legal, security, and finance all have muscle memory built for the old model. Budget for that change rather than expecting the tooling to force it.

Where to go next

If you're rethinking build-versus-buy for a world where generation is cheap, start with build vs. buy vs. configure and the companion argument in the end of the CRUD app as a product. To see the governance properties in context, take a look at regulated workflows or compare plans on pricing.