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.
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 believe
The longer version — what we do, how we achieve it, and the values that decide both — is at Who we are.
How we work
Capability building only works if it’s disciplined and transparent. Ours rests on four moves and two named practices.
- 1
Map
Understand how work really happens.
- 2
Prove
Deliver the smallest build that proves value.
- 3
Build with
Co-create with the people who’ll use it.
- 4
Evolve
Keep releasing, balancing new capability with refinement of what exists.
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.
Robin Vessey
Author, Building CapabilityMatt White
LinkedIn →Daniel Findley
LinkedIn →Scott Rapsey
LinkedIn →
Start the conversation
Book a conversation → · See our work →