Higher education is talking about building software again, and the build vs. buy debate is back. Not big systems, at least not yet. Small apps, workflows, and AI agents that sit beside the student system and do the thing it never quite did: a transfer credit triage tool, or an agent that reads a degree audit and drafts the advising email.
AI coding tools made this cheap enough to try. A staff member with a decent prompt and a free afternoon can now produce something that five years ago needed a developer and a budget line. Vendors noticed, and their answer is a wave of low-code tools and agent builders that let institutions build too, as long as they build inside the vendor’s platform.
I spent years in the CIO chair at a small private university before moving to the analyst side, and this conversation gives me déjà vu. Higher education has run the build vs. buy cycle before, and we didn’t love how it ended. So the honest question is whether AI changes the math or just changes the tools.
Plenty of institutions ran homegrown student and finance systems through the 1980s and 1990s. A lot of them worked. They fit the institution because the institution built them, usually around a small team that knew every table and every workaround.
Most of them ended for reasons that had nothing to do with code quality. The people who understood them retired, and federal aid and tax reporting rules changed faster than two or three programmers could keep up. For some institutions, Y2K accelerated replacement decisions that had been easy to put off.
So we bought. Then we customized what we bought until it looked like what we’d replaced. Every modification had a defensible reason, and together they turned routine upgrades into multiyear projects. Some campuses ended up years behind their vendor’s current release, maintaining code nobody else in the world ran.
The move to the cloud was the correction: configure, don’t customize. Cloud platforms reduced how often institutions touched core code, but institution-specific extensions and modifications didn’t go away. Institutions gave up some fit in exchange for staying current, and many are still adjusting to that trade.
The cost of getting to a working prototype has dropped considerably. Work that took a developer a semester can now take a capable staff member a few days, and the person building it is often the person who understands the problem best. Additionally, the offices that never had a developer to ask often understand their processes better than anyone else on campus.
The build is also happening in a different place. Last time, institutions built or modified the system of record itself. Today most of the interesting work sits at the edges: the student-facing experience, a handoff between two offices, or an agent that reads from the student system and drafts something for a person to approve. Modern student and administrative systems expose APIs that the old ones rarely did, so you can build beside the core instead of inside it. If the integration layer is solid, that’s a healthier architecture than anything most of us ran in 2005.
The cost didn’t go away; it just moved. Building software got a lot cheaper, but owning it costs about what it always has, and ownership is where higher education has gotten into trouble before.
An app built in a week still needs someone to fix it in year three, after the person who built it has taken a job across town. AI-generated code adds a twist: sometimes nobody, including the person who prompted it, fully understands how it works. We used to worry about the one programmer who knew the system. Now we can produce systems that nobody knows.
Agents raise the stakes. A wrong dashboard is embarrassing. A wrong agent can send 4,000 students the wrong financial aid message before anyone notices, or write bad data back into the system of record. A weekend project that handles student data or supports student-facing services still has to meet applicable privacy, accessibility, security, and audit requirements. The development effort may be smaller, but the institutional obligations are not. They just tend to get skipped.
The instinct hasn’t changed either. The homegrown era and the customization era were both driven by institutions wanting software to match how they already work. AI makes it very easy to indulge that instinct again, one small app at a time. Fifty small apps can add up to the same tangle as one heavily modified system, and they’re much harder to inventory.
Vendors see the same opportunity, and they want the building to happen on their platforms.
Workday announced Workday Build in September 2025, including a low-code agent builder from its Flowise acquisition. Its CTO put it plainly: “The era of one-size-fits-all enterprise software is over.” In July, Oracle announced an AI-native builder experience for its AI Agent Studio that lets developers use tools like Claude Code and Codex to build agentic applications that run inside Fusion Applications. Ellucian’s examples look different. It launched Ellucian Student in April with embedded agents and a prescriptive, productized implementation approach. Separately, its Intelligent Processes tool lets nontechnical staff build no-code workflows for forms, tasks, and approvals. That’s workflow automation rather than the general agent-building tools Workday and Oracle describe, but the work still happens on Ellucian’s platform.
Read those announcements back to back and the pitch is consistent. Build whatever you need, as long as it runs on our platform, under our security model, against our data. Oracle says it directly, contrasting its approach with “disconnected AI automations” that bolt on controls later.
That’s a fair point and a self-interested one. Building inside the vendor’s runtime does solve real problems with identity, permissions, audit trails, and upgrades. It’s also different from old-style customization, which changed the vendor’s core code. Today’s extensions run through supported APIs, tools, and runtimes. But it still means your institution’s logic now lives in the vendor’s tool, in the vendor’s format. An agent built in one vendor’s studio may not move to another platform without significant rework, depending on its architecture and how much it relies on proprietary components rather than open standards. And we spent 20 years learning that customizations are what keep institutions on a platform long after they’d like to leave.
I don’t think that makes vendor builders a bad choice. Often they’re the right one. But let’s not call it “configure, don’t customize.” It’s a new kind of customization, with a cleaner upgrade path but many of the same long-term questions about ownership and platform dependency.
Build vs. buy was always a slightly false choice. Institutions increasingly have three options: use the vendor’s delivered functionality, extend it inside the vendor’s platform, or build independently with APIs, integration tools, and outside development tools. Each step down that list adds control, and each one adds complexity too. In-platform extensions deepen vendor dependency. Independent builds buy portability by putting all of the governance and support on the institution, which then has to maintain its own platform and the integrations between it and everything else. The real decision now is where the build lives and who owns it. These are the questions I’d want answered before anyone writes a prompt:
No. But we’ll repeat the past if we treat this as a technology decision instead of an ownership decision.
The homegrown era largely ended because institutions couldn’t sustain what they built. Heavy core customization fell out of favor when upgrade bills finally showed what all those modifications cost. AI lowers the cost of building and can make maintenance easier. It doesn’t make sustaining software free, and it doesn’t hand the responsibility to anyone else.
The institutions that come out of this well will build less than they could and own everything they build. The rest will be back in five years, trying to inventory agents nobody remembers deploying.
Originally posted by Matthew Winn on LinkedIn. Be sure to follow him there to catch all his great industry insights.
Share Article:
© Copyright 2026, The Tambellini Group. All Rights Reserved.
Get exclusive access to higher education analysts, rich research, premium publications, and advisory services.
