Engagement model
A second opinion from engineers with no stake in the answer
Senior engineering judgment applied to a decision already on your table. We are not bidding for the delivery work behind it, which is what makes the advice worth having.
- Best for
- You have the team, but not the second opinion.
- Engagement type
- Advisory time, with no delivery attached.
- Your involvement
- You keep the decision, the delivery and the timeline.
- Our responsibility
- Being right about what we tell you.
- Primary outcome
- A consequential decision made with better information.
You probably need this when
Advisory is bought when a decision is close, expensive, and hard to reverse — and the people closest to it are too invested to test it.
A decision is coming that you cannot take twice
A platform choice, a data model, a move off a monolith. Reversing it later means paying for it twice, so it is worth being sure once.
A rebuild has been proposed from inside
Your own team wants to replace something. They may well be right — but nobody in the room is positioned to test the case dispassionately.
You are choosing between vendors or platforms
Two credible proposals, each convincing in its own terms, and no neutral way to compare what they are actually committing to.
An architecture needs review before it is built on
The design is done and about to become expensive to change. You want it read by someone who has seen this fail before.
A technical strategy needs testing against reality
There is a two-year direction on a slide. Whether your team, your systems and your budget can actually reach it has not been examined.
What this engagement means
You are buying judgment and the reasoning behind it. You keep the decision, and no delivery work is bundled to it.
This isn’t
- A bundled development engagement, or a route into one
- Staff augmentation — nobody joins your team or picks up tickets
- A disguised pre-sales exercise for CipherCru delivery work
- A full investigation of a problem you have not framed yet
- Ownership of the decision, or of what follows from it
This is
- Independent engineering judgment on a decision you have already framed
- Architecture and technology review by people who have built and maintained this class of system
- Vendor and proposal assessment, read on the terms the proposal is making
- Decision support: the options, the trade-offs, and what we would do
- Access to a senior engineer for the length of the decision, not the length of a project
What you get
Advisory outputs are small, written and pointed. The value is in the reasoning, so the reasoning is what gets handed over.
- A recommendation on the specific decision in front of you
- The reasoning that produced it, and what would change it
- The case against our own recommendation, stated fairly
- Review of the proposed architecture or platform choice
- The failure modes it carries, and which of them matter at your scale
- What is genuinely load-bearing versus what is preference
- A written record of the decision, the options and the rationale
- The assumptions it rests on, named so they can be revisited
- Questions to put to a vendor or an internal team before committing
How we work together
This is the model where CipherCru holds the least. You own the decision, the delivery and the outcome; we own the quality of the advice.
| Responsibility | Client | Shared | CipherCru |
|---|---|---|---|
| Framing the decision | Not included | Included | Not included |
| Technical judgment and review | Not included | Not included | Included |
| Options and trade-offs | Not included | Not included | Included |
| The decision itself | Included | Not included | Not included |
| Delivery of the work | Included | Not included | Not included |
| Engineering standards | Included | Not included | Not included |
| Team and priorities | Included | Not included | Not included |
| Outcome of the decision | Included | Not included | Not included |
How the engagement runs
Short, and shaped around the decision rather than a delivery calendar. It ends when you can decide.
Framing
We establish what is actually being decided, what has already been ruled out, and what constraints are real rather than assumed.
Review
We examine the architecture, the proposal, the systems or the vendor material in front of you, and talk to the people who will live with the result.
Challenge
We test the reasoning — including our own — against how this class of decision usually fails. This is the part you are paying for.
Position
We give a recommendation and the reasoning behind it, in writing, along with the case against it.
Support
We stay available while the decision is taken and communicated, so the reasoning holds up in the rooms we are not in.
Is this right for you?
Advisory works when there is a decision to advise on. Without one, it becomes a conversation with no output.
A strong fit when
The question is framed, and what is missing is independent judgment.
- You have capable engineers and a decision none of them can take neutrally
- The choice is expensive to reverse and about to be made
- You want a proposal or a vendor assessed by someone not competing for the work
- You need the reasoning recorded, not just an answer
Consider another model when
The problem is not yet a decision, or what you need is hands rather than judgment.
- You are not yet sure what the problem is, let alone the options
- You want someone to own delivery of the outcome, not advise on it
- Your team needs additional engineers under your own process
- The decision is made and the work needs scoping and building
Another model may suit you better: Discovery / Assessment — The question itself is unclear and needs investigating before anyone can advise on it. Managed Delivery — You would rather hand over responsibility for the outcome than take the decision yourself.
This sounds like what we need.
Tell us the decision you are facing. We will tell you whether an outside read would change it — and decline if we think it would not.
How it works commercially
Advisory is bought as senior time against a defined decision, with nothing attached to the other end of it.
Fees are agreed per engagement. Contractual detail lives in our engagement terms.
Compare relevant models
Advisory is often weighed against one model that goes further back and one that goes much further forward.
| Consulting / Advisory | Discovery / Assessment | Managed Delivery | |
|---|---|---|---|
| Starts from | A decision already framed | An unclear problem | An agreed business outcome |
| Main output | Judgment and a decision record | A written recommendation | The outcome itself |
| Who is accountable for delivery? | You are | You are | CipherCru is |
| How much of your time? | A few focused conversations | Access during the investigation | Direction and review, not management |
| Ongoing capacity? | No | No | Yes, for the length of the outcome |
Other ways to work with us
If a decision is not quite what you have — or you would rather not be the one making it — these are the nearer models.
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.
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.
Not sure which model fits? Tell us the situation and we will point you at the right one. See all seven engagement models
Common questions
What clients ask before commissioning advisory work.
You build software. How is your advice independent?
Who actually does the work?
How quickly can you start?
Can this turn into a delivery engagement later?
Will this undermine our own engineers?
How is this different from a Discovery?
Put the decision in front of someone outside it
Tell us what is being decided and what it costs to get it wrong. We will tell you whether an independent read is worth your money.
Consulting / Advisory
Engagement model