Redgum Book a conversation →
Two developers listening to a business owner at a workshop bench, sketching his process as simple red diagrams

Software developers who don’t speak in code.

For more than 30 years we’ve built systems for businesses across 40+ industries, from solo consultancies to organisations with thousands of staff. The through-line has never been the technology. It’s the relationship, and the belief that a business’s unique strengths are worth protecting, not standardising away.

We build what your competitors can’t copy.

Most software makes a business more like its competitors — same tools, same processes, same ceiling. A sovereign system does the opposite. One question decides everything we do — what is the long-term best outcome?

Key facts. Redgum is a four-person Australian software consultancy, founded in the 1990s at Swinburne, that builds sovereign systems — software shaped around a business’s own way of working, so the capability can’t be bought off a shelf or copied by a competitor.

Why we exist

Somewhere along the way, “getting software built” became a translation problem. People who understood the business talked to project managers, who talked to analysts, who talked to developers, and by the time anything got built, the original intent had been sanded down to fit a template.

We started Redgum to close that gap. The person writing the code stays in direct contact with the person running the business. No translation layer to lose meaning in, and no incentive to make your operation look like everyone else’s.

What we do

Redgum builds sovereign systems: software designed around what a business does differently, not what it does the same as everyone else. We work as architects and business-solution creators, building frameworks for business operations that grow the value of the whole company — not just its top-line revenue.

A sovereign system takes the thing your business does differently — the judgment, the shortcuts, the hard-won exceptions — and turns it into capability nobody else can follow, because nobody else has your business inside it. Efficiency makes the existing way faster; capability lets you do what you couldn’t before. We build the second kind.

That’s why the work starts with conversation rather than a spec. Exploring how the business really runs is where the gold is unearthed — the unique knowledge that becomes unique capability. And it’s why we build for the leader and their people: the point is to bring staff with the leader on the journey, never to cut them out.

We measure the result the way an owner does — by what the company is worth, not just what it earned this quarter.

How we achieve it

By behaving like an advisor first and a developer second. Every engagement runs on the same commitments: act in the client’s best interest, challenge their thinking, stay commercially savvy, de-risk the build, and deliver what the business needs — which is not always what it first asks for.

A yes-man with a keyboard is cheap and everywhere. What’s rare is a partner who will push back — who asks why before how, and who treats your capital the way you do. So we challenge the status quo with a fresh perspective, and we bring insights across sectors: a pattern proven in logistics might be exactly what a professional-services firm needs, and after 40+ industries we’ve usually seen the pattern before.

Commercial savvy runs underneath all of it. We think in lifetime cost of ownership, not build cost — because the most expensive system is the one that doesn’t work.

  1. 1

    Map

    Understand how work really happens.

  2. 2

    Prove

    Deliver the smallest build that proves value.

  3. 3

    Build with

    Co-create with the people who’ll use it.

  4. 4

    Evolve

    Keep releasing, balancing new capability with refinement of what exists.

Two named practices carry the discipline:

The values we work by

Values only matter when they cost something. These are the ones we’ve paid for over thirty years, and they are the reason clients stay for decades rather than projects.

Together they add up to one identity: the advisor who happens to build software — making a real difference to a client’s business, one decision at a time.

We take responsibility for the outcome

Most development firms take responsibility for effort: hours worked, features shipped. We’ve always taken responsibility for the result. When projects have gone wrong over thirty years — and some have — we’ve put in whatever it took to get them back on track and deliver. The question that has shaped our practice is a careful one: how does a developer take responsibility for the outcome safely, without pretending risk doesn’t exist?

The answer is structural, not heroic — four mechanisms carry the risk:

The partnership, honestly drawn

There’s an honest limit, and naming it is part of taking responsibility. We are translators between your business and the computer:

That’s not a caveat. That’s the partnership working as designed. Taking responsibility doesn’t mean taking over — it means building so that at every step you can see exactly what you’re getting. And so can we.

Where we came from

Redgum started the way a lot of good things do: with friends who couldn’t leave a problem alone. In our industry-based learning year at Swinburne, four of us — Robin Vessey, Matt White, Matt Richardson and Andrew Bickerton — were supposed to spend the year inside IBM or Microsoft. Instead we started Redgum, signed each other’s industry-year agreements, and told the university we’d been employed. This was long before startups were cool; back then, striking out on your own was closer to an embarrassment.

The commercial solution we built that year ran for nine years — and was only retired when another Redgum solution replaced it. The lessons of that first project, and a stubborn unwillingness to accept the standard software development paradigms, became the foundation of everything since: an organisation-wide focus on the science and engineering of software for business. That focus is the difference between another software developer and a genuine development partner.

Experience means little unless you capture it — so we’ve used our own craft on ourselves. Redprint is institutional memory turned into a working system: three decades of project delivery distilled into the process every client build runs on. It shapes how we scope, build and manage every project — the predictability and accountability you need, alongside the creativity you want. And when you engage Redgum you inherit more than a team: three decades of accumulated IP, code libraries and solutions proven in the real world, which means less building from the ground up — lower cost, less time, less risk. You benefit directly from every mistake we’ve already made and every solution we’ve already proven.

The team

Redgum is a small team — four people, no layers. The people you meet in the first conversation are the people who build and support your system.

Start the conversation

Book a conversation → · See our work →

Related

How we workDeliverRedprintCommercialising Industry ExperienceInnovating Internal OperationsPortfolio: CatalogueBuilding Capability: Book Landing