Build or buy: how to actually run the numbers

The naive version of this decision is a monthly fee against a one-off quote, and over twelve months the subscription usually wins. That arithmetic is correct and incomplete.

Where buying is genuinely right

We say this first because it is often true and it is the answer that costs us work. Buy when:

• The strategy is standard and mechanical — grid, DCA, simple trend following on a liquid pair. These are solved problems and someone has solved them adequately.
• The capital at risk is small enough that a development budget cannot be justified against it.
• You are still exploring. Paying to find out whether you like automated trading is cheaper than commissioning a system to find out the same thing.
• Time to first trade matters more than fit.

If three of those describe you, stop reading and go buy something. Come back when one of them stops being true.

Where buying breaks down

The last row is the one specific to trading and it is easy to underweight. A bought strategy is a shared strategy — see why the bot you bought does not work.

The honest cost comparison

Over a three-year horizon, count everything on both sides:

1. Buy. Subscription × 36, plus any performance fee, plus the cost of workarounds where it does not fit, plus the migration cost when you eventually outgrow it or the vendor shuts down.
2. Build. Development, plus infrastructure (a VPS is small money), plus maintenance for exchange API changes, plus the changes you will want in year two.

The item people forget on the buy side is the workaround cost — the trades you do not take because the platform cannot express them, and the manual steps you perform around its limitations. It is invisible on an invoice and often the largest line.

The item people forget on the build side is maintenance. Exchanges change APIs. Budget for it rather than being surprised by it.

The middle path we usually recommend

Rarely all-or-nothing. A sequence that works:

1. Start with something off-the-shelf to establish whether automated trading suits you at all. Cheap, fast, and the answer is genuinely useful.
2. When you hit its limits, write down exactly what you could not do. That list is the specification for the custom system, derived from experience rather than imagination.
3. Build the piece that matters most — usually execution and risk — and keep the rest simple.
4. Add strategies as modules against infrastructure you now own.

The question that decides it

One question cuts through most of the analysis: how often will you want to change the rules?

If the answer is rarely, buy. Standard tools handle standard strategies well and you gain nothing from ownership you will not exercise.

If the answer is constantly — because you are still learning what works, because the market keeps moving, because your edge is in adaptation rather than in one fixed rule — then you need something you can change without asking permission. That is what building buys you, and it is worth more than the feature list.