Skip to content
AnithraSolutions
Practice · 7 min

What a two-week diagnostic actually finds

Anonymised findings from twelve engagements: the failure patterns that recur, the ones nobody expects, and why the fix is usually smaller than the fear.

Published 14 February 2026By the Anithra Solutions engineering team

We start most engagements with a paid two-week diagnostic. Two engineers read the code, interview the people who operate the system, and produce an architecture record, a risk register and a costed plan. Clients keep it whether or not they continue with us.

Across twelve of those, the findings cluster more tightly than we expected. Anonymised, here is what recurs.

The problem is rarely the one in the brief

Eight of twelve briefs described a performance or scaling problem. In six of those, the actual constraint was a data model that forced expensive queries, not infrastructure. Adding capacity had been tried and had produced a proportional increase in cost with a sub-proportional increase in throughput — which is the signature of this failure.

Recurring findings

  • No environment that resembles production. Staging with a thousand rows tells you nothing about a table with two hundred million.
  • Observability that reports uptime rather than correctness. Every service green while orders silently fail a business validation.
  • A single person who understands the deployment. Usually the same person named in every incident review.
  • Retries without idempotency. Duplicate charges, duplicate emails, duplicate inventory movements — always discovered by a customer.
  • Test suites with high coverage and low value, exercising code paths rather than behaviours.

The one nobody expects

In four engagements the most valuable finding was that a planned project should not happen. A replatform that would have cost seven figures was replaced by six weeks of query and index work plus a caching layer. A microservices decomposition was deferred indefinitely in favour of fixing the deployment pipeline that had motivated it.

The best outcome of a diagnostic is often a smaller project. That is inconvenient for a firm billing by the month, which is exactly why we charge for the diagnostic separately.

Why two weeks

One week is enough to read the code and not enough to talk to the people. Four weeks produces a longer document without changing the conclusion. Two weeks consistently lands where the findings stabilise — the second week mostly confirms and quantifies what the first week suspected.

Working on this?

We run a paid two-week diagnostic that ends with an architecture record, a risk register and a costed plan — yours to keep either way.

Talk to an engineer

Let's find out whether we're a fit.

Thirty minutes with an engineer who has shipped this before — not a salesperson reading a deck. You leave with a straight answer about scope, cost and timeline, whether or not you work with us.

Prefer email? sales@anithrasolutions.com · We reply within one business day