About / How We Work

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

Capability, not projects. Efficiency makes the existing way faster; capability lets you do what you couldn't before. We build the second kind. (See 2.3.1 - Building Capability.) Understand before you build. We begin with how your work actually happens, not a demo of what we can do. Reduce risk, don't just promise. Start small, prove value, compound from there. Stay for the long game. Systems need ongoing development, not a one-off delivery. We share accountability for outcomes.

How we work

Capability building only works if it's disciplined and transparent. Ours rests on four moves and two named practices.

Map Prove Build with Evolve. Understand how work really happens; deliver the smallest build that proves value; co-create with the people who'll use it; then keep releasing, balancing new capability with refinement of what exists.

Deliver is our adaptive delivery method: proof-led, full-lifecycle, direct contact with the people writing your code. Read about Deliver →

Redprint is the living blueprint: a shared digital twin of your system that keeps business, development and quality working from the same picture. Read about Redprint →

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. Every step is defined, explained and approved by you before money moves: our progressive escrow means each sprint is signed off from your side before anyone gets paid — including us. The code we write carries a warranty: if it doesn't work as engineered, we fix it at our cost, not yours. Changes are tracked and their implications shown to you ahead of time, not after you've committed. And our governance keeps your senior sponsors in the loop, because in our experience projects rarely fail inside the project — they fail around it, when the people not in the room are left guessing.

There's an honest limit, and naming it is part of taking responsibility. We are translators between your business and the computer. We take full responsibility for the translation; the business judgment stays with you. You know your customers, your market and your operation in a way we never will — so while we break every build into steps small enough to judge, “is this right for my business?” is a question only you can answer. 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 management team

Redgum is run by its core management team — four people, no layers. The people you meet in the first conversation are the people who build and support your system.