The Developer Who Built It Left Three Years Ago: University Homegrown Software’s Knowledge Crisis

Three years ago, a developer at a regional university built a grants management tool. It tracked pre-award submissions, connected to the finance system, and generated compliance reports that the research office needed for federal audits. Everyone was grateful. The developer moved on to a better-paying position at a tech company. And the system kept running.

It’s still running today. Nobody on staff knows how.

That scenario isn’t unusual. Across U.S. universities, research offices run grant submission workflows, IRB tracking tools, compliance dashboards, and finance integrations built by developers who left years ago. The systems work until they don’t, and nobody can predict which day that is.

This is the knowledge crisis at the center of the research administration legacy system problem. It’s not a technology failure. It’s an institutional knowledge failure that lives inside technology.

When the Last Person Who Understood the System Walks Out the Door

One resignation can make a critical system untouchable. That’s the operational reality Research Directors and COOs at regional universities face, and it rarely shows up in any risk register until the moment it becomes a crisis.

The bus factor of 1: why universities are one resignation away from crisis

The term “bus factor” refers to how many people on a project could leave before the project collapses. A bus factor of 1 means one person holds all of the knowledge. Most university homegrown systems have a bus factor of 1 by default, because they were built by one person, maintained by one person, and never formally documented.

ClearlyAcquired’s 2026 analysis puts the replacement cost for high-level technical talent at 150 to 400 percent of annual salary, with project delays of six to twelve months while the replacement gets up to speed. For a university IT department already stretched thin, that’s not a budget line item. It’s a budget emergency.

The person who leaves doesn’t take any files with them. They take the context. Why is that field named the way it is? Why does the batch job run at 2 a.m. on Tuesdays? Why does the finance system integration require a manual workaround every March? That knowledge doesn’t exist anywhere else.

A research administration system dashboard showing active grants and compliance status, the kind of workflow-specific tool that accumulates unwritten rules with every passing year.

The documentation problem: when the system IS the institutional knowledge

Most homegrown research administration systems weren’t built with documentation as a deliverable. They were built under a deadline, by someone who understood the domain well enough that writing it down felt redundant. The system was the documentation.

Three years later, the system is still the documentation. And nobody on staff can read it.

This isn’t a criticism of the developer who built it. It’s a structural failure of the development model: when documentation is treated as optional rather than as a core deliverable, institutional knowledge concentrates in one person and stays there until that person leaves. No formal process, no offboarding checklist, and no knowledge transfer session changed that outcome.

[INTERNAL_LINK: anchor text “bus factor and knowledge loss” → /blog/institutional-knowledge-loss-software-development]

How Universities End Up Here: The Lifecycle of a Homegrown System

Every problematic homegrown system started as a good idea. Understanding the lifecycle makes the problem clearer and the solution more honest.

Built for a specific need, by a specific person, at a specific moment

The grants management tool, the IRB submission tracker, the post-award compliance dashboard, these systems were built because a gap existed. The commercial tools didn’t fit the institution’s specific workflow. The IT department had a developer with capacity. The research office had a specific pain point. The system was scoped tightly, delivered quickly, and it worked.

Nobody planned for it to become critical infrastructure. But workflows built around a working system become dependent on it. Staff learn the quirks. Other systems start referencing its data. Three years pass. Now it processes $4 million in annual grant submissions, and nobody seriously considers turning it off.

Three years of patches, workarounds, and unwritten rules

Systems don’t stay static. Funder requirements change, federal reporting formats shift, and institutional workflows evolve. Each change produces a patch. Each patch produces an assumption that gets encoded into the system without documentation. Each undocumented assumption becomes a rule known only to the developer.

By year three, the system runs on accumulated workarounds. The developer who built it understood the original design, stayed current with each patch, and held all of it in working memory. When they left, the system’s mental model left too. What remains is a working system that nobody can explain.

Diagram showing how a homegrown system accumulates technical and knowledge debt over time as developers cycle through and documentation remains absent.

The Real Cost: What Happens When Nobody Knows How It Works

The system still runs, so the cost is invisible. Research Directors focus on grant deadlines. COOs focus on budget cycles. IT Directors focus on keeping everything running. Nobody has time to audit the risk exposure of a system that hasn’t broken yet.

Then it breaks.

Financial challenges: maintenance spirals when tribal knowledge disappears

When the person who knows the system leaves and a problem surfaces, the repair cost is disproportionate to the actual issue. A bug that would have taken the original developer two hours to fix takes a contractor two weeks to diagnose, because the contractor has to reverse-engineer the architecture before they can touch it.

Williams College CIO Barron Koralesky noted publicly that maintaining PeopleSoft alone costs approximately $500,000 per year at his institution, and that figure excludes side systems and personnel. A homegrown system doesn’t carry a licensing fee, but the maintenance cost can quickly reach comparable levels when tribal knowledge disappears, especially if it takes repeated contractor engagements to address issues the original developer would have resolved in an afternoon.

