In 2025, Eastern Washington University asked to renew its Ellucian Banner contract without competitive bidding. A central part of the justification was what leaving would cost: comparable ERP replacements had taken three to four years and $14 million to $20 million, and EWU had more than 60 integrations tied to the system.
The cost of exit had become an argument for staying.
That is where many institutions sit with their vendors, and the budget pressure is not easing. Moody’s projects 3.5% revenue growth against 4.4% expense growth across higher education in 2026. In an EDUCAUSE QuickPoll, 42% of institutions expected IT budget cuts for 2025-26, with a median decrease of 8%.
Software is one of the least flexible lines in that budget. For years, the alternative was worse. That has changed.
The money and staff time freed by replacing vendor products should go to the people who hold institutional knowledge, and to the work our campuses have never had the capacity to reach.
Cheaper Code, Fewer Seats
Ten years ago, building our own meant a developer we probably couldn’t hire, a multi-year timeline, and a system that died when its one maintainer left. Buying was the rational default. Five years ago, low-code tools helped at the edges, but the math mostly held.
It doesn’t anymore.
With coding agents and current tooling, a small team can scope, build, test, and ship an internal tool in days or weeks. The same agents that write the code can document it, explain it to the next person, and help maintain it. Maintenance was always the strongest argument against building, and it is weaker now too.
We saw it firsthand at the University of Montana. We were paying a vendor every year for a status page, a simple tool with no sensitive data behind it. Our team built a working prototype during a single Vibe Friday, one of the recurring sessions we run to introduce people to AI. Getting it production ready took several more weeks of security review, accessibility work, and testing.
Then we dropped the subscription.
That ratio is the honest picture: the code is fast now, and the diligence still takes the time it takes.
Others are seeing the same thing. In a Retool survey of 817 of its own customers and builders, 35% said they had replaced at least one SaaS tool with a custom build. That is a vendor surveying its users, so discount the number.
The direction is real.
Pricing is shifting at the same time. In May I wrote that the agent shift is bigger than the SaaSpocalypse: seat-based pricing assumed people were the users, and agents break that assumption. Gartner now puts up to $234 billion in application spending, roughly 20% of SaaS by 2030, at risk from agents working across systems.
Building got cheaper while the case for renting got weaker. That combination is new.
The Risks on Both Sides
None of this means skipping the risk conversation. It means matching ambition to blast radius. Custom development is not free, and neither is dependence.
A status page is an easy call. An ERP is not, and I don’t think most of us are ready to build one. But when it takes more than thirty surrounding systems, many with custom modifications, to make ours work, it is fair to ask what that platform’s future looks like.
Vendor risk means escalators that outrun budgets, data lock-in, limited auditability, and exit costs high enough to skip competition entirely.
Custom risk is just as concrete:
- Sustainment. Someone has to own the tool in year three.
- Accessibility. Every custom interface is our own ADA Title II obligation.
- Security. AI-generated code needs review, and anything touching student records needs FERPA scrutiny.
- Shadow IT. The same Retool survey found 60% of builders had created tools outside IT oversight in the past year.
That number comes from a cross-industry survey, so treat it as a warning rather than a measure of higher ed. But building is already happening on our campuses, as the examples below show.
The question is whether it happens inside governance or around it.
Trading one dependency for another is the obvious failure mode. The durable position is an institutional layer for identity, authorization, logging, and data access that sits above multiple models and tools, with contracts that require portability and a clear exit.
Emerson and Michigan
Emerson College, a mid-sized school with fewer than thirty buildings, had a familiar help desk problem: locked-out alumni, contractors with no ERP record, former employees asking for old W-2s. Student workers couldn’t handle those tickets, so they went to senior administrators.
Starting in fall 2025, Emerson’s IT leaders used AI-assisted development to build a privileged access management system that integrates more than twenty applications, and they report $52,754 in avoided vendor costs in the first few months.
Seven applications are now live. The tooling cost little. The staff investment was substantial: the access system alone took hundreds of hours from someone who knew the operation. Emerson’s leaders are also candid that their review process can’t keep pace with how fast changes now happen, and they advise building the review framework before the first deployment.
The University of Michigan shows the same logic at research-university scale.
Its internal billing department replaced a legacy procurement tool that cost hundreds of thousands of dollars with one built on Maizey, the university’s own AI platform. The university reports the new tool’s annual cost at $62. CIO Ravi Pendse has stressed that the system is modular, so AI components can be swapped out as better ones arrive.
That is the detail worth copying: Michigan built something it can change without waiting on a vendor.
Where the Savings Should Go
The point of replacing software is to give people back the time they spend on repetitive work: chasing exceptions, re-keying data, answering the same question again.
At Emerson, student help desk staff now safely resolve requests that used to land on senior administrators, who can turn to harder problems. The authors describe AI as a translator rather than an author.
The people who understand the problem are still the scarce resource.
Replacements only work because staff define the requirements, catch wrong results, handle the exceptions, and adapt the tool as campus needs change. There is also a practical reason to protect them. The staff who know where the friction is will either surface the next process worth automating or keep it to themselves. If the first project’s savings show up as layoffs, they have every reason to stay quiet.
So reinvest on purpose.
Fund training for the staff whose work changes, budget for maintaining what you build, and put the rest toward campus projects that have sat on the backlog for years.
Buying used to be the safe default. AI has made building a real option again.
Use it to replace the software, and keep the people who understand our campuses. They’re the reason those replacements work, and they’re where the savings should go.
If I were a vendor, I’d be asking a hard question right now: what is my value when a customer can vibe code a replacement over a weekend? A good answer looks like dependable operation, support that actually helps, and capabilities we couldn’t afford to sustain ourselves. The vendors with that answer will keep their customers.
The rest are about to find out how many of their renewals were inertia.
