TL;DR. The custom apps agent opportunity is the highest-leverage AI surface most mid-market companies own — and three modernization calls in the last 90 days pivoted the conversation to confirm it. Call it the migration paradox: a manufacturer was about to spend $300K. He was about to pay twice to give away the asset that made the business defensible. Three custom-app modernization conversations on our pipeline in the last 90 days pivoted the same way — buyers came in talking about EOL stacks and departing engineers, and left talking about MCP servers, A2A endpoints, and embedding their domain logic into agent workflows. The pattern is consistent enough to name: the custom application your team built because SaaS couldn’t do the thing — that exact application — is the highest-leverage AI surface you own. The 2026 rebuild conversation is no longer “modernize the legacy app.” It’s “rebuild the legacy app as an agent-native participant in your operations stack.” The buyers who see this first are getting a structural advantage that their SaaS-only competitors can’t catch up to.

---

A few weeks ago, I sat with the head of operations at a mid-market manufacturer. He pulled up his maintenance ledger — twelve years of work orders, failure modes, mean-time-between-failure curves, parts genealogies, technician notes — all of it accumulated inside a CMMS his team had built in-house, back when no commercial system would model their line the way they needed it modeled. He had a board mandate to migrate to an enterprise CMMS by year-end. The migration quote alone was north of $300K, before licensing.

Halfway through the conversation, he stopped and said, “I’m about to spend three hundred thousand dollars to give away twelve years of data we built ourselves. And then they’re going to charge me ninety grand a year forever to access it.”

That was the pivot.

I run sales conversations for many custom app rebuilds. In the last 90 days, three of them — including that one — followed the same arc. I’ve started calling it the pattern. The shorthand is the migration paradox. A buyer with a custom internal app is asked to pay hundreds of thousands of dollars to migrate to a SaaS. What they’re paying to migrate is the asset that made the business defensible in the first place. Then they pay a third party, forever, to lease it back to them in a form the third party controls.

In 2024, the answer to “should we migrate or rebuild?” was usually “rebuild.” Most shipped a 90-day spec-driven modernization for a third of the cost of the SaaS migration. That answer hasn’t changed. In the last quarter, though, the conversation moved beyond cost math. Each of the three buyers pivoted before I finished the diagnostic. They didn’t want to discuss modernization. They wanted to discuss MCP servers, A2A endpoints, and what it would take to make their custom app fit into their AI workflows. The migration paradox brought them in. The agent’s argument closed the discussion.

To tie these shifts together, the piece below is what I’ve been saying on each of those calls, written down.

The flip nobody named yet

The reason your custom app exists is the reason it’s now valuable.

Think about why the app got built in the first place. Five or eight years ago, someone—probably the same person across from me—looked at the SaaS market, found three vendors that covered 60-70% of the workflow, and did the math on what re-architecting the rest would require. They decided to build something custom instead. That decision was about uniqueness. Your business logic was sufficiently differentiated that nothing off the shelf fit, and the cost of forcing a fit was higher than building from scratch.

The custom app, then, is a literal record of where your operations differ from the market. The order-routing logic handles your specific carrier contracts. The approval flow respects your organizational hierarchy. The compliance check codes your industry’s edge cases. The pricing rule is yours alone, because no one else has your exact mix of channels and customer tiers. The custom app is your business’s unique IP rendered as code.

Now let’s consider what happens when we  layer 2026 on top of the foundation.t.

In November 2024, Anthropic released the Model Context Protocol (MCP). This open standard gives AI agents structured access to data and tools. By March 2025, OpenAI had adopted it. In April 2025, Google launched the A2A (Agent-to-Agent) protocol. This sits one layer above MCP and lets agents from different systems negotiate, delegate, and coordinate work directly. By late 2025, both protocols had been transferred to the Linux Foundation and had become the de facto industry standard for how AI agents read data, call tools, and coordinate.

What that means structurally: in 2026, every agentic workflow worth running depends on the tools the agent can call. The tools an agent can call determine what the agent can actually do. Generic tools — calendar, email, web search, a vanilla database — produce generic agent behavior. Tools that encode your business’s specific logic produce agents that do your business’s specific work.

You can see where this goes. The custom application that encodes your unique business logic is precisely the asset that, exposed through MCP and A2A, gives you an agent stack nobody else can copy. The same uniqueness that justified building the app five years ago is what makes it strategically valuable right now.