Compliance and security risks that auditors start asking about

Federal grant compliance requires that systems handling award data meet specific security and audit standards. A system nobody fully understands is a system nobody can verify meets those standards. When an auditor asks how data integrity is maintained in the grants management workflow, “the system handles it” isn’t an answer.

ListedTech’s 2026 IT strategic landscape report found that 25 to 40 percent of universities are actively replacing or modernizing core platforms annually, with an average system age of ten years. The urgency isn’t sentimental. Systems at that age carry known security vulnerabilities, use outdated dependency versions, and increasingly fall outside compliance tolerances for federal data handling.

Research administration bottlenecks that block grant cycles

The most immediate operational consequence isn’t a security audit. It’s a grant cycle that stops moving. When the system can’t generate a required report format because the underlying data structure changed in a patch nobody documented, the Research Director can’t submit on time. When the post-award compliance dashboard can’t reconcile against the updated finance system because nobody knows where the integration logic lives, the sponsored programs office runs the reconciliation manually in a spreadsheet.

These bottlenecks don’t show up in IT incident logs. They show up in the Research Director workload, in late submissions, and in grant administrators spending two days per month on data entry that should take twenty minutes.

Technical debt cost at your institution

Why Replacing It with a Vendor Doesn’t Solve the Problem

The instinct, once the risk becomes visible, is to buy something. Cayuse. Kuali. InfoReady. A platform built by a company whose entire business is research administration software. That’s a reasonable instinct. It’s also the wrong conclusion.

How ERP migrations create a new knowledge dependency at 10x the cost

The knowledge dependency problem doesn’t disappear when you buy a vendor platform. It migrates from your developer’s head to the vendor’s configuration team. Now your institution’s specific workflows, compliance rules, and integration requirements live in a configuration that your staff didn’t build, in a system your IT team can’t modify, maintained by a company whose priorities aren’t your grant cycle.

Moran Technology Consulting has documented that Ellucian has raised Banner maintenance fees at 3 to 5 times the rate of inflation. That’s not a vendor being exploitative. That’s a vendor knowing their customers have no practical alternative once implementation is complete, because the institutional knowledge of how the system was configured to match your workflows now lives inside the vendor’s platform.

Ellucian reported 26 SaaS go-lives in Q1 2026, the highest number in a single quarter in company history. The migration wave is real. The question for any Research Director or COO evaluating it is: who owns the knowledge of how this system works for your institution once the implementation team goes home?

The configuration-vs-customization trap in research administration platforms

Vendor platforms work well for institutions with standard workflows. If your grants process matches the template, the platform is a good fit. Most regional universities have workflows that don’t match the template. They have fifteen-year relationships with specific program officers, compliance requirements from funders who don’t follow federal standards, and reporting formats that evolved from relationships, not from best-practice guides.

When your workflow doesn’t match the platform’s configuration options, you have two choices: modify the workflow to fit the platform, or customize the platform to fit the workflow. The first option disrupts how your research office operates. The second creates exactly the kind of undocumented dependency you were trying to escape, except now it costs $200,000 per year in licensing to maintain it.

Side-by-side comparison of a homegrown system dependency and a vendor platform dependency, showing both paths converge on the same key-person knowledge concentration problem.

What Universities Are Doing Instead: The Middle Path

There’s a third option that nobody in this space is writing about. It’s not “keep the broken system running,” and it’s not “buy the $800,000 platform.” It’s custom-built systems scoped precisely to the institution’s actual workflows, delivered with complete documentation transfer, and maintained through an ongoing embedded partnership that outlasts individual developers.

Documentation-first development: the system and its manual are built together

The root cause of the knowledge crisis isn’t the existence of homegrown systems. It’s that they were built without documentation as a deliverable. Fix the documentation requirement, and you fix the knowledge concentration problem at the source.

Documentation-first development means UML architecture diagrams, system design documents, API references, user story libraries, and test coverage reports are produced alongside the code, not as an afterthought after delivery, and not as a contractual formality. They’re part of every sprint. When a developer leaves, the documentation stays. Not because the developer was disciplined, but because the development process made documentation unavoidable.

The documentation belongs to the institution, unconditionally, from the moment it’s produced. Not licensed to the institution. Not hosted in the vendor’s portal. Owned, transferred, and stored by the institution itself.

Embedded partnerships that outlast individual developers

The second structural fix is an ongoing embedded partnership with an external development team rather than a one-time build. The difference matters for one reason: knowledge compounds over time.

An embedded partner who has worked on your research administration system for two years understands why the batch reconciliation runs on a specific schedule, what the finance integration expects, and which reporting fields get queried by your federal reporting template. That accumulated context doesn’t live in one person’s head. It lives in the documentation, in the team’s institutional history, and in the ongoing partnership relationship.

