AI-assisted development gives me a reason to reconsider which internal products are practical to build. The useful comparison starts with the capabilities a university actually needs and includes the work of keeping them running.
AI-assisted development gives me a reason to reconsider which internal products are practical to build. The useful comparison starts with the capabilities a university actually needs and includes the work of keeping them running.
This retrospective entry was prepared from an October 4 draft and first published on October 27, 2026. Its September archive placement is an editorial date.
This is part of the three areas of my university AI work.
I want to help university IT teams become internal software and product teams. They should be able to look at a workflow, decide what software would serve it well, and build and maintain that software when that is the right choice. Sometimes that should lead to canceling a contract.
AI-assisted development has changed which internal products I consider practical to build. That opens up a useful question for an institution already paying for software: what would we build if we started with the work people actually need to do?
Consider a hypothetical vendor with 1,000 features. A university uses 20 of them. Five other things it needs are missing, so it adds two more products. Now one workflow depends on three subscriptions.
The vendor might be fairly priced for all 1,000 features. The university still has a poor fit for the 25 it needs.
The scope changes when someone asks whether an internal team could replace the product. Recreating everything in the vendor's catalog would be a very different project from building those 25 capabilities reliably. I want the team to define the smaller project before dismissing it based on the size of the larger one.
Take a request workflow as an example. Someone submits a request, a staff member assigns it, another person approves it, and the requester receives an update. A manager needs to see what is waiting and where work is getting stuck. The team may also need an export, a record of changes, and a way to correct a mistake.
Writing those needs down makes the scope easier to examine. “Replace our platform” hides the decisions. “Let the assigned staff member correct a request without losing its history” gives us something specific to build and check.
The number 25 is illustrative. The useful exercise is finding the actual boundary of the product.
My work helping teams includes internal ticketing, CRM, email and SMS tools, design tools, dashboards, automation, and deployment. These are areas where I want teams to have more ability to shape the software around their work.
AI-assisted development makes me willing to consider builds I would previously have set aside. I can explore an implementation, revise it, and work through the details with more help. Whether a particular build makes financial sense still depends on its scope and what it will take to operate.
The decision should include the complete workflow. If three subscriptions are needed, compare the internal product with those three subscriptions and the work required to keep them connected. Include the staff time spent moving information, correcting mismatches, and explaining which system contains the current answer. Those costs need to be established for the institution; I would not assume them from a vendor's feature count.
A commercial product that fits well may remain the right choice. I want building to receive a serious evaluation alongside buying, extending, and integrating, with a scope small enough to understand.
There is also an important implementation distinction here. Using AI to help build a product does not require a model to perform every ordinary operation once it is running. A form can save a record through conventional application code. A permission check can follow explicit rules. A dashboard can query a database. We can use AI during development and still deliver software whose routine behavior is defined and testable.
Building the right 25 capabilities requires understanding why someone needs them.
I want an engineer to sit with the person doing the work and follow a request from beginning to end. Where do they copy information? What do they check before approving something? What happens when the request arrives incomplete? Which spreadsheet exists because the current software cannot answer a question?
That observation should affect the implementation. A request for another dashboard may turn out to be a need to identify overdue work. A new field may be compensating for an unclear status. Building the requested screen immediately can preserve the underlying problem.
An engineer developing product judgment should be able to describe whose problem a change solves, what can be left out, and how the team will tell whether the change helped. They should also be able to explain what a proposed feature adds to ongoing support. AI can help produce more code; the team still needs to choose which code is worth owning.
I want product managers to move closer to implementation too.
For a request tool, that could mean sketching the records it needs, understanding how users and requests relate, and following an API call from a form to a saved result. They should be able to ask what happens if the same submission arrives twice, a notification fails, or a user loses access while work is in progress.
A useful learning exercise would be to build a small prototype with AI assistance, inspect how it stores information, and review it with an engineer. Then write acceptance checks for the behavior people depend on. Can one department see another department's requests? Does changing an assignment preserve its history? What does the user see when saving fails?
The goal is to reduce the distance between an idea and an implementation both people understand. A product manager with some engineering fluency can make a more useful proposal. An engineer with product judgment can help improve it before the team invests in the wrong behavior.
Each month's set of projects we're bringing in-house represents at least $10,000 in additional annual contract savings once those transitions are complete. Some months' projects are considerably larger.
Right now, we're bringing more than $50,000 a year in contracts in-house by the end of 2026. These are planned contract transitions, rather than savings already realized. Development, hosting, support, security, migration, and maintenance still belong in the cost comparison.
An internal product needs a home after its first demonstration.
I would identify who maintains it, who answers support requests, and who can deploy a correction when the original builder is unavailable. The ownership plan should include hosting, monitoring, backups, dependency updates, and the time required for future changes. That belongs in the cost comparison from the start.
Access controls and security need concrete decisions: who can view or change each kind of record, how access is removed, and what information should be retained. Integration needs the same attention. If another system changes a field or becomes unavailable, the team needs a defined response.
Migration is part of the product work too. The team should know how existing records will move, how it will check their accuracy, and how users will continue working during the transition. Contract renewal and notice dates determine when a replacement could actually remove a subscription.
I would keep human review throughout this work. Let the people who handle the requests try realistic cases. Have engineers inspect the implementation and its tests. Check the workflow against the requirements before calling the replacement ready. A working demo is a useful point for review; the ownership and migration plan make it possible to move beyond that point.
If you are responsible for a university IT team, pick one workflow that currently runs across several products. List the subscriptions, the capabilities people actually use, the missing pieces, and the manual steps between systems.
Then define the smallest internal product that could handle that work reliably, including its support and maintenance. Compare that concrete product with what you have now. That is where I would start helping IT become a team that can build what the institution needs and cancel the contracts it can genuinely replace.
If you want help working through that comparison, get in touch with one workflow and the tools it depends on.