Most engineering leaders are still calling that app “tech debt.” They have it backward.

What the three buyers actually said

Anonymizing the specifics, here are the three conversations, distilled to their turning points.t.

Buyer 1 — manufacturing CMMS. The maintenance system from the opener. It was built in-house around 2013 because the commercial CMMS market couldn’t model their specific equipment hierarchy or capture the failure-mode taxonomy their reliability engineers had developed. It holds twelve years of operational data, structured the way their team thinks. The migration to the enterprise vendor was scoped at $300K plus $90K/year in licensing. It would also require a 9-month data-transformation project to fit their model into the vendor’s schema, losing fidelity in places where the vendor’s data model didn’t have a place for what they had. “I’d be paying to flatten our own thinking,” he said. The conversation turned on a single question: if they rebuild instead of migrate, can the predictive-maintenance agent the reliability team has been piloting actually talk to the model the engineers built, instead of a vendor’s generic equipment ontology? That’s where we left it. He’s running the comparison internally now.

Buyer 2 — education student services. The group had built a custom student information layer on a 2017-era Rails 4 codebase that sits in front of a Banner SIS. The buyer joined the rebuild discussion due to EOL pressure on Rails. Five minutes in, she pulled up a demo from a competing SIS vendor. “They’re showing me an AI advising agent,” she said. “It looks fine, but it can only see what they expose. If I rebuild ours, can the advising agent see all our actual prerequisites, cross-listings, and workflows? That’s where the value is.” Same pivot.

Buyer 3 — vertical SaaS internal admin. A customer-success and billing-ops admin app, Python 2 Django 1.11, 60K LOC. The CFO had told the buyer to consider a replacement because maintenance costs were creeping up. Halfway through the call, he stopped me. “Honestly, maintenance isn’t the real cost,” he said. “The real cost is a customer-success team of forty and an internal admin app that’s a black box to every AI tool we’re trying to use. If we rebuild this, I want our CSMs to send a Claude agent in there to do their work. Can we?”

Three industries. Three stacks. Three different forcing functions that got the conversation onto my calendar. One question they all converged on: If we’re going to rebuild this anyway, how do we rebuild it so an agent can do useful work inside it?

This question isn’t something I’m steering toward the buyers — it’s consistently coming from them.

What “agent-native” actually means in the rebuild

The technical mechanics aren’t particularly complicated. They’re architectural choices made at the start of the rebuild. They are not bolted on afterward.

Every domain capability ships as an MCP tool, not just an internal function. This approach makes each capability—inventory check, order placement, approval workflow, compliance verification—agent-native. Agents can directly introspect these tools, call them with structured arguments, and flexibly compose them with others, unlocking seamless automation. Internal teams stop writing one-off integrations against your app’s REST API. Instead, they simply point Claude or another agent at the MCP server. The agent handles integration and interaction autonomously, reducing manual effort and accelerating innovation.

A2A endpoints let your app join workflows spanning vendors and systems. Most teams haven’t internalized this yet. MCP makes your app a callable tool for agents. A2A turns your app into an agent peer that can negotiate, delegate, and coordinate directly. The CFO’s planning agent no longer requests data from your operations team. Instead, it queries your app’s A2A endpoint, which negotiates the answer in real time. The support agent at your customer’s vendor doesn’t email your team about order status. It hands off to your A2A endpoint and gets a structured response.

The data model and authorization layer are designed for agent access from day one. Permissioning, audit trails, rate-limiting, and provenance are first-class architectural concerns rather than retrofits. An agent calling your inventory tool has a clearer identity, a clearer scope, and a clearer audit trail than the human users you’ve spent ten years designing for.

The output of a rebuild done this way is an application usable by your team. It’s embeddable into agent workflows. The workflows that span your operations stack, your CFO’s planning agent, your support team’s automation, and your customers’ agents all route through your app as peers. That is a categorically different asset than the legacy custom app you started with. And it’s structurally impossible for any SaaS vendor to give you, because the data model and the domain logic that make it valuable are yours.

Why a SaaS replacement doesn’t reach this

The instinct in the room is usually, “Couldn’t we just buy a SaaS that does the same thing now?” The 2026 answer is: no, not really, and not for the reason buyers expect.

The SaaS market in 2026 is rapidly developing AI surfaces. Most major SaaS vendors have shipped some version of “ask AI” inside their product. Some are building MCP servers. A few have shipped them. None of them — zero, as of this week — has shipped a complete MCP-and-A2A surface that exposes the full operational scope of their product to an agent stack you control.

