We don't start with what should be built.
We start with what the business is trying to achieve — and what is actually standing in the way. The answer to that decides what gets engineered, and whether anything needs to be.
- Business understanding
- What the business must achieve, and what already works.
- Diagnosis
- The constraint underneath the request, not the request.
- Decision
- Reuse, buy, integrate or build — and sometimes nothing.
- Engineering
- Only what the decision justifies, built for handover.
Protect what is working. Diagnose what is not. Introduce only the technology and complexity the business can justify.
The systems your business runs on today keep running while the change is underway. Nothing gets replaced for being old. Replacement has to win an argument against leaving the system alone, and most of the time that argument has not been made.
Most requests arrive with the answer already inside them. We test that choice before we cost it, because an assumption is cheap to correct in a conversation and expensive to correct in production.
We introduce complexity only when the business can point to what it buys. Complexity added for a future the business cannot yet describe is paid for now and defended for years.
We do not open with engineering. We open by narrowing the problem until one course of action is clearly better than the alternatives — including the alternative of leaving it alone.
What we establish before we recommend anything
Nine Questions, asked in this order, before any scope is written or any price is agreed. The order is the method: every question depends on the answers above it, and a technology question asked first produces a technology answer.
01
What has to be different in the business when this is finished?
Desired business outcome
The answer is a change in how the business operates or earns, not a list of features.
02
What is the one constraint everything else bends around?
The binding constraint
Budget, a date, a contract, one person's availability — one of them is already deciding the answer.
03
What already works and should be left alone?
Investments worth keeping
Systems that are unfashionable but load-bearing are the ones most often replaced for no return.
04
What data do you already hold?
Data that already exists
Most organisations already hold the data the new system is being asked to produce.
05
What has been tried before, and why did it fail?
Previous attempts and their causes
A failed attempt tells us more about the real constraint than any requirements document.
06
Who operates this after we leave?
The team that inherits it
The team that inherits the system sets the ceiling on how complex it can be.
07
What does doing nothing cost?
The cost of no change
If nothing changes and the business is fine, that is a finding, not a failure.
08
How will we know this worked?
How success is measured
A measure agreed before the build cannot be rewritten afterwards to fit the result.
09
What breaks if this goes wrong?
What breaks, and for whom
Which customers, which payments, which obligations — the answer sets how carefully we sequence the change.
The diagnostic should reduce uncertainty before it creates a delivery commitment — reverse that order and you have bought a plan nobody has tested.
Six ways forward. Only one of them is building.
Most briefs arrive already naming a build. Build sits last because it is the most expensive, the slowest, and the only one of the six you cannot undo cheaply.
We weigh business impact, time to value and long-term fit against cost, risk and complexity. That is a lens, not a score — no formula turns six judgments into a ranking. Naming all six forces the trade-off into the open, where you can argue with it.
Reuse
Something you already own does most of this, and nobody has opened it in years.
- Capability you have already paid for and your team already runs beats a better version of it that nobody has built yet.
- You inherit its constraints and its shape. If the thing you need is genuinely different, reuse buys a workaround, not a solution.
Refactor
The system does the right things badly. The logic is sound; the code around it is not.
- Working software carries business rules nobody wrote down. A rewrite discards them, then rediscovers them one production incident at a time.
- It will not fix a wrong data model or an architecture that cannot reach your scale. Refactoring improves; it does not redirect.
Replace
The system's cost of change is rising faster than the value it returns.
- Replace when the constraint is structural, not cosmetic — when every change costs more than the last and nobody can say why.
- You pay twice — for the new system and for running the old one until the last user moves off it.
Buy
The problem is not specific to you, and someone already sells the answer.
- Nobody wins a customer because their billing engine is custom. Buy the commodity; spend the engineering where competitors cannot copy you.
- You take on someone else's roadmap and pricing. Bending the product around your process costs more than the licence does.
Integrate
The capability exists across systems you already own; nothing joins them up.
- What looks like a missing system is two working systems with no path between them. Wiring costs less than rebuilding either end.
- Every integration is a dependency on someone else's uptime, versioning and data quality. The seams need owning, monitoring and testing forever.
Build
Nothing on the market fits, and the thing that does not exist is the differentiator.
- Build only where the work is the business itself — the part a competitor buying the same software still could not copy.
- It is the slowest route to value, and every defect, upgrade and maintenance hour after launch belongs to you.
Build is an available answer, not our default one — a firm that reaches it every time is selling hours.
Two ways to answer the same brief.
The two columns answer the same brief and disagree at ten points. The left-hand column is not a straw man — each of those answers is defensible, and most of them are what you have been quoted before. The first four rows are where the difference starts: prescribing becomes diagnosing, replacing becomes preserving, complexity becomes proportion, delivery becomes outcome.
| Decision point | Conventional approach | CipherCru approach |
|---|---|---|
| The starting point | The brief names the solution. Delivery starts immediately, and no budget is spent before code exists. | We spend money before code exists, on finding out whether the code is the answer. |
| Existing systems | A rebuild on a current stack is cleaner to estimate, staff and support than inherited code. | What works stays. We replace the part that is failing and leave the rest running. |
| How much is built | Architecture is sized for the scale the business plans to reach, avoiding a second rebuild. | We build for the load and risk you have now, and leave seams where growth arrives. |
| What counts as done | The agreed scope is delivered, tested and signed off. Scope is what was contracted and priced. | Signed-off scope is not the measure. The change has to hold up in your operation. |
| How requirements are treated | Requirements are captured, agreed and baselined, so both sides know exactly what is being built. | A requirement is an answer someone already chose. We ask what it was answering. |
| How the estimate is made | The estimate follows the specification. A fuller specification produces a firmer number and a fixed price. | We price what we understand. Uncertainty gets work to remove it rather than a padded number. |
| When the brief is wrong | A change request is raised, costed and scheduled. The contract absorbs it in an orderly way. | We say so before the build. Losing the work costs less than building the wrong thing. |
| Who owns the decisions | The delivery team decides within scope and brings the significant calls to you for sign-off. | You decide. We make the trade-off explicit, recommend one option, and record why the others lost. |
| What handover means | Handover is a defined phase at the end: documentation, training and a clean transfer of access. | Handover is not an event we run. Your engineers review the code as it is written, so nothing arrives unexplained. |
| How the relationship ends | A support or retainer agreement continues after launch, keeping the people who built it available. | It ends when you choose. Nothing we build depends on us, and leaving carries no penalty. |
Each stage makes something certain before the next one begins.
A stage ends when a specific uncertainty is gone, not when its time is used up. If we cannot name the question a stage closed, starting the next one just moves the unknown further down the engagement, where it costs more to answer.
Clarity
Discover
Start with the business, not the backlog.
We begin with the business outcome, users, current systems, constraints, risks, and priorities. Together, we define what needs to change, what should be built, and the clearest path from idea to delivery.
- What you see
- You answer questions about the business before anyone discusses a technology.
Direction
Design
Turn intent into clear decisions.
We translate the agreed direction into user journeys, system architecture, integrations, technical decisions, and delivery-ready specifications — balancing usability, scalability, maintainability, risk, and cost.
- What you see
- You approve the architecture, and the trade-off it accepts, while changing it is still free.
Visibility
Develop
Make progress visible in working software.
We build in prioritized increments using focused delivery cycles, continuous integration, testing, code reviews, and regular demonstrations so progress stays visible and working software is delivered throughout the engagement.
- What you see
- You use the software yourself while it is still incomplete.
Evidence
Validate
Prove it before production depends on it.
We validate functionality, integrations, performance, security, resilience, and critical user journeys against agreed acceptance criteria, then resolve issues that could compromise reliability or production readiness.
- What you see
- You see the failures as well as the passes, while there is still time to act on them.
Control
Launch
Go live without losing control.
We plan and execute the production release, verify environments and integrations, complete documentation and operational handover, and confirm the system is stable and ready for real-world use.
- What you see
- You hold the go-live decision, and the runbook your team will use.
Progress
Evolve
Keep improving after the release.
After launch, we monitor real-world performance, support operations, address emerging needs, and prioritize improvements using business priorities, user feedback, and product evidence rather than change for its own sake.
- What you see
- You decide what changes next from what production shows, not from the original roadmap.
Discover the right problem. Design the right intervention. Develop it with visibility. Validate it with evidence. Launch it without disrupting the business. Evolve it as the business changes.
The shape of an engagement, not a schedule.
Nine milestones every engagement passes through, in this order. How long each takes depends on the problem, so none of them is a date. What changes is not the calendar but who is deciding, who is operating, and what we are still needed for.
Questions
We begin with questions
Nothing is being built yet, and that is deliberate. You will spend more time explaining the business than the systems, and some of what you assumed was settled will turn out to be an open question.
- Decision confidence
- Questions
- Product maturity
- Concept
- Client ownership
- Context Provider
- CipherCru role
- Consultant
Decisions
Decisions become explicit
Nothing stays implicit. Every significant call is recorded with the reasoning that produced it, so a decision taken this quarter can still be defended two years later by people who were not in the room.
- Decision confidence
- Diagnosis
- Product maturity
- Concept
- Client ownership
- Decision Partner
- CipherCru role
- Architect
Software
Decisions become working software
Progress stops being a status report and becomes something you can open. What you open is the system itself, incomplete on purpose, built in the order that retires the biggest risks first.
- Decision confidence
- Decisions
- Product maturity
- Working Software
- Client ownership
- Reviewer
- CipherCru role
- Engineering Partner
Evidence
Evidence replaces assumptions
Claims about performance, security and behaviour under load stop being claims. Where the evidence contradicts a decision we made earlier, we change the decision rather than the success criteria.
- Decision confidence
- Evidence
- Product maturity
- Production-Ready
- Client ownership
- Reviewer
- CipherCru role
- Engineering Partner
Adoption
Software moves into the business
Real users, real data, real consequences. The launch is staged so today's operations keep running throughout — the business absorbs the change in steps it can reverse, not in one weekend.
- Decision confidence
- Evidence
- Product maturity
- Live
- Client ownership
- Operator
- CipherCru role
- Launch Partner
Ownership
Ownership is already transferring
There is no handover event, because there is nothing left to hand over. The code, accounts, documentation and decision records have been in your name since the first commit, and your engineers have been in the reviews.
- Decision confidence
- Evidence
- Product maturity
- Live
- Client ownership
- Owner
- CipherCru role
- Launch Partner
Advisory
CipherCru's role starts changing
You need us for fewer things, and that is the intended direction. We move from writing the software to reviewing what your team writes, and the questions coming to us get harder and rarer.
- Decision confidence
- Evidence
- Product maturity
- Live
- Client ownership
- Owner
- CipherCru role
- Advisor
Production
Production creates new evidence
Live usage tells you things no diagnostic could. Some of the roadmap you agreed at the start will now look wrong, and it is cheaper to admit that from production data than to build it anyway.
- Decision confidence
- Confidence
- Product maturity
- Live
- Client ownership
- Owner
- CipherCru role
- Advisor
Evolution
Evolution becomes selective
Not every idea gets built, and the bar rises once the system is already doing its job. We argue for the changes the evidence supports and against the ones that only add surface area to maintain.
- Decision confidence
- Confidence
- Product maturity
- Improving
- Client ownership
- Owner
- CipherCru role
- Advisor
The last three milestones are about needing us less. An engagement that leaves you more dependent on us than when it started has failed.
Seven models. What changes between them is who owns the outcome.
Discovery into Fixed-Scope Delivery into Retained Engineering is a common path; so is Discovery into a Dedicated Team. You are choosing where to start, not committing to how the engagement ends.
Two questions decide it: how much is already known, and who should carry delivery risk. Everything else — budget model, urgency, how long the roadmap runs — narrows the shortlist rather than setting it. If you are unsure, start with the model that commits you to the least.
Discovery / Assessment
A time-boxed investigation that ends in a written recommendation, including the recommendation not to build. You can act on it with us or without us.
Best when the problem is agreed and the solution is not.
- Where it fits: a business case nobody can evidence, or a system everyone blames.
- A written problem statement, the options considered, and the reasoning for each.
- You own the decision at the end; we own the evidence behind it.
Consulting / Advisory
Senior engineering judgment applied to decisions you are already making — architecture, vendor choice, a rebuild someone has proposed. No delivery attached.
Best when you have the team but not the second opinion.
- Where it fits: an in-house team facing a decision it cannot take twice.
- Architecture review, technology selection, or a rebuild proposal tested before it is funded.
- You own the decision and the delivery; we own being right about what we told you.
Staff Augmentation
Senior engineers inside your team, under your process, your standards and your review. You direct the work day to day.
Best when you know what to build and lack the people.
- Where it fits: a roadmap that is agreed, funded and behind schedule.
- Knowledge transfer is a deliverable, so capacity does not become dependency.
- You own the backlog, the priorities and the delivery risk.
Dedicated Engineering Team
A standing team that works to your roadmap with our own delivery lead, engineering standards and quality bar. It ramps up and stays with the product.
Best when the roadmap is long and the requirements keep moving.
- Where it fits: a product roadmap that runs longer than any single project.
- A named delivery lead who is in the standups, not reporting on them.
- You own direction and priorities; we own how the team delivers them.
Retained Engineering
Reserved senior capacity for a system already in production — changes, integrations, incident support and the improvements a live business keeps needing.
Best when the software is live and the work never fully stops.
- Where it fits: a live system your team can run but not extend.
- Unused capacity is a signal to reduce the retainer, not to invent work.
- You own the operation; we own the engineering capacity you draw on.
Fixed-Scope Delivery
A defined piece of work, scoped and priced up front, delivered end to end. Scope changes are re-priced in the open rather than absorbed quietly.
Best when the scope is stable enough to write down and hold.
- Where it fits: a replacement, an integration, or a first release with firm edges.
- Fixed budget, so the risk of a wrong estimate is ours, not yours.
- We own scope, estimate and delivery risk; you own acceptance.
Managed Delivery
We take an outcome rather than a specification — assembling the team, running the delivery, and reporting against the business result you asked for.
Best when the result is agreed and delivery has no owner.
- Where it fits: an organisation with the outcome but no engineering function to run it.
- Reporting is against business milestones, not against hours booked.
- We own planning, staffing and delivery; you own the decisions and the result.
The right model is the one that matches how much is already known and who should own the outcome — not the one that keeps us on the account longest.
Six outcomes, grouped by what they are for.
Six categories of outcome. Judge each by the same test — whether your team could act on it with nobody from CipherCru in the room.
What you receive depends on four things: the problem we are solving, the engagement model you choose, the scope we agree, and where delivery responsibility sits. A staff augmentation engagement and a managed delivery do not produce the same evidence.
Ownership says what belongs to you. This list says what we leave behind. They are not the same question, and a page that answers only the first has not told you what you get.
Clarity
What the problem is, what we recommend, and enough reasoning for someone who was not there to check it.
- A written recommendation with the reasoning behind it
- A record of the options we rejected, and why
- A problem statement agreed before any scope is written
A Delivery Path
How the work is sequenced, what it depends on, and what could stop it — agreed before budget is committed.
- A scope that names what is excluded
- A sequenced plan with its dependencies and risks
- An estimate with the assumptions it rests on
Working Technology
Software you can run, use and deploy while the engagement is still going on.
- Working software running in your environment
- Code committed to your repositories as it is written
- Integrations with the systems you already run
Evidence
What proves the system behaves as agreed — including where it did not, and what we changed.
- Test results against the agreed acceptance criteria
- Performance, security and resilience results
- A record of what failed and what we changed
Production Readiness
What your team needs to run the system on the first day we are not available.
- A runbook for the failures we know about
- Deployment and rollback procedures your team has run
- Monitoring and alerts that reach your team, not ours
Capability to Continue
Your team can change the system after we leave, without calling us to explain how it works.
- Decision records explaining why the system is built this way
- Documentation a new engineer can start from
- A backlog of what we did not build, and why
Not every engagement produces every output. What we agree to produce is written into the scope before the work starts, so nothing on this list arrives as a surprise invoice.
What holds on every engagement
Five commitments, the same five we make on every piece of work, whether or not they are negotiated.
01
A named senior engineer accountable for the engagement. One person owns the outcome from the first conversation to handover — not an account manager relaying questions to a delivery team you have never met.
02
A working product in your environment within the first month. Something real, running where you can use it, inside the first month. Progress you can operate is worth more than progress you have to take on trust.
03
Every technology decision comes with a reason. The trade-off, the alternatives we considered and why we chose what we chose, written down as we go, so the next team does not have to relitigate it.
04
No lock-in. Nothing we build depends on us to keep running. If you decide to take the work elsewhere, there is no technical or commercial obstacle in the way.
05
We own the engineering. You own the product. Engineering judgment, quality and delivery are our responsibility. Direction, roadmap and the asset itself are yours, throughout.
The questions worth asking before you commit
The answers below are the ones we give on a call — written down so you can check them against what we do.
How quickly can you start?
How do you estimate an engagement?
What happens when requirements change?
Who actually works on our project?
Can you work with our existing team?
What if we are not yet sure what we need?
Can you take over an existing or troubled system?
What happens after launch, and who owns everything you build?
Have a decision you are stuck on?
Bring us the constraint, not the spec. We will tell you what we would do and why.