Do you need to know whether the system you were quoted is the right one?
Review of architecture, cost, and vendor proposals before the money is committed. Independent, specific, and written down.
The problem
A proposal arrives with a confident architecture diagram, a price, and a timeline, and the people who have to approve it cannot tell whether it is right. The vendor is not lying, but they are answering the question they know how to answer. Common results are a system three times larger than the problem, a licence model that gets expensive exactly when the business grows, or a design that quietly assumes the hard part will be handled later.
How we approach it
We read the proposal against the problem it is meant to solve, not against best practice in the abstract. We check the numbers — users, data, throughput, cost over five years — and the assumptions that were not written down. Where something is wrong we say what and why, and what to ask for instead. Where the proposal is good we say that too; the value is in a clear answer, not in finding fault.
Worked example
A quote reviewed, a scope halved
A logistics company had a proposal for a warehouse management system priced for 40 sites over five years. They had six sites and no concrete plan for the rest. We reviewed the architecture and the licence terms and found that two-thirds of the cost bought capacity they would not use before the contract ended, and that the integration with their accounting system — the part that actually mattered — was listed as a later phase with no price. The revised scope covered the six sites, priced the integration first, and kept an option for expansion. The vendor stayed the same; the contract was about half the size.
What you get
- A written review of the proposal against your actual problem and numbers
- A list of specific risks, gaps, and unpriced assumptions
- Concrete questions and changes to take back to the vendor
- A recommendation you can act on, including when it is to proceed as quoted