Why not? Because that would let you build an agent stack that orchestrates across multiple SaaS vendors without any one vendor at the center. The economic incentive of every SaaS vendor is the opposite of that — they want their AI surface to be the center of your workflow, not yours. The SaaS servers the MCP vendors ship will continue to expose the surface area the vendor decides is safe, with rate limits and authorization models the vendor chooses. That’s not the same architectural property as an MCP server you own.

If your roadmap depends on agent-native access to your domain logic — and after the three pivots above, I’d argue every mid-market roadmap should — waiting for SaaS vendors to give it to you is a structural bet against your own AI infrastructure.

The custom rebuild is the only path to an MCP and A2A surface you control. That’s not a feature you can add to a SaaS contract. It’s a property of code you own.

And the “just wrap it with MCP” shortcut doesn’t reach this either

There’s a second, more technical instinct that comes up later in the same conversation. Microsoft shipped App Service Easy MCP in January. Scalekit is writing about wrapping vs. rebuilding. The pitch is appealing: keep the legacy app where it is, slap an MCP wrapper around the existing REST API, and your agents can call it. No rebuild needed.

That works for a narrow set of cases. It does not work for the case where the three buyers were actually in.

A wrapper translates an existing REST API into MCP tool calls. The wrapper inherits whatever the underlying API was designed for — which, for a 2014-era custom app, was human users clicking through forms, not agents calling tools with structured arguments. The endpoint shapes are CRUD-y. The authorization model is session-based. The audit log records HTTP calls, not agent identities. The data model has fields that exist because the 2017 product manager wanted them on a screen, and missing fields that an agent now needs to reason about because the 2017 product manager hadn’t thought of them.

You can wrap that. The agent can call it. But the agent’s behavior degrades exactly as Rushi described in MCP Is Not a REST Wrapper: too many tools, each too granular, with the model spending most of its budget figuring out which to call. The wrap gives you a checkbox. It doesn’t give you the asset.

The rebuild is the only way to design tool boundaries that match the agent’s job, an authorization layer that grants agent identities the right scope, and a data model that records what the agent needs to know. Wrapping is a useful tactical move when the underlying app is already well-shaped for it. For most twelve-year-old custom apps, it isn’t.stom apps, it isn’t.

The cost calculation, revisited

Donatas, from the LoadSys team, wrote about the new rebuild-vs-SaaS math recently. The short version: spec-driven AI-assisted rebuilds now ship in 90 days for $80–150K, and AI agents handle the bulk of ongoing maintenance, so the five-year TCO comparison that used to favor SaaS for most internal apps now favors the rebuild.

The agent-opportunity variable makes that comparison more lopsided.

The previous calculation was: a rebuild gets you an app with lower five-year TCO than the SaaS equivalent. True, and a real result on its own.

The 2026 calculation adds: a rebuild gets you an app with lower five-year TCO than the SaaS equivalent, plus an MCP/A2A surface no SaaS will give you, plus the compounding value of using that surface across every internal agent workflow you’ll build over the next three years.

There’s no row on the SaaS comparison spreadsheet for, “and the rebuild becomes a strategic agent asset for the rest of the decade.” There should be.

Five signals your custom app is an agent opportunity

If three of these hold, your custom app is in the band where the agent-opportunity argument is decisive.

1. The app encodes business logic that the SaaS market hasn’t generalized. This is the original reason the custom app exists. If it’s still true, the logic is still yours — and the logic is exactly what makes the app valuable to an agent.
2. Your AI roadmap includes workflows that span your operations. Internal copilots, agent-orchestrated reporting, customer-facing AI surfaces that need live access to your data — anything where an agent needs to actually do the work, not just answer questions about it.
3. At least one team in your company has tried plugging an AI tool into the existing legacy app and given up. This is the smoking gun. The fact that the legacy app is opaque to agents is exactly the problem the rebuild solves. If somebody’s already hit that wall, your team is already ready to act.
4. The app is 20K-200K LOC on a 5–12-year-old stack. The sweet spot for a 90-day spec-driven rebuild. Above 200K, the spec itself becomes a multi-month engagement; below 20K, the rebuild is small enough that the agent argument is almost too easy.
5. A forcing function is firing. Talent loss, runtime EOL, insurance renewal, operational scale breaking — there’s a reason the rebuild conversation is on this quarter’s agenda. The agent-opportunity argument is the reason the rebuild conversation isn’t deferred for the fourth quarter in a row.

