What you'll take away

  • The prototype is the cheap 20%. Scale, validation, audit, and multi-year maintenance are the expensive 80% that never shows up in the original estimate.
  • Build the alpha; buy the commodity. Your edge is your strategy and your client relationships, not the plumbing that every competitor also needs.
  • The real comparison is total cost of ownership over years, including the senior-engineer attention that an in-house stack quietly consumes forever.

The build-versus-buy conversation usually goes wrong because both sides argue about the wrong thing. The build camp points at the prototype and says, correctly, "we can do this." The buy camp points at the vendor demo and says, correctly, "so can they." Neither statement settles anything, because the question was never whether an optimizer can be built. The question is what it costs to own one — to keep it correct, fast, scalable, auditable, and staffed — across the years you will actually depend on it. That is a total-cost-of-ownership question, and TCO is where in-house builds quietly hemorrhage.

The iceberg under the prototype

Consider what the prototype does not yet do. It does not scale to the whole book under a deadline — that is a different and much harder engineering problem than solving one account. It has no rigorous validation against a known-good reference, so nobody can yet prove its answers are correct, which means compliance cannot sign off. It produces results that may not be reproducible run-to-run, which is a quiet disqualifier the first time an auditor asks why two identical accounts traded differently. It has no handling for the thousand edge cases real data throws — corporate actions, halted securities, missing prices, odd constraint combinations — each of which is a 2 a.m. page until it is handled. And it has no one whose job is to keep all of that working as markets, regulations, and the book evolve.

Figure 1 — Where the cost actually sits

Prototype (one account works)
~the easy part
Scale to the whole book
hard
Validation & audit trail
harder
Years of maintenance
forever

The visible cost is the prototype. The real cost is the tail — and the tail consumes your most senior, least replaceable engineers.

The hidden line item: senior attention

The most expensive resource an in-house optimization stack consumes is not cloud spend or solver licenses, painful as those are. It is the attention of the few engineers who actually understand it. A home-grown optimizer becomes load-bearing the moment it touches production, and load-bearing systems demand their authors. Those authors are precisely the people you most want building the things only your firm can build — your strategies, your client experience, your differentiated research. Every quarter they spend nursing the optimizer through an edge case or a scaling crisis is a quarter they are not spending on your actual edge. That opportunity cost never appears on an invoice, which is exactly why it is so dangerous.

There is also a key-person risk that compounds over time. The stack ends up encoding years of hard-won, undocumented knowledge in the heads of two or three people. When one of them leaves, the firm discovers how much of its production infrastructure was actually a person, and the cost of that discovery arrives at the worst possible moment.

The honest case for building

None of this means building is always wrong. Build when the optimizer is your edge — when the way you solve the problem is itself the proprietary advantage you sell, and owning every line is the point. Build when your requirements are so unusual that nothing on the market fits. Build when you have the rare, durable engineering depth to treat infrastructure as a first-class, permanently staffed product rather than a project that ships once and then rots. These are real situations, and firms in them should build with their eyes open.

But for most firms, the optimizer is not the edge — it is the commodity infrastructure underneath the edge. The strategy is proprietary; the constrained, tax-aware, deadline-bound solver that executes it is something every competitor also needs and none of them should be reinventing. The clean principle is the old one: build the alpha that is yours, buy the infrastructure that is a commodity to own internally. The firms that get this right spend their scarce senior-engineer attention on what differentiates them and let a productized, tested, supported engine carry the plumbing.

The fair way to settle it is a head-to-head on your own data. Run a productized engine against your in-house stack, same universe and constraints, and compare total cost and outcome honestly.

Request a pilot →

The decision deserves an honest TCO model, not a prototype demo. Add up the scaling work, the validation work, the audit work, the edge-case work, the years of maintenance, and — above all — the senior attention diverted from your real differentiators. Then compare that to the cost of buying infrastructure that already does those things and comes with someone whose entire job is to keep it working. For most firms, run honestly, the math is not close.

References & further reading

  1. F. Brooks, The Mythical Man-Month — the classic on why software estimates underprice the hard 80%.
  2. Asymmetry Computing, The overnight batch: pricing a whole book before the open.
  3. Asymmetry Computing, Determinism, reproducibility, and the coming audit standard.