Skip to content
Pyrana
Resources
Business leadersEnterprise architectureAgentic applicationsBuild vs buy

Build, buy, or build on a platform

Software is not dead, but the case for buying a bespoke application for every workflow is dying, and so is the case for coding your own foundation. The architecture that holds up has four tiers, and most of the work your company does belongs in the one that did not exist two years ago.

Eric Tarnowski · Co-founder and President, Pyrana · October 15, 2026 · 9 min read

For twenty years the architecture question in every enterprise came down to two words. Build or buy. Buying won most of the time, because building was slow and expensive and the thing you built had to be maintained by people who kept leaving. The result is the estate most companies run today, a stack of purchased applications, one per workflow, stitched together with integrations and spreadsheets.

That frame broke this year. The market said so first. Between January 28 and early February, the S&P 500 software and services index lost about a trillion dollars of value, with an eight percent drop in a single week, after Anthropic shipped a set of plugins that let a general-purpose agent do work that companies pay seat licenses for (ACS Information Age, February 2026; Fortune, February 6, 2026). Traders called it the SaaSpocalypse. Satya Nadella had described the mechanism fourteen months earlier, saying that business applications are "essentially CRUD databases with a bunch of business logic," and that in the agent era the logic moves out of the application and into agents that do not care what the back end is (BG2 podcast, December 2024, as reported by ARN).

Software is not dead. Your general ledger is not going anywhere. But the value proposition for buying a bespoke application for every workflow and every analysis is dying, and the obvious alternative, coding it all yourself now that code is cheap, is worse. The real question has three answers now, and the architecture that holds up uses all three in the right places.

Buying four hundred tools does not scale

Start with the first bad answer, which is to keep buying. The average organization already runs 305 SaaS applications and spends 55.7 million dollars a year on them, according to Zylo's 2026 index of more than 40 million licenses. Torii's 2026 benchmark, which also counts what employees bring in themselves, puts the average large enterprise at 2,191 applications, with more than 61 percent of discovered applications outside formal IT oversight, and reports that AI tools are expanding shadow IT rather than consolidating it (CIO Dive, February 24, 2026).

Now add an AI-native vertical tool for every function. Each one arrives with its own identity model, its own permissions, its own audit trail, its own copy of your knowledge, and its own agent. I wrote about what that looks like at twelve agents in Twelve agents, twelve permission models. At four hundred it is not an estate. It is a liability nobody can inventory.

The instinct to go the other way is right, even when the execution overshoots. Klarna dropped Salesforce and Workday and stopped using around 1,200 small software services, and its CEO's stated reason was that the company wanted to consolidate its data in a way that was easier to feed into AI (TechCrunch, June 4, 2025). The company later walked back the headcount side of its AI push and began hiring people again for customer service. The data argument survived the walk-back. You cannot run agents over knowledge scattered across a thousand tools.

Vibe-coding your foundation does not scale either

The second bad answer is the one the selloff seemed to endorse. If the business logic is leaving the application, and an agent can write software in an afternoon, why not generate your own?

Because the demo is the easy part. Veracode tested more than 100 language models on 80 coding tasks and found they introduced a security vulnerability in 45 percent of cases, choosing the insecure method over the secure one when both were available, and larger models did no better (Veracode, July 30, 2025). In July 2025 a coding agent on Replit deleted a live production database during a declared code freeze, then reported that it had ignored an explicit instruction not to proceed without approval (Fortune, July 23, 2025). Those are not arguments against AI-assisted development. They are arguments against making generated code the foundation your company runs on.

The foundation is the part nobody sees in the demo. Identity and single sign-on, tenant isolation, authorization that follows the person into every data source, approvals that bind to the exact call that was approved, durable execution that survives a restart, an audit record written before the action, and a knowledge layer that remembers what each run was told. I listed that work in Component build vs. platform. Every team that vibe-codes an application has to build it again, and Gartner's prediction that more than 40 percent of agentic AI projects will be canceled by the end of 2027 names inadequate risk controls as one of the three reasons (Gartner, June 25, 2025).

The architecture that holds up

The target architecture I would draw for almost any enterprise today has four tiers.

A handful of systems of record. The general ledger, the HR system, the CRM of record, the order and inventory systems. These are transactional, regulated, and commoditized, and you buy them. Their job is to be the authoritative store, and the less custom logic they carry, the better.

A robust data layer. A warehouse or lakehouse where the systems of record land, with governance, lineage, and row-level security that reflect who a person is. This is the tier Klarna was reaching for. Agents are only as useful as the data they can reach and only as safe as the permissions that travel with it.

A platform for agentic applications. This is the tier that did not exist two years ago, and it is where most of your workflow and analysis use cases belong: the close, collections, procurement review, compliance monitoring, project reporting, content review, and the long tail of processes that today live in a purchased point tool or a spreadsheet. The platform supplies identity, authorization, audit, context, and the runtime once. Each application is configuration on top of it, with the business logic Nadella was talking about expressed as rules and knowledge instead of as code.

A handful of hyper-specialized vertical tools. Some domains have real moats. A vendor that has spent a decade accumulating regulatory submissions, clinical protocols, tax code, or litigation outcomes across hundreds of customers has knowledge and models you cannot reproduce by configuring an application over your own data. Buy those, and hold them to a short list: a domain body of knowledge you do not own, a workflow that is standard across the industry, and a compliance burden the vendor carries for you.

The test for which tier a use case belongs in is simple. If the value is in the record, buy a system of record. If the value is in your data, your rules, and your process, build the application on the platform. If the value is in a domain the vendor knows better than you ever will, buy the vertical tool. Build bespoke only when the software is the product you sell.

Most companies that run the test find the middle tier is far larger than their current estate admits. The purchased point tools were never bought because the workflow was special. They were bought because building was expensive. That constraint is gone, and so is the reason to keep paying for four hundred permission models.

Where Pyrana sits

Pyrana is the third tier. It is not a system of record and it is not a vertical tool. It is the platform on which a company delivers its own agentic applications. The hard part is already built, so each application is configuration rather than a rebuild of the fundamentals.

The platform connects to the first two tiers rather than replacing them. Tool sources cover REST, ODBC, MCP, Snowflake, Databricks, and document drives, each bound per agent with its own scope, so an application reads the ledger and the warehouse as the user who opened it. Identity comes from your SSO. Authorization is layered from tenant to App to access profile to scope. Approval policies evaluate the arguments of a call and freeze it for a named reviewer. Every run writes its audit event before it executes and records what knowledge was retrieved, injected, and cited. Where a client needs domain logic of its own, it ships an extension, a service of its own that the platform calls under the same identity and policy controls, which is how the bespoke cases get handled without becoming a bespoke foundation.

The economics follow from that. The App configuration for a new application takes about a week with clean data, the first application typically reaches production in about six weeks, and each one after that is faster because the foundation is already there. Pyrana runs as SaaS on a dedicated private tenant, or inside the client's own infrastructure for large enterprises. The hosting choice does not change the architecture.

What to do next week

Pull the application inventory, the real one including what finance pays for and what employees expensed, and sort every entry into the four tiers. Systems of record. Data layer. Workflow and analysis applications. Vertical tools with a real moat.

Then look at the third pile. Count how many of those applications exist to run a process over your own data under your own rules, and how many permission models, audit trails, and copies of your knowledge they add up to. That number is the cost of the old frame. The decision in front of you is not whether to build or buy. It is how much of that pile to move onto one platform, and how soon.

Sources

More for business leaders

Bring your hardest process.

We will run it through admission, approval, and the record, and show you what comes out.

Book a demoHow it works