Engagement

Technical Systems Assessment

$15,000

Fixed. No hourly billing.

3 weeks

Written output · executive + technical walkthrough

A bounded diagnosis of why a system has become expensive to change, and a costed plan for what to do about it.

Start a conversation Read a complete example

Engineering says five months. You expected six weeks.

Both of you are probably right, and that is the problem.

Estimates like that are rarely a sign that someone estimated badly. They are usually the first visible symptom of something structural — a system that still works, still makes money, and has quietly stopped being able to absorb change at a reasonable price.

An estimate that doesn’t make sense: A change that sounds small comes back priced like a project. Nobody can quite explain the gap, and the explanations that do arrive are about the codebase rather than the business. Meanwhile a commitment has already been made to a customer, a partner, or a board.
Every integration feels bespoke: You have connected three or four external systems and each one was built from scratch. Nothing was reused. When one breaks, the person who wrote it fixes it. Failures are often discovered by operations staff or, worse, by a customer.
The rewrite argument nobody can settle: Engineering wants to rebuild. Finance wants a number. Nobody can say with confidence whether the current system is genuinely at its limit or whether it just needs a few specific things repaired — so the decision keeps getting deferred, which is itself a decision.

Is this system worth continuing to invest in, and if so, what exactly should be changed first?

That is what this engagement answers.

A diagnosis, not an audit and not a proposal

Most technical reviews fail in one of two directions. Either they are a two-day skim that produces a slide deck of generic observations, or they expand into an open-ended consulting engagement that becomes its own project before it has told you anything.

This is deliberately neither. It is a bounded diagnostic with a fixed scope, a fixed duration and a fixed price, aimed at a decision you have to make.

It is scoped to your actual question: We are not cataloguing everything wrong with your system. We are establishing why change has become expensive and what it would cost to fix.
It is not an exhaustive code audit: Three weeks does not buy line-by-line review of a large system, and any firm that says otherwise is either not reading the code or not telling you the truth. We go deep on the paths that matter and we tell you exactly what we did not examine.
It is not a sales document: The recommendation can be to do less. A credible assessment may conclude: do not rewrite this, do not migrate frameworks yet, do not move it to the cloud, do not buy another platform.
It is conducted personally by Dorian Ben Haim: Systems that have become hard to change are rarely broken in one layer, which is why a review that can only see one layer tends to recommend replacing everything.

What happens across the three weeks

Week one
Access and orientation
Stakeholder sessions with the people who actually know: engineering leadership, the engineers in the system daily, whoever performs releases, and the operational staff who deal with the consequences when something fails. In parallel we get access to the code, the database, the deployment process and recent logs, and we read.
Week two
Investigation
We trace real changes through the system — recent ones, and the one you are currently trying to price — to establish where the cost actually accumulates. We read the integration implementations in full, review the deployment path, and reconstruct the estimate that brought you here so we can say specifically why it is what it is.
Week three
Analysis, costing and delivery
Findings, options, recommendation, sequenced roadmap and effort model, written up. Then a live walkthrough in two parts: 45 minutes with leadership on the decision and its cost, and 75 minutes with engineering on the findings, the design, and where we think we might be wrong.

What we need from you: access to the relevant code, database and schema, logs and deployment materials; whatever documentation exists, however incomplete; a small number of focused stakeholder sessions across engineering, operations and the business owner of the problem; and, where available, a non-production environment.

What you receive

One document, written to be genuinely usable by two audiences who need different things from it. A CTO should find it technically credible enough to argue with; a CEO or CFO should be able to authorise or decline the investment from it without needing anything translated.

Current-state assessment: What exists, where change is difficult, and the specific mechanisms causing it
Risks and constraints: Architecture, technical debt, integration dependencies, deployment risk, operational bottlenecks, and knowledge concentration where it materially affects delivery
Target-state recommendation: What should change — and explicitly what should be left alone
Sequenced roadmap: Phases, dependencies, priority, and what deliberately waits
Cost and effort model: Ranged effort estimates with stated confidence, costed clearly enough to support a funding decision, and honest about which numbers are order-of-magnitude rather than plans
Architecture diagrams: Where they clarify something. Not as decoration
Scope statement: What we examined and what we did not, stated plainly

If you take this report to a different firm and successfully execute from it, you got exactly what you paid for.

The assessment fee is not a deposit and does not come off a later project. Some firms will offer you that. It is a discount, and it quietly tells you what they think the diagnosis was worth.

That standard is not rhetorical, it is a design constraint. It is why the roadmap is sequenced with dependencies rather than vaguely phased, why the effort model carries ranges and confidence levels, and why the recommendation is specific enough for someone else to price.

See a complete one

Every section, at the depth we actually write to. A fictional 120-person B2B company with a seven-year-old .NET order management platform, three brittle integrations, a manual release process, and a partner integration priced at five months against a six-week expectation.

It reaches a conclusion that mature legacy systems often warrant: do not rewrite the platform.

The company is invented. The standard of work is not.

Read the example assessment

When not to buy this

A diagnosis is only worth paying for when the answer is genuinely unknown.

You already know what needs building: If the problem is well understood and scoped and you need it delivered, skip this. Implementation engagements typically start at $25,000.
You need a decision validated rather than examined: If a rewrite has already been approved and what you want is a document supporting it, we are the wrong firm — there is a reasonable chance this recommends against it, and that would be an expensive way to be annoyed.
The system is actively failing: Outages, data loss or a live incident need stabilisation first. Diagnosing change cost while production is on fire is the wrong order of operations.
There is no system yet: Build-versus-buy for something that does not exist is a different question and this is not the instrument for it.
The system is small enough to hold in one head: If a competent engineer on your team could explain the whole thing in an afternoon, you probably do not need three weeks of external investigation.