Why not LEAN, and why not build it yourself

Two questions come before every other one: why not use LEAN, which is open source and free, and why not build this in-house, which most of the people reading this could do. Both are fair, and both have honest answers — including the parts where the other option wins. Those parts are stated first.

Why not LEAN?

What LEAN does better

It is open source, so its future does not depend on any one vendor staying in business — the single strongest argument against buying from us. It has years of public use and a community you can ask. It ships broker and market-data integrations we do not have. It offers a hosted research environment with notebooks, charts and a data library attached. It costs nothing to run yourself. If those are the deciding factors for you, use LEAN — we would rather say so here than take up your evaluation.

Platform or component — the difference a feature table cannot show

LEAN is a platform: your strategy lives inside its process, its lifecycle and its conventions. This is a library: it lives inside yours. It does not own your main loop, your data path, your threading model or your deployment. That one difference decides everything downstream — where the code runs, what it links against, what has to be true before your risk officer signs it off.

Written in C++, for programs already written in C++

If your production path is C++ — because of latency, because of an existing stack, because of the people you hire — then adopting a C#-hosted platform is not the small decision it looks like. Here the engine is a library your program links: a C ABI, a C++ surface and a Python module over the same core. Research in Python and production in C++ are the same engine, not two implementations that have to be kept in agreement.

Measured, not asserted

Performance claims are cheap and we treat our own the same way. The connection library's numbers are published with the method and the machine. The engine's own traversal numbers are not published, because the report does not exist yet — and we say that instead of rounding something up.

Correctness that has to be demonstrated

A wrong backtest still prints a profit, and nothing on its surface tells you which one you are holding. The invariants underneath — position through a reversal, average cost, exposure at the instant of the fill, the order refused before it is sent, a simulator that cannot see the future — are each pinned by a test that fails the moment the invariant does.

Nothing leaves

There is no account to open and no data to upload. The engine reaches Solo 76 once every few days to check its licence, carrying a licence identifier, a machine fingerprint and a count of running robots. Which AI you use, local or public, is your connection and your decision, not ours.

Why not build it yourself?

You probably can. That is not the question.

Most people who evaluate this engine could write one. The question is not whether the team is capable — it is what the thing costs after the first version works, and that is systematically underestimated, because the hard part is invisible from the outside.

It is not what your firm is paid for

A trading team is paid for two things: finding strategies that hold up, and pricing the risk it takes. Everything else is overhead that simply has to exist. Position accounting, cost basis, exposure snapshots, fill semantics and the statistics that make two candidates comparable all sit in that second category — indispensable, invisible, and identical at every firm that has ever built them. No one has ever won a mandate for having a better ledger. The hours your researchers spend making one correct are hours not spent on the only two things the market pays for, and they are the most expensive hours in the building.

The bill nobody quotes

Position accounting that survives a reversal. The average cost a realised profit is measured against. An exposure snapshot taken at the instant of the fill and not a tick later. The order that has to be refused before it is sent rather than explained afterwards. Two feeds whose timestamps must line up. A simulator that must not accidentally see the future. Each of these is an afternoon to implement and a quarter to trust — and until it is trusted, every number your firm makes decisions on rests on it.

It does not stop when it works

An engine is not a project with an end. Every new instrument type, venue quirk, corporate action, fee schedule and clock discrepancy is a change to a system where a silent error does not crash — it prints a profit. That maintenance is permanent, it lands on your most expensive engineers, and it competes directly with the work that actually makes money.

When building it yourself is the right answer

If you trade one asset class, on one venue, with one shape of strategy, and you are confident there will not be a second of any of those, then a small in-house engine you fully control is cheaper and better than anything you can buy, this included. The economics change the moment the second one appears, because the cost of an engine is not in writing it — it is in generalising it without breaking what already worked.

Already building one? Run on this while you finish

The two are not in competition on a timeline. Teams who have already started their own engine put this one underneath in the meantime, so candidates keep being measured and risk keeps being checked instead of waiting on an internal milestone. Because this is a library and not a platform, nothing you build around it is wasted when you switch: the data, the connections, the deployment and the strategies were yours throughout, and replacing the piece in the middle is the whole of the migration. Think of it as the courtesy car while yours is in the workshop — and if you decide to keep driving it, that works too.

It is not either/or

This is a library, not a platform, so the parts you insist on owning stay yours. Your data, your connections, your deployment, your monitoring, your research tooling and the strategies themselves do not move. What you stop writing is the piece in the middle that has to be right and gives you no advantage for being yours.

What if Solo 76 goes away?

Source-code escrow, on request

It is the right question to ask a small vendor shipping binaries, and open source does not have to answer it — a real advantage we are not going to pretend away. Our answer is source-code escrow: on request we place the source of the engine, and everything needed to build it, with an independent escrow agent, to be released to you if Solo 76 ceases to trade or ceases to support the product. Because the engine also validates its licence periodically, the deposit is written to include the means to keep your systems running without that validation — a release event must not be the day your production stops. Ask, and we will set it up.

See the measured numbers Browse robot examples Questions and answers