On a plan, a platform, or someone else’s proposal — including an honest answer about what you do not need to build yet. Priced as advice, not as a way into a bigger project.
The people best placed to tell you whether a technology decision is sound are usually the people quoting to deliver it. That is not dishonesty — it is a structural problem, and it is the one this service exists to solve.
A quote arrives with a timeline, a stack and a six-figure number. You cannot tell whether the price is fair, the approach is sound, or half of what is listed is needed at all — and the only person who can explain it wrote it.
Deadlines move, the explanations get more technical, and nobody internally can challenge them. The uncomfortable question — is this recoverable, or are we paying for the same thing twice — has no safe person to ask.
The plan grew in meetings, everyone contributed, and it is now bigger than the problem that started it. Somewhere in it is a smaller version that would settle the question for a fraction of the money.
We read what you have been sent the way a technical buyer would: what is actually included, what is assumed, where the estimate is soft, what is missing, and which questions to put back before you sign. Often the outcome is that the vendor is fine and the scope is not.
The three-way question most plans skip. Ready-made software wins more often than agencies admit, and staying on what you have is a legitimate answer. We work through it on cost over several years, not on the appeal of the idea.
Which platform fits the size of the problem, who can maintain it in your market, what it costs to run, and how hard it is to leave. Exit cost is the criterion most selections ignore and most regrets come from.
An assessment of what exists — the code, the architecture, the hosting, or the product itself and how it is used. What is sound, what is fragile, what is genuinely urgent, and what has been called urgent for a year without incident.
A sequence with reasoning attached: what to do now, what to defer, and what to drop. Run as a working session with the people who hold the decision, so it survives contact with your own organisation.
Everything here is usable without us. The output is written to be handed to your board, your vendor or another supplier — that is the point of it.
What we think you should do and why, written so a non-technical director can follow the reasoning and disagree with it on its merits rather than on trust.
The strongest argument for the opposite decision, stated fairly. A recommendation with no counter-argument is a sales document, and you already have enough of those.
The explicit list of things in the current plan that should be deferred or dropped, with the reason for each. This is frequently the single most valuable page in the document.
The state of the code, architecture, hosting or product, separated into what is a real risk, what is a cost, and what is simply not to our taste — because those three are not the same thing.
What to do first, what depends on what, and where the decision points sit — so the plan can be re-argued later by people who were not in the room.
Priced as advice, not as a way into a bigger project. There is no implementation quote at the end, no discount for continuing with us, and no obligation of any kind. If the answer is that your current supplier should carry on, that is what the document will say.
The value of this work is almost always in what does not happen next — the build that was avoided, the scope that was cut, the platform that was not committed to.
Most proposals contain a version worth doing now and a version that grew in meetings. Separating them is usually the fastest money a business saves on a technology decision.
Knowing which questions matter changes the negotiation. Vendors quote and explain differently to a client who can tell an assumption from a commitment.
A platform that cannot be left, an estimate resting on an untested assumption, a dependency on one person. These are cheap to find now and very expensive to find in month seven.
Plenty of these engagements confirm that what you were about to do is right. That is not a wasted engagement — it converts a nervous decision into a settled one, and stops it being reopened every quarter.
This is the Product & Technical Consulting engagement specifically — not the general Novrix delivery process, which covers a whole project from discovery to launch.
The decision stated in one sentence, with the constraints and what a good outcome would look like to you.
The proposals, the code, the contracts, the numbers — and short conversations with the people who hold each part.
Assumptions tested, costs projected over years rather than months, alternatives priced including doing nothing.
A working session where you argue against the finding. What survives that is what goes into the document.
The written recommendation, the counter-case and the sequence. The engagement closes there by design.
It is a fair challenge and you should ask it of anyone. Our answer is structural: this engagement is priced and invoiced as advice on its own, there is no implementation quote attached to the end of it, and there is no discount or credit if you later build with us. We also write the case against our own recommendation into the document. You are welcome to take the findings straight to another supplier — that happens, and it is a normal outcome rather than a failed one.
No. A substantial share of these engagements end in “do not build this yet”, “buy something off the shelf”, or “your current vendor is doing the right thing and the problem is your scope”. If the honest recommendation is that nothing should be built, that is the deliverable, and the invoice is the same either way.
Yes — it is one of the most common reasons people come here. We read it as a technical buyer would: what is actually included, what has been assumed, where the estimate is soft, what is missing, and what to ask before signing. We are not looking for reasons to reject it. A review that concludes “this is a reasonable proposal at a fair price, here are four questions to settle first” is a good result.
As a fixed fee for a defined piece of work, agreed before it starts, based on the scope of the question rather than the size of whatever might follow. A single proposal review is a small engagement. A full technical audit with a roadmap is larger. Either way you know the number in advance, and it does not change according to what we recommend.
Reviewing a proposal is usually days rather than weeks. An audit of an existing system, or a selection exercise involving several platforms and stakeholders, runs longer. These engagements are deliberately short — the value is in reaching a decision before a deadline or a signature, not in producing a large document slowly.
Rarely, in our experience. A capable supplier is generally comfortable explaining their reasoning, and a review often ends up defending their approach to a nervous client. Where a vendor resists any external examination at all, that reaction is itself information. We can also work from documents alone where the relationship is delicate, without contacting them.
Usually not, though the options narrow. The useful question mid-project is rarely who was at fault — it is what can still be salvaged, what a realistic completion looks like, and whether continuing beats stopping. That comparison is uncomfortable to run internally and straightforward to run from outside, which is most of why it gets avoided.
The decision in one sentence, and whatever exists around it — the proposal, the plan, access to the system, the constraints you are working within. You do not need to prepare a brief or tidy anything up first. Part of the first step is establishing what the real question is, which is not always the one people arrive with.
Listed so you know what exists, not as the next step. Plenty of these engagements end with a recommendation to build nothing, or to build it with somebody else.
Send the proposal, the plan or the question you are stuck on. You will get a fixed fee for a defined piece of advice — and no implementation quote at the end of it.
