You have a funded project and a piece of software you need to run it. Maybe it is a portal for study participants. Maybe it is a tool to collect and clean data in a way no off-the-shelf product handles. Maybe it is a model your lab built that now needs a real interface so other people can use it. You do the sensible thing first. You ask campus IT.
And often, campus IT cannot take it.
This is not a knock on them. University IT and research computing groups do serious work. They run the network, the storage, the security, the shared clusters. But a custom research tool is a different kind of job. It needs to be designed, built, and maintained over months. It has to answer to your grant, your protocol, and your timeline, not the queue for the whole campus. That work does not fit in most IT queues, so it waits. Sometimes it waits until the grant is halfway gone.
We built Prairie Code partly for this exact moment. So here is how we think about the professor’s software problem.
Why it falls through the cracks
A custom research tool sits between two groups, and neither one owns it.
It is too specific for campus IT. They support standard systems for thousands of people. A one-off tool for one lab is outside the mandate, even when everyone agrees it should exist.
It is too much for the lab to build alone. Your graduate students are researchers, not software engineers. A student can stand up a rough script. Turning that into a reliable tool that survives the student’s graduation is a different craft, and it pulls people away from the actual research while they learn it the hard way.
So the tool ends up half-built, undocumented, and dependent on whoever happened to write it. When that person leaves, the tool leaves with them. This is the quiet tax on a lot of research software, and it is expensive.
The part almost no one plans for: the tool has to outlive the grant
Grants end. The software they pay for often has to keep running long after. A cohort you follow for years. A dataset other researchers will use. A method you want the field to adopt. If the tool dies when the funding does, the work does not compound.
Building for that outcome is a design decision you make at the start, not a patch you add at the end. It means clear documentation, standard tools instead of exotic ones, data you can export in full, and a team on your side who was trained to run the system. It means the lab owns the code and the accounts, so the tool does not depend on any one vendor or any one graduate student still being around.
That is how we build. We hand over software your lab owns and can run without us. The engagement ends by design. You keep the tool.
What we actually do here
We are a small custom software workshop near Lawrence, Kansas. We work with university labs and research centers on funded projects that need real software. Research portals. Data collection and cleaning tools. Interfaces that put a lab’s model in front of the people who need to use it. Custom research software, built for one lab’s real problem instead of bent out of a product that was made for someone else.
We are honest about what we do not do. We do not sell you another lab-information system to subscribe to. We do not take work we cannot finish well, and we take a limited number of projects a year so the ones we take get done right. If a subscription genuinely fits your need better than a custom build, we will tell you.
If this is you
If you are a professor or a lab director with a funded project and a software problem campus IT cannot pick up, that is the case we are built for. It does not have to sit in a queue for the rest of the grant.
We are near KU, we work with Kansas labs, and we are glad to talk through what you need before you commit to anything. Reach us at hello@prairiecode.ai.
Why can’t campus IT build custom research software for a lab?
Campus IT supports standard systems for thousands of people. A one-off tool for a single lab falls outside that mandate, even when everyone agrees it should exist, so it waits in a queue built for the whole campus.
What happens to research software when a grant ends?
Without planning, it often dies with the funding. Building software that outlives the grant means clear documentation, standard tools, exportable data, and a team trained to run it, so the lab owns the code and the accounts instead of depending on one vendor or one graduate student.
Does Prairie Code build software for university labs?
Yes. We are a small custom software workshop near Lawrence, Kansas, and we work with university labs and research centers on research portals, data collection and cleaning tools, and interfaces that put a lab’s model in front of the people who need it.
Written by
Miles Bassett
Founder and principal craftsman at Prairie Code. He writes and speaks on deliberate AI adoption for small businesses and institutions.