Research Software Engineer as a Service: When You Can't Hire One

Your grant promised a tool. A dashboard the funder expects. A pipeline that turns the cohort data into something a reviewer can read. The work plan has a line item for it, and a budget. What it does not have is a person whose job is to build it. The PI runs the science. The two PhD students are best at research, not engineering. The postdoc has a thesis to finish. The institution has a research-software-engineering group, but it is booked solid until next spring.

This is the research software engineer gap, and it is one of the most common reasons a funded project arrives at its deadline with a half-built digital deliverable. This post explains what a research software engineer (RSE) actually does, the four ways teams try to fill the gap, and when bringing in an external RSE as a service is the right call rather than hiring, queuing, or hoping.

What a research software engineer actually does

A research software engineer sits between two worlds. They understand enough of the science to build the right thing, and enough software engineering to build it so it survives. The role grew out of a simple observation, formalised by groups like the Software Sustainability Institute: research increasingly depends on software, and the people writing that software are usually scientists who taught themselves to code, not engineers who learned the domain.

In practice an RSE does work the research team cannot, or should not, do itself:

• turns a prototype into a maintainable, documented tool that runs on more than one laptop
• builds the data pipeline, the dashboard, the API, or the model deployment the work plan committed to
• sets up the version control, testing, and documentation that keep the software usable after the person who built it leaves
• translates between what the funder expects as a digital deliverable and what the team can realistically ship

The value is not just the code. It is that the code is built to a standard a reviewer can verify and a future team can continue.

The four ways teams try to fill the RSE gap

Most projects try one of four routes. Each works in some situations and breaks in others.

1. The institutional RSE group

Many universities now run a central RSE team. When yours has capacity and your timeline is flexible, this is often the best option: the engineers are excellent, they know the institution's systems, and the cost is internal. The break: these teams are usually oversubscribed. A project with a fixed closeout date in four months cannot always wait in a queue measured in quarters. Capacity, not quality, is the constraint.

2. The PhD student

The default. The student who built the prototype keeps going and ships the production version too. Cheap, available, and domain-aware. The break: the student is best at research, the engineering is a stretch on top of a thesis, and when they graduate the institutional knowledge of the tool walks out with them. The result is software that works in a demo and breaks the first time someone else tries to run it.

3. The generic dev shop

Hire a software agency. They have engineers and availability. The break: they do not read Annex 1, do not know what FAIR means, and do not understand what an evaluator looks for in a digital deliverable. They build a competent product that solves the wrong problem, in a stack the team cannot maintain, on a timeline that ignores the closeout date. The decision of whether to build at all, and what minimum-viable means here, is one they are not equipped to make.

4. The permanent hire

Open a position for a research software engineer. The right answer when the need is continuous. The break: hiring is slow, with months of recruiting, onboarding, and pay-scale friction, and a single finite deliverable rarely justifies a recurring salary line. For a project that needs the work done well once, a hire is oversized.

What "research software engineer as a service" means

There is a fifth route that sits between the institutional queue and the permanent hire: an external RSE engaged for a finite, scoped piece of work. The engineering is done by a partner who reads grant work plans natively; the team owns the result and operates it after the partner exits.

Concretely:

• a scoped engagement (typically 4 to 10 weeks) that takes a deliverable from "promised in the Annex" to "built, documented, handed over"
• code delivered to the team's own repositories, in stacks the team can hire for and maintain
• documentation, a runbook, and a fresh-laptop test, so the tool outlives the engagement
• an exit, not a retainer: the team runs the tool itself afterward

The model fits the shape of grant-funded work: finite deliverables, fixed timelines, no appetite for recurring vendor cost.

When the external option is right, and when it isn't

It is the right call when:

• the deliverable is well-defined and the deadline is fixed
• your institutional RSE team cannot take the project in time
• the work needs to outlast a graduating student
• the project does not need continuous engineering, just this piece done well

It is the wrong call when:

• the need is genuinely continuous (then hire, or build internal RSE capacity)
• the scope is undefined (scope it first; a good partner will tell you honestly when a spreadsheet or an off-the-shelf tool genuinely suffices)
• the institutional RSE team has capacity and your timeline can absorb the queue (use them)

An honest partner will sometimes tell you the external option is not the one you need. That is the partner to trust.

What to look for in an external RSE partner

Five things separate a research-fluent partner from a generic shop:

1. they ask to see the Annex, the work plan, and the deliverable definition, not just a feature list
2. they talk in terms of evaluators, FAIR, closeout, and handover, not just "the app"
3. they commit to a stack you can hire for and maintain, and to handing over the code
4. they scope the minimum viable version honestly, and say no to the parts you do not need
5. they plan their own exit from day one

Where Pragma fits

Pragma is a small research-fluent studio that builds the digital deliverables grant-funded projects promised. We work as an external research software engineer for teams whose institutional RSE group is full, whose prototype needs to become a maintainable tool, or whose closeout is closer than their delivery readiness. The engagement is finite, the code goes to your repositories, and we exit without a retainer. We read the work plan, scope the minimum viable deliverable, and ship in weeks rather than quarters.

If your grant promised a tool and your team does not have the engineer to build it, that is the engagement we exist for.

Three things to do this week

1. Check your institutional RSE team's real availability against your deadline. If the queue is longer than your runway, you have your answer.
2. Write down the deliverable in one paragraph: what it is, who uses it, what the evaluator will check. If you cannot, the first task is scoping, not building.
3. If the gap between what is promised and what your team can ship is wider than the time allows, request a scope review. The earlier the conversation, the less compressed the build.

The research software engineer gap is not a failure of planning. It is structural: research budgets fund science, and the engineering is an afterthought until it is suddenly urgent. The fix is to recognise the gap early and choose the route, internal, hired, or external, that fits the deadline you actually have.