The three buyers in the last 90 days each had four or five of these. The pattern isn’t subtle.

What I’d do this week

If you read this and recognized your own custom app in three or more of those signals, the next step is a working specification — not a vendor pitch. A document that says, concretely: here’s what your rebuilt app does, here’s what its MCP surface exposes, here’s what its A2A endpoints negotiate, here’s the architecture, the implementation plan, and the cost.

We ship that as a fixed-price two-week Discovery Sprint — $2,500 — and you keep the spec, whether you proceed with us or not. If you do proceed, the Sprint credits will be applied to the rebuild fee. The rebuild itself is 90 days, $80–150K, fixed price, with 25% of the fee forfeited if we miss the deadline.

That’s the offer. The thing I’d want you to do this week, whether or not we ever talk, is open the custom app’s repo and ask one question: which of the things this app does would you want an agent to be able to do directly? List them. If the answer is “most of them,” your custom app is your best opportunity to be an agent. Three buyers in a row in different industries can’t all be wrong about that.

The buyers who get to this conclusion first will ship agent stacks that their SaaS-only competitors won’t be able to copy. The buyers who get their third shipment the same thing six months later. The buyers who don’t get there at all are the ones I’ll be having the same conversation with next May — except their CMMS migration will have already shipped, and the data will already be gone.

I’d rather you not be the one telling me that story next year.

---

FAQ

How do I know if my custom app’s logic is genuinely differentiated, or if we just over-built something a SaaS could do? Run the test from the original build decision in reverse. Take the top ten things the app does and ask: Is there a SaaS in 2026 that does all ten without a workflow change? If the answer is no on more than three of them, the logic is still differentiated. The most common failure mode in this self-assessment is over-counting items where the SaaS is “close enough” — the rebuild-vs-replace argument is unfortunately decided on those “close enough” items, because that’s where workflow re-architecture costs hide.

We’re already exposing some of our app’s data via REST API. Isn’t that the same as MCP? No. A REST API exposes endpoints; an MCP server exposes tools with structured schemas, typed arguments, typed responses, descriptions, and discovery metadata that an agent can reason about. The agent reads the MCP server’s tool list, decides which tool to call based on the user’s request, and composes calls across tools without being told which to use. A REST API requires a developer in the loop to write the integration. MCP servers don’t. That difference is the entire reason this works.

Does this apply to customer-facing custom apps or just internal ones? Both, but the internal-app case is structurally cleaner because the authorization model is simpler — your employees have known roles, your audit log is internal, and the A2A endpoints don’t have to negotiate identity across organizational boundaries. Customer-facing custom apps work too, but the A2A piece gets harder because you’re now negotiating with agents acting on behalf of users whose identity and authorization come from elsewhere. The three pivots in the last 90 days were all internal apps. Customer-facing pattern is real; the implementation discipline is heavier.

What does the MCP/A2A architecture add to the 90-day timeline? Structurally, very little, because the choice is made at spec time and the tools that ship with the rebuild are MCP-callable from the start. The data model is designed for agent access from day one rather than retrofitted, which means permissioning and audit trails are treated as first-class architectural concerns rather than bolted on later. The 90-day timeline holds. What changes is the spec — the Discovery Sprint includes the agent-surface design alongside the application design.

Can we rebuild and then add MCP later? You can, and many teams will. The architectural cost is materially higher than designing MCP-first, because the authorization model, data model, and tool boundaries are drawn for human users first and then redrawn for agents. In our delivery experience, retrofit work tends to fall in the 30–80% range of the original architectural cost, depending on how tightly coupled the original authorization model was — wider ranges in either direction are common. If you know the agent surface is on the roadmap, design for it now.get drawn for human users first and then re-drawn for agents. In our delivery experience, retrofit work tends to land in the 30–80% range of the original architectural cost, depending on how tightly coupled the original authorization model was — wider in either direction is common. If you know the agent surface is on the roadmap, design for it now.

---

What to read next

• Rebuild or Replace with SaaS? Why the Custom-App Calculation Changed in 2026 — the cost math for the 90-day rebuild.
• What Is Spec-Driven Development (and Why It’s Replacing Vibe Coding) — the methodology that makes a 90-day rebuild structurally possible.
• Modernization — the offer, with current pricing and a path to a Discovery Sprint.