When a Nexa Devs engineer transitions off a project, the documentation they produced transfers to the next engineer. The knowledge doesn’t reset.

“As Ashwin Ballal, CIO at Freshworks, states: ‘The first thing we should be doing when adding a new vendor is to ask, are we adding to the problem or solving it? Adding vendors, data sources, systems, and custom configurations compounds complexity. It doesn’t reduce it.'”

The embedded partnership model doesn’t add to the complexity. It absorbs it over time.

What a 10-year research computing partnership looks like in practice

The UCLA David Geffen School of Medicine research computing team has worked with Nexa Devs for more than ten years. That’s not a testimonial about a software delivery. It’s a statement about what an embedded engineering partnership looks like when it works at institutional scale.

10 years means the partnership has outlasted 4 or 5 internal hiring cycles. It means the system knowledge accumulated in that partnership is deeper than any individual staff member’s knowledge, because the partnership’s institutional memory doesn’t reset when a staff member moves on. It means UCLA’s research computing systems have continued to evolve, integrate new requirements, and adapt to institutional changes without starting from scratch.

UNED, Europe’s largest distance learning university, operates at a scale that requires exactly this kind of embedded engineering continuity. Custom systems built for a student population of hundreds of thousands can’t be maintained through a one-time vendor engagement.

These aren’t edge cases. They’re the model.

How an embedded development partnership works

Modernizing Without Losing What You Built: A Framework for Universities

For universities that already have homegrown systems running critical research administration workflows, a complete rebuild is rarely the right starting point. The institutional logic embedded in those systems, the workflows, the compliance rules, the integration behaviors, represents years of accumulated decision-making. You don’t rebuild it. You preserve it while modernizing around it.

Phased modernization that preserves institutional logic

Phase one is documentation recovery. Before touching the code, map what exists: architecture diagrams, data flow documentation, integration dependencies, and a plain-language explanation of what each component does. This phase alone substantially reduces the knowledge concentration risk, because it externalizes what was previously held only in the codebase.

Phase two is selective modernization. Not everything needs to change at once. The components most likely to create security or compliance exposure get addressed first. The integrations that have accumulated the most undocumented patches get cleaned up next. Components that still function correctly get left alone.

Phase three is capability expansion. With a documented, partially modernized system, adding new capabilities, AI-assisted grant matching, automated compliance reporting, and real-time finance integration becomes a design conversation rather than a guessing game. You know what you’re building on.

Integration with modern solutions without a full rip-and-replace

The EDUCAUSE/GovTech 2023 survey found that nearly half of responding institutions had recently undergone an ERP upgrade, were mid-upgrade, or planned one within five years. That migration wave doesn’t have to mean replacing every homegrown system at the same time.

Modern API design makes it possible for a well-documented homegrown system to integrate with new platforms rather than being replaced by them. If your institution purchases a new finance ERP, a properly documented grants management tool can connect to it through an API layer without requiring a system rebuild. The institutional logic stays. The integration point updates.

The condition for that integration path to work is documentation. Without knowing what the grants management tool actually does internally, building a clean integration point is impossible. That’s why documentation recovery comes first.

Phased modernization roadmap for a university research administration system, showing documentation recovery, selective modernization, and capability expansion as sequential phases.

How to Evaluate Whether Your Homegrown System Is a Risk or an Asset

COOs and IT Directors don’t need a six-month technology audit to identify knowledge risk. Three questions and an afternoon are enough to get a clear picture.

Signs your system has a bus factor problem

Ask your IT Director these questions about each critical research administration system:

1. If the person who knows this system best leaves tomorrow, could we resolve a production issue within 48 hours without having to call them?
2. Does documentation exist that describes why the system works the way it does, not just what it does?
3. Has any new developer been successfully onboarded to this system in the past 12 months?

A “no” answer to any of these is a bus factor warning sign. Two “no” answers mean the system has a single point of failure. Three “no” answers mean the system’s continuity depends entirely on one person’s continued employment.

The documentation audit: three questions to ask before anyone else leaves

Before the next developer, IT director, or research systems administrator at your institution gives notice, run a documentation audit on each critical system:

• Architecture documentation: Does a diagram exist showing what systems this one connects to, and what data flows between them?
• Business logic documentation: Are the rules the system applies to grant submissions, compliance checks, or financial reconciliations written down anywhere outside the code?
• Recovery documentation: If this system failed at 10 p.m. before a federal report submission deadline, could someone who didn’t build it restore it to working order?

If the honest answer to any of these is “no” or “probably not,” the institution is carrying knowledge risk that belongs on a board-level agenda, not an IT to-do list.

The goal isn’t to create a documentation project as a remediation task. The goal is to change the development model so documentation is produced alongside code from the start. That change requires a different kind of development partnership than the one that produced the current system.

What documentation-first development looks like