I've spent much of my career in higher education technology helping institutions figure out how to solve problems.
For a long time, the build versus buy decision was fairly straightforward. If we needed something, we looked for a product that could do it. We evaluated options, reviewed costs, considered integrations, and made a decision. Building something ourselves was always an option, but usually not the first one.
There were good reasons for that. Building software takes time, talent, and resources. Then you have to maintain it.
But I'm beginning to wonder how much of that thinking still holds true.
AI is changing what's possible, and I find myself asking questions that I wouldn't have seriously considered even a year or two ago.
What if some of the things we've always purchased could now be built by our own teams? What if we could create something that fits our needs better, in a fraction of the time? What if the cost of experimenting with an idea is becoming so small that we can afford to explore possibilities we previously would have dismissed?
And perhaps the more interesting question is, what would we do differently if we weren't constrained by the same assumptions we've had for the last 20 years?
A couple of experiences got me thinking
At Doane University, we've been experimenting with AI-assisted development.
One of our developers recently built an application that addressed a need we had been considering spending approximately $50,000 to solve.
That got my attention.
Not just the potential savings, although those are certainly meaningful. It was how quickly the conversation changed. Something that would traditionally have sent us down a purchasing path became something we could potentially solve ourselves.
It made me wonder how many other opportunities like that are sitting right in front of us.
I was also talking with Tom Peters about some of the work happening at his institution. He shared an example of an employee who had built something that was essentially a configuration management database (CMDB) on steroids.
Think about that for a moment.
Here's an employee who saw a need and was able to create something remarkably capable.
I don't know that we would have approached either of these situations the same way a few years ago.
And that's what fascinates me.
How many talented people across our institutions have ideas that have never gone anywhere because the cost or complexity of building something was too high?
What happens when that barrier starts to come down?
Maybe we're asking the wrong question
At Doane, our team has been working through how AI fits into our university's strategic plan.
One of the things we've been intentional about is not creating a separate AI strategy that competes with everything else we're trying to accomplish.
Our strategic plan already tells us where we're going. AI is one of the capabilities that may help us get there.
That framing has changed how I think about this conversation.
Rather than starting with what AI can do, we're trying to start with what we're actually trying to accomplish.
Can we improve the student experience? Can we make work easier for faculty and staff? Can we eliminate repetitive tasks? Can we improve the quality and speed of our work? Can we give people more time to focus on things that require their expertise, creativity, and relationships?
And where might AI help us do those things?
That brings me back to build versus buy.
Maybe the first question shouldn't be whether we should build or purchase something.
Maybe it should be whether we're solving the right problem in the first place.
I've seen plenty of situations where we've purchased technology to support a process without really questioning whether the process itself made sense.
What if AI gives us an opportunity to rethink the work, rather than just automate what we've always done?
What are we really buying?
I keep coming back to this question.
When we purchase software, we're not just buying functionality. We're buying expertise, ongoing development, security, support, and the ability to depend on someone else to keep it running.
There's real value in that.
But we're also making a commitment. We take on licensing costs, contracts, integration requirements, and sometimes limitations that shape how our institutions operate.
Building something ourselves creates a different set of commitments.
We may have more flexibility and control, but we also own what we create. Someone has to maintain it, secure it, document it, and support it.
AI may dramatically reduce the effort required to create an application. I'm not convinced it reduces all the responsibilities that come afterward.
So how do we think about the entire lifecycle of something we're building?
How do we make sure we're not creating a collection of applications that nobody understands or can maintain five years from now?
And how do we recognize the situations where a commercial solution is still clearly the better choice?
I don't have all those answers.
But I think they're becoming increasingly important questions.
What does this mean for our people?
This may be the part I'm most interested in.
We have incredibly talented people working at our colleges and universities. They understand the problems, the frustrations, and the opportunities in ways that someone outside the institution often cannot.
Historically, having a great idea didn't necessarily mean having the ability to do something about it.
Maybe that's changing.
What happens when someone who understands a problem can work with a developer and build a solution in days or weeks instead of waiting months or years?
What happens when a small technology team can accomplish things that previously required a much larger development effort?
And how might that change the way we think about the capacity of our institutions?
In our AI strategy work at Doane, we've talked quite a bit about expanding human and institutional capacity.
I like that framing.
Of course we need to be responsible with our financial resources. But I don't want us to overlook the opportunity to help our people accomplish more, improve the experiences of those we serve, and spend less time on repetitive work.
The savings might be significant. The additional capacity might be even more valuable.
Where does this leave us?
I'm not ready to suggest that higher education should start building everything.
Far from it.
There are things I wouldn't want my institution trying to recreate, regardless of how capable AI becomes.
But I'm also not comfortable assuming the decisions we made five years ago would necessarily be the same decisions we'd make today.
I'm wondering whether we need to revisit some of those assumptions.
Are there applications we're paying for that solve relatively simple problems?
Are there needs we're not addressing because we assume the solution would be too expensive?
Are there opportunities to simplify our work before we purchase another system?
How do we decide which capabilities are worth owning and which are better left to others?
And what does all this mean for the skills and responsibilities of our technology teams?
I don't think we need to rush to answer every question.
We're in a period where the technology is changing quickly, and there's a lot to learn. Some of the things we're experimenting with today may become routine. Others may turn out to be more complicated than we expected.
That's part of discovery.
One of the things I appreciate about KANE is the opportunity to learn from people facing similar challenges across higher education.
I'd love to hear what others are experiencing.
What have you built that you never would have considered building a few years ago? Where has AI changed the economics of a decision? Where have you discovered that buying still makes more sense?
And perhaps most importantly, what questions are you asking now that you weren't asking before?
I don't know exactly where this is headed.
But I have a feeling we're only beginning to understand what's possible.
And I find that pretty exciting.
