Wialon Consulting

Three situations account for most engagements. An integration that used to work has started dropping records, and nobody can say when it began. A build is halfway done and the estimate has stopped meaning anything. Or a decision is on the table — dual-stack, self-hosted, rebuild versus repair — and the team wants a second opinion from someone who has shipped the thing before.

None of these are solved by a strategy document. Each needs someone reading the actual sync logs, the actual API usage, and the actual failure timestamps, then writing down what is broken in the order it should be fixed.

A review is two weeks, not two months. The first week is evidence: data flows traced end to end, API usage measured against limits, failure points reproduced rather than theorised about, and the mapping between systems written down as it actually is rather than as the documentation claims.

The second week is the plan. Findings are split into stability fixes that can ship immediately and architecture changes that need sequencing, each with the cost of doing it and the cost of not doing it. The output is a document your engineers can execute without us, and an honest statement of which problems are worth leaving alone.

A rewrite is the most expensive recommendation available, and it is right less often than it is proposed. Most fragile integrations are structurally fine and failing on four or five specific things: no idempotency, no reconciliation, retries without backoff, mapping scattered across files, alerts with no owner. Those are days of work, not quarters.

We recommend a rebuild when there is a hard blocker — a data model that cannot represent the business, or a coupling to a system being retired anyway. Otherwise the sequence is stabilise first, then improve the architecture incrementally while the system keeps running. Teams that arrive after a failed rewrite usually needed the first path.

The review document, the runbooks for the failures that actually occur, the alert routing with named owners, and pull requests reviewed alongside your engineers rather than delivered over the wall. The goal is a team that does not need to call us again for the same class of problem.

Where the review turns into implementation work, it usually lands as an integration rebuild of one flow, a data pipeline to get analytics off manual exports, or — where the ceiling is the platform rather than the code — a dual-stack design.

A review that only produces more work to buy is not a review. Some of the most useful outcomes are the ones that shrink the scope: an integration that is fine as it stands and needs monitoring rather than rebuilding, a real-time requirement that costs more than the problem it solves, a second platform that would add operating cost without answering a question you actually have.

We say so plainly, and in writing, including where that means a smaller engagement than the one you asked about. The reason is self-interested as much as principled — a project sold past the point of value is a reference we do not get to use, and in a market this small, references are how the next project arrives.