When Less Is More: What Mature PGR Software Learns to Leave Out

25th September 2026

One of the strangest things about mature software is that it can look less sophisticated than immature software.

Fewer fields. Fewer options. Fewer things to configure. Simpler dashboards. Fewer decisions for the user to make.

At first sight, that can look like less capability.

But often the opposite is true.

In our recent article, Why PGR Management Is Different, we explored why postgraduate research management is deceptively complex. Much of that complexity doesn’t come from individual processes, but from the way those processes interact over the lifetime of a research degree.

That leads naturally to another question:

If the underlying domain is complex, should the software look complex too?

We don’t think it should.

In fact, one of the things nearly two decades of developing PGR software has taught us is that product maturity can have a rather counter-intuitive appearance.

Mature software can look simpler.

Not because it does less.

Because it has learned what its users shouldn’t have to do.

Adding capability is the easy direction

Software products have a natural tendency to accumulate things.

A new field is requested. Another workflow stage is added. A new status is introduced. Somebody wants an additional notification. Another configuration option would accommodate a particular way of working.

Individually, each request can be entirely rational.

But every addition has consequences.

Who can see the new field? Who can edit it? Does it affect workflow? Does it require approval? Should it appear in reporting? Does another system need to know about it? What happens when regulations change?

The visible addition might be tiny.

The dependencies behind it may not be.

Over many years, those individually reasonable decisions can accumulate into considerable complexity.

Configurability isn’t necessarily flexibility

This creates an interesting paradox.

A highly configurable product can initially appear extremely flexible.

Almost anything can be changed.

But every local configuration creates another variation that needs to be understood, maintained, tested and supported.

As those variations accumulate, changing the product itself becomes harder.

So more configurability does not necessarily produce greater long-term flexibility.

It can sometimes produce the opposite.

More configuration → more variation → more dependencies → more complexity → greater maintenance → harder upgrades → less long-term agility.

There is therefore an important distinction between software that can’t do something and mature software that has deliberately decided something shouldn’t need to be configurable.

Product maturity involves learning what to leave out

Young software tends to demonstrate its progress by adding capability.

Mature software has another challenge.

It has to learn what not to add.

Which options genuinely benefit users?

Which processes should be standardised?

Which decisions need human judgement?

Which exceptions genuinely justify permanent software functionality?

And which underlying complexities can the platform simply manage itself?

Those decisions become particularly important in postgraduate research management because apparently small changes can interact with events elsewhere in a researcher’s journey.

Exposing every underlying rule and dependency doesn’t remove that complexity.

It simply transfers responsibility for managing it from the software to the people using it.

The sophistication of simplicity

This is why we don’t think visible complexity is necessarily evidence of sophisticated software.

Consider a dashboard.

It is relatively easy to display everything the system knows.

The harder problem is deciding what this particular person needs to know now.

What requires attention?

What decision needs to be made?

What can safely remain invisible?

A simple dashboard may therefore represent considerably more thought than a complicated one.

The same principle applies throughout a PGR platform.

Researchers shouldn’t need to understand the machinery governing their candidature.

Supervisors shouldn’t need to understand every underlying process dependency.

Administrators shouldn’t have to carry every possible combination of events in their heads.

The complexity still exists.

But increasingly, it should exist inside the product rather than inside the user’s head.

Absorbing complexity

We think this is an important way of looking at software maturity.

The purpose of a specialist platform isn’t simply to digitise complexity and display it more efficiently.

It should understand enough about its domain to absorb some of that complexity.

That doesn’t mean hiding information people genuinely need.

It means modelling the difficult relationships underneath the user experience so that users don’t have to reconstruct those relationships themselves.

The researcher sees what they need to do.

The supervisor sees what requires their attention.

The administrator sees where their expertise and intervention are required.

The machinery underneath may be extremely sophisticated.

But the person using it shouldn’t need to know.

After nearly two decades of developing software for postgraduate research management, that leads us to a fairly simple conclusion:

The maturity of a PGR platform is not measured by how much complexity it can expose. It is measured by how much complexity it can absorb.