A decision before the work
Technical assessment and consulting
An assessment is rarely commissioned because someone wants a document. It is commissioned because a decision is pending: rebuild or repair, change supplier or stay, start now or wait. That kind of decision needs an impartial view, which is why this work is separated from implementation. If the conclusion is that the existing system is adequate, or that the work is not worth starting, then that is the conclusion — a common and entirely reasonable outcome.
Discuss an assessment scopeIn short: what this is and is not
This is an assessment and a recommendation, not the start of work. You receive an answer to a specific question, the reasoning behind it, and the alternatives with their risks — in a form someone who does not work with technology daily can decide from. Implementation is a separate decision and you can take it to anyone. The assessment is not part of a proposal and not a sales conversation with a document attached.
When an assessment is the right fit
- A choice has to be made between repairing the existing system and rebuilding, and the two sides weigh the risk differently.
- You are taking over a system whose history nobody knows and need to understand what is in it.
- Before a larger investment you want an impartial view from someone who will not be delivering it.
- There are recurring faults or performance problems, but it is unclear whether the cause is architecture or usage.
When something simpler is enough
- The problem is already known and clearly defined — an assessment would only delay a decision you can take now.
- You need continuing work on an existing system — maintenance and support fits better.
- The question is about search visibility — SEO work fits better, and includes the technical check already.
From decision to conclusion
An assessment is scoped by the decision you need to make rather than by a checklist. Below are illustrative examples. This is not a price list and not a promise about what the conclusion will say — that depends on what is found.
| Decision you need to make | What is examined | What you receive |
|---|---|---|
| Repair or rebuild | The state of code and data, dependencies, and how much of the system can be separated and replaced in stages. | A recommendation with stages, and the conditions under which rebuilding is justified and when it is not. |
| Whether to take over an unknown system | What is in the code, which accesses and rights exist, and what is missing to make it maintainable. | A list of takeover conditions and known risks, including those we cannot resolve. |
| Why the system struggles | Performance and stability behaviour, database usage, and where the time is actually spent. | Causes ranked by impact, separating architecture from configuration and from how it is used. |
| Whether the technical state allows being found | Indexing obstacles, URL structure, redirects, duplication, response time. | Obstacles ranked by importance; if there are none, that is also a conclusion. |
| Whether the plan is feasible at all | Scope, assumptions, third-party dependencies and what happens if they do not hold. | An impartial judgement, including a recommendation not to start, or to start smaller. |
How the work runs
- 01
Defining the decision
We first agree which decision the assessment must support and who will take it. Without that, an audit becomes a list of general observations nobody uses. This step also records what the assessment will not cover.
- 02
Review with access
We review the code, the data structure, the environments and how the system is used day to day. We talk to the people who use it — some of the most important facts are not visible in code. Access is requested only as needed and returned when finished.
- 03
Conclusion and alternatives
We describe what was found, what it affects, and the available options with their risks and approximate scope. Alternatives are described honestly, including doing nothing and choosing a different supplier where that would be the better answer.
- 04
The decision conversation
The conclusion is presented in language the decision-makers can question, not only read. Implementation is not part of this work and not its purpose; if you decide to hand it to us, that is a separate agreement.
What drives cost and duration
- How specific the decision is — one clear question is assessed considerably faster than a general state review.
- The size of the system and whether documentation exists; without it, most of the time becomes investigation.
- Whether access and conversations with users are possible, or the assessment is from code only.
- Whether data quality has to be assessed, or a structural review is enough.
- Whether the conclusion has to be presented to a wider group, or a document is enough.
Worth considering before we talk
- 01Which decision has to be made, and by when?
- 02Who will take the decision, and what information are they missing?
- 03Can access to the code and environments be granted for the assessment?
- 04Who uses the system today, and who can we talk to?
- 05Which option do you already consider most likely, and why?
Let us scope the assessment
Describing the decision you need to make and who will take it is enough. If it turns out no assessment is needed because the answer is already known, we will say so.