Northwind Industrial Supply — Order Management Platform

Northwind asked us one question: why does the Meridian partner integration cost five to seven months when it was expected to take six to eight weeks?

The answer is not that the estimate is wrong. The estimate is approximately correct, and the reason it is correct is the finding of this assessment.

The order management platform works. It processes roughly 2,400 orders a week, has not had an unplanned outage exceeding 30 minutes in the last 14 months, and contains fifteen years of pricing, freight, tax and contract logic that is largely correct. It is not failing. It is not obsolete. It does not need to be replaced.

What it has lost is the ability to absorb change cheaply. Every external integration built since 2019 was added by extending the order pipeline directly rather than by connecting at a boundary. There are now three of them, each slightly different, none isolated. Meridian would be the fourth — but it is the first that requires real-time, bidirectional communication, and the pipeline was built around nightly batch assumptions. The estimate is high because Meridian cannot be added to the current design; it can only be added through it.

Our recommendation: do not rewrite the platform. Build the integration boundary that should have existed, and deliver Meridian through it.

This is not a compromise between rewriting and patching. It is the only sequence that meets the commercial deadline and leaves the system cheaper to change afterwards. Meridian pays for the seam; every integration after it can reuse a boundary that no longer has to be built from scratch.

The patch option is ~$53K cheaper today and leaves you in exactly this position again when the fifth integration arrives — except with four coupled integrations instead of three. We do not recommend it, but we have costed it honestly because it is a legitimate choice if cash is the binding constraint this quarter.

Findings 1 and 3 are addressable in under six weeks and do not depend on the Meridian decision.

A three-week assessment is a bounded diagnostic, not an audit. Being explicit about the boundary is part of the deliverable.

Where a finding below rests on a sample rather than a complete review, we say so.

The platform is a .NET Framework 4.8 application on IIS, running on two application servers behind a hardware load balancer, with SQL Server 2019 on a separate host. Two newer satellite services (notifications, document generation) run on .NET 8 in the same environment. All of it is on-premise.

The technology is not the problem. .NET Framework 4.8 is supported, SQL Server 2019 is supported, and nothing in this stack is forcing a migration on a vendor’s timetable. Anyone who tells you the age of the framework is itself the issue is selling something.

We traced four recent changes through the codebase — a freight rule change, a new customer-tier discount, a carrier rate update, and a tax jurisdiction addition. All four required edits in more than three places.

The pattern is consistent: there is no single authoritative answer to “what does this order cost.” Pricing is computed in at least three locations:

These three implementations agree most of the time. They have diverged twice in the last two years, both times detected by finance during month-end reconciliation rather than by a test.

This is the mechanism behind “small changes require touching half the system.” The system is not tangled arbitrarily. It has three copies of one decision, and every change to that decision has to be applied three times, correctly, by someone who knows all three exist.

This is design debt, not decay. Each duplication was a reasonable local decision — the stored procedure was added for batch performance, the job’s recomputation for a real reconciliation bug. Nobody made a mistake. The cost compounded quietly.

Three external integrations, all built inside the order pipeline, none behind an abstraction.

ERP synchronization — silent failure. A nightly job consumes a flat file of inventory and price updates. When the file is malformed or absent, the job logs a warning and exits successfully. Inventory then serves stale figures until the next successful run. We found four occurrences in the 30-day log window. In two of them, the first detection was a customer ordering an item that was not in stock.

Carrier API — vendor-driven fragility. The endpoint URL and API version are compile-time constants in three places. The carrier deprecated the version currently in use with an announced sunset. More significantly, the retry wrapper catches Exception, logs at Debug level, and returns a default rate. A rate lookup failure is therefore indistinguishable from a successful lookup that returned the default.

Payment provider — synchronous coupling. The credit check is a blocking call inside order submission with a 30-second timeout, no circuit breaker, and no queue. When the provider is slow, order submission is slow; when it is down, orders cannot be submitted at all. This has happened once in 14 months, for 40 minutes.

Each integration is individually repairable. The reason we treat them as one finding is that they are three solutions to the same problem, and none of them is reusable. Meridian would be the fourth.

The releases succeed. That is worth stating plainly — this is a disciplined manual process performed by someone competent. But the capability lives in one person’s working memory, the rollback path is slow enough that nobody wants to use it, and the 3-hour window is a structural reason the team batches changes into large, riskier releases every 3–4 weeks instead of shipping small ones.

Deployment friction is a change-cost multiplier. It does not appear on any estimate, and it inflates every estimate.

Three areas have a single knowledgeable owner: the release process, the ERP synchronization job, and the freight rate engine. In each case, one person can explain how it works and no written material would let a competent engineer reconstruct it.

We raise this as a technical finding because it directly affects change cost. Every change touching those three areas is scheduled around one person’s availability, and two of the four changes we traced had waited on exactly that.

Ranked by expected cost of inaction, not by severity of the underlying defect.

Findings 1, 5, 6 and 7 are inexpensive and independent of the Meridian decision. They should proceed regardless of what leadership decides about the platform.

Leadership is weighing three options: patch Meridian, modernize incrementally, or rebuild the platform. We were asked to give a view. Do not rebuild it.

We are not arguing that the platform is good. We are arguing that a rewrite solves a problem Northwind does not have while creating one it cannot absorb.

What a rewrite would discard. The valuable asset in this system is not the code, it is fifteen years of encoded commercial reality — contract pricing tiers, freight rules with genuine exceptions, tax jurisdiction handling, credit terms, and several hundred behaviours that exist because a customer once complained. None of it is documented. Most of it is only discoverable by reading the code that implements it. A rewrite does not port this; it re-derives it, in meetings, from people who will remember it incompletely.

The failure modes are asymmetric. The current system’s worst case is “change is expensive.” A rewrite’s worst case is “there is no working order system, and the old one has been frozen for eighteen months.” The first is a cost. The second is an existence risk for a business running $41M of GMV through this platform.

The timing is disqualifying. Meridian is commercially committed with a deadline roughly five months out. A rewrite is 18–30 months on our estimate. Any rewrite plan requires building Meridian into the legacy system anyway — which means paying the full integration cost and the rewrite cost, and then building Meridian a second time.

Basis for the rewrite estimate. This is an order-of-magnitude figure intended to establish scale. It is not an implementation estimate and should not be planned against.

At 6–8 engineers and ~140 productive hours per engineer-month, that is 18–30 months elapsed.

The dominant uncertainty is the characterization line, and it is worth being explicit about why: the cost of rewriting this system is driven less by writing code than by discovering what the current one actually does. That work has no shortcut and it cannot be parallelized across a large team.

The conditions that would justify a rewrite are absent. We would change this recommendation if the platform were unstable in the core path, if the stack were out of vendor support, if the domain had fundamentally changed, or if the team could not safely make changes at all. None of those are true. What is true is that a specific, identifiable part of the design — the integration boundary — is missing.

That is a repairable defect, not a reason to start over.

The objective is not to modernize the platform. It is to make the parts of it that the business changes most often cheap to change, and to leave the rest alone.

Three interventions, in priority order.

Correlation IDs through the order path, structured logging, explicit success/failure signalling from the ERP job with alerting on non-success, explicit capture and quarantine of failed integration work with a path to replay it, and removal of the exception-swallowing retry wrapper in the carrier client.

We are deliberately not prescribing a mechanism here. The current integrations are a nightly file job and two synchronous HTTP calls; there is no message infrastructure to build on, and introducing one before the boundary exists would be solving the wrong problem first. If Phase 1 introduces messaging at the boundary, a dead-letter queue becomes the natural implementation. Until then, a quarantine table and a replay command are sufficient and considerably cheaper.

This does not fix any integration. It means you find out before your customers do. It is the highest ratio of value to effort in this document.

Introduce an explicit integration layer: a defined contract for what an external partner can do (inventory query, order submission, status notification, pricing agreement), adapters implementing that contract per partner, and a translation boundary so partner-specific formats never enter the order pipeline.

Meridian is built as the first adapter. This matters commercially: the seam is not a separate modernization project requiring its own justification — it is the shape the Meridian work takes. The budget is Meridian’s budget.

Migrate the three existing integrations behind the boundary afterwards, one at a time, starting with the carrier client (which has a forced deadline from the announced API sunset anyway). Do not migrate all three before Meridian ships. That inverts the priorities and puts the deadline at risk.

A build and release pipeline, scripted and versioned database migrations, one-command deploy to both servers, an automated smoke test, and a rollback that takes minutes.

This is not glamorous and it is not on the critical path for Meridian, which is exactly why it should run in parallel with a separate owner. It removes the single-person dependency, shortens the release window, and — the real benefit — makes small releases cheap enough that the team stops batching a month of changes into one risky Sunday night.

Collapse the three pricing implementations to one authoritative path, with the other call sites delegating to it.

We are deliberately separating this from the first three. It is the most valuable structural improvement in the document and the least urgent. It is also the one most likely to surface behaviour differences that require commercial decisions rather than technical ones — the three implementations disagree in edge cases, and someone in finance will have to say which is correct.

Do not start this until Meridian has shipped. It needs the team’s full attention and it should not compete with a committed deadline.

The Meridian deadline is the forcing function. This sequence delivers it with buffer while leaving the platform structurally better.

Meridian is live in week 16 against a week-22 commitment. Phases 0 and 2 are independent of the Meridian decision and can start immediately.

Phases 3 and 4 are deliberately beyond the deadline. Committing to them now, before Meridian has shipped, is the most common way this kind of plan fails.

Effort in engineer-hours. Ranges reflect genuine uncertainty, not padding.

How to read the cost column. Figures normalize internal and external engineering effort at a blended $110/hr so the options can be compared on a single scale. This is engineering-equivalent delivery cost, not incremental cash expenditure. If Phase 0 and Phase 2 are absorbed by existing salaried engineers, their cash impact is close to zero and their real cost is the other work those engineers do not do. Actual budget impact depends entirely on the internal/external mix, which is a decision Northwind has not yet made. Substitute your own blended rate.

The recommended path costs roughly $53K more than patching, in engineering-equivalent terms. What that buys: Meridian delivered with schedule buffer instead of schedule risk, future partner integrations implemented against a reusable boundary rather than rebuilt through the order pipeline, integration failures that announce themselves rather than being reported by customers, and a release process that does not depend on one person’s calendar.

We have deliberately not put a number on the cost of a future integration. The saving is real — the boundary, contract and adapter framework are built once, at roughly 220–280 of Phase 1’s hours — but the size of the saving depends on the functional scope of whatever partner comes next, and we have no candidate to scope against. A figure here would be a guess wearing a decimal point.

The largest single risk to this estimate is Meridian’s own API. Our Phase 1 range assumes documented endpoints, a usable sandbox, and a responsive counterpart during integration testing. We have not seen their documentation. If their API is undocumented or their sandbox is unreliable, Phase 1 moves toward and possibly past the top of the range. We recommend obtaining and reviewing their API documentation before committing to a delivery date — this is a two-day exercise that materially de-risks a five-month commitment.

Stated plainly, because “do nothing” is a real option and deserves an honest forecast rather than a scare.

The platform will keep working. It is stable and it is not degrading on its own.

What continues: Meridian costs 5–7 months and arrives late or over budget. The fifth integration costs the same again. Integration failures continue to be discovered by operations staff and occasionally customers, at the current rate of roughly one every eight days in the log window we reviewed. Pricing divergence remains a month-end reconciliation risk. The carrier API sunset arrives on the vendor’s schedule and becomes an emergency. Release capability remains attached to one person.

None of these is a crisis. That is precisely what makes this decision easy to defer — and deferral is how a system that merely became expensive to change eventually becomes one that cannot change at all.

Things we could not verify in three weeks that would change parts of this document.

This assessment is delivered with a live session, structured for both audiences.

Part 1 — Leadership (45 min). The decision, the three options and their costs, why we recommend against a rewrite, what happens to the Meridian deadline under each. Questions.

Part 2 — Engineering (75 min). Findings in detail, the integration contract design, phase sequencing, estimate assumptions, and where we think we might be wrong. Bring the release engineer and whoever produced the Meridian estimate.