A living blueprint everyone can read.
Redprint is a shared canvas: a digital twin of your system that changes as the project evolves. It holds the high-level goals and the technical detail in one place, so business, development and quality all work from the same picture.
Why a shared blueprint matters
Most software projects lose meaning in translation. Intent gets handed from business to project manager to developer, and detail scatters across documents nobody keeps current. Redprint is the antidote: one active blueprint that stays true as the build changes. Because it's shared, everyone sees the same thing: leaders see how goals map to what's being built, developers see the technical detail, quality sees what "done" means.
What Redprint gives you
Visibility: see what exists, what's coming, and how it connects. Prioritisation: decide what's next against the whole picture, not one silo. Transparency: no black box; the blueprint is open to you throughout. Lifecycle support: the twin keeps serving you long after the first release, guiding maintenance and the next layer of capability.
Why it supports capability building
Capability compounds when each layer builds cleanly on the last. Redprint is how we keep that foundation coherent: the architectural memory that lets the next build be faster, more valuable, and harder for competitors to copy.
Already have a system? Start with Retrospective Redprint
Most businesses don't start from a blank page — they arrive with a system that has run the place for years. Often it was home-grown, and the documentation never happened: nobody wrote down why it works the way it does, what it actually does for each user, or how it does it. The knowledge and IP live in one developer's head, or have already walked out the door. If your core software isn't stable, neither is your business — and you can't make a good decision about a system nobody can describe.
Retrospective Redprint recovers the blueprint from a system that never had one. Two instruments do the work. The Asset Register captures a clear, high-level picture of the system as it stands: maps of its key areas, and a list of the assets that make it up, each with its size and risk profile — the IP crystallised, and a structure to hang every future decision on. The Quality Index then grades each asset from five (“well engineered — safe to extend, the tests and documentation tell you what to expect”) down to zero (“move anything, even a little, and it may break in ways nobody can predict”). Together they turn a fog of opinions about the old system into an honest, shared picture.
You'll recognise the moment this is needed. Staff build workarounds outside the system to get their jobs done, and nobody quite trusts its results. New-starter training is measured in months. Developers blame the technology, then the business; every release creates more problems than it solves; every recommendation ends in “rewrite it in technology X.” Customers have learnt to push back for discounts, and your ability to adapt is capped by the system itself.
From that honest picture, the decision becomes strategic rather than emotional: keep it, grow it, replace it — or sell it. Depending on the goal, we capture at the depth required: the high-level register for orientation and planning; usage capture (how each role actually works, every use case, every “I wish it could”) to inform a replacement that misses nothing; business capture for a complete functional specification; technical capture where the secret is in the code and needs to survive it. For buyers and investors, the same work answers the only question that matters: what exactly are we buying?
Retrospective Redprint is where capability building starts for an established business: a picture of the IP you already own, and a foundation for planning what comes next.
How we deliver → ยท How we work →