What the build estimate always misses
The first 80% of the work is a demo. Orders go out, fills come back, everyone is pleased. That 80% is the broker client. The last 20% is the layer, and it is the part that never ends. Rejected orders with undocumented causes, and no record that the instruction existed before the rejection. Websockets that drop mid session and take your fill events with them, and nothing durable to reconcile against. Positions that drift from what the broker says, discovered at the worst moment. A retry that double-sends because nothing made submission idempotent. A replace that silently loses the original quantity. Risk checks you keep meaning to write properly. Broker API changes that land on their schedule, not yours. None of this appears in the original estimate, because the original estimate described software and this is an operation. Software gets finished. Operations get staffed.Put rough numbers on it
Run the back of the envelope math for your own team. A capable engineer costs somewhere north of $200,000 a year fully loaded. A serious first version takes months, not weeks, once the order lifecycle, reconciliation, monitoring, and failure handling are real. After launch, maintaining the layer quietly eats a meaningful slice of someone’s time forever, and doubles the day you add a second broker, because now there are two sets of formats, error codes, and quirks to keep aligned underneath it. Then add the cost that never shows up on a spreadsheet: every hour spent on the layer is an hour not spent on the strategy, and the strategy is the only part that makes money. For a small team, that opportunity cost dwarfs the salary math.What buying actually gets you
An order and execution management layer as an API. Anthid is one example. You describe the outcome you want as an intent; Anthid records it before contacting the broker, in the same transaction that queues it, checks it against your pre-trade controls, routes it, and streams back what happened. Dispatch state and fill state are reported separately, so sent is never read as filled. Amendments are kept as sequenced history, and everything lands in a durable ledger that is retained for six years. Trading windows and order size limits are enforced before an order leaves, and every refusal is recorded. The broker sits behind that layer. Lightspeed is connected today, and the instruction is expressed in Anthid’s terms rather than the broker’s. You also inherit numbers a small team rarely reaches alone: 99.99% uptime and median order acknowledgement of 42ms, with someone else carrying the pager.Those numbers describe how the platform has been running, not a commitment. The connected broker integration is in beta, and a broker integration carries no service level commitment. See Service levels.
When building still wins
Sometimes it does, and pretending otherwise would be silly. If you run a large firm with a dedicated platform team, colocated hardware, and latency requirements measured in microseconds, the execution layer is part of your edge and you should own it. The same goes if your strategy depends on broker behavior so unusual that no shared platform will model it. Those cases are real. They are also rare, and most teams citing them are three people with a Slack channel named #infra.How to decide in an afternoon
You do not need a committee for this one. Take a strategy you already have, point it at a managed platform’s paper trading tier, and see how far you get before dinner. Anthid’s free tier needs no credit card and no sales call. If you ship a working paper strategy in an afternoon, you have your answer, because the build option cannot even schedule its kickoff meeting that fast.Quickstart
Create your first intent against a paper account.
CREATE instructions. They do not reevaluate replacements or cancel resting orders. HTTP create retries are not deduplicated; reconcile an uncertain submission before retrying. See Intents for the current contract.