Why nobody honest guarantees trading profit
We guarantee that the software behaves as specified. We do not guarantee what the market does with it. Anyone collapsing those two is selling something other than software.
Vizanix engineering · about the author
- SECTION
- Why and when
- PUBLISHED
- 2026-08-30
- CHAPTERS
- 5
- READ NEXT
- 3
- LANGUAGE
- written in English
This comes up in almost every first conversation, usually phrased as “what results can you promise?”. It is a fair question with an uncomfortable answer, and the reasoning is worth setting out properly rather than hiding behind a disclaimer.
Two different things get called a guarantee
| Software warranty | Profit guarantee | |
|---|---|---|
| What is promised | The system does what the spec says | The market produces a return |
| Who controls it | The developer | Nobody |
| How it is verified | Tests, testnet, paper, acceptance | Cannot be, in advance |
| What happens on failure | We fix it | Someone absorbs a loss |
| Can be given honestly | Yes | No |
The first column is what we sign up to. Order execution correct against the venue's API. Risk limits enforced. Reconnection without duplicate orders. Partial fills accounted correctly. Every one of those is testable, and if the system does not do it, that is our defect to fix.
Why the second cannot be given
A trading outcome depends on the strategy, the market regime, the fee tier, the capital, the timing, and the behaviour of every other participant. A developer controls none of those. Promising an outcome you do not control is not confidence — it is a claim that will be paid for by someone.
There is a simpler version of the argument. If someone could reliably guarantee a return on a trading bot, the rational thing to do with that capability is to run it with their own capital and borrow against it. Selling it for a development fee would be an extraordinary misallocation.
What we can actually be held to
The absence of a profit guarantee does not mean the absence of accountability. The things that go into a written scope:
- The strategy is implemented exactly as specified, and any ambiguity is resolved in writing before it is coded.
- Risk limits behave as agreed under test, including the ones that are inconvenient.
- The system survives the failure drills — disconnect, restart, rejection, partial fill.
- Backtest and paper results are reproducible from the delivered code.
- Source code, documentation and a runbook are handed over.
- Defects found in a defined window after handover are fixed at no cost.
That is a real warranty on a real deliverable. It is narrower than what some vendors imply and it is enforceable, which the wider version is not.
What we will tell you instead
Something more useful than a promise: an honest read on whether the strategy is worth automating. Sometimes that answer is no.
We have told clients that a backtest did not survive purged validation, that a strategy's edge disappeared once fees were applied inside the loop, and that the sensible first project was a data pipeline rather than a bot. Those conversations cost us revenue in the short term and are the reason a proportion of clients come back with a second project.
The one thing automation does guarantee
Consistency. A bot applies the same rule to the thousandth signal as to the first, at 3am, on the trade after a painful loss, when you would have hesitated.
That is a genuine, deliverable guarantee. Whether the rule is a good rule remains your decision — and the honest version of this business is being very clear about which of those two things you are buying.
This article describes engineering practice. It is not investment advice. Vizanix develops software and does not promise trading returns.