The line sits at tooling because only tooling can be accepted
Software acceptance rests on a specification: given these inputs, produce these outputs, handle these failures. Each clause can be tested. Strategy returns depend on market conditions, fills and parameter choices, so a developer cannot prove them on delivery day. Stopping at tooling is not a capability ceiling. It separates what can be verified from what cannot be promised. A return target written into a contract adds a clause nobody can test.
What the tooling layer usually covers
Typical scope includes market and historical data ingestion, a backtest engine, a signal-to-order execution module, position and risk rules, order and fill logs, alerting, and deployment configuration. These modules share one trait: their behavior can be described. Examples are 'no duplicate orders after a reconnect' or 'reject new orders when a symbol exceeds its position cap', and both translate directly into test cases. During scoping, confirm who supplies data sources and exchange accounts so a missing dependency does not surface at handover.
Strategy stays with the client because the judgment and IP are theirs
A strategy encodes entry logic, parameters and risk appetite, which is the client's investment judgment. When one party writes both strategy and system, three problems appear: ownership is unclear, nobody is accountable for overfitting in the backtest, and live losses cannot be traced to code defects or strategy decay. A cleaner split is for the client to supply rules or pseudocode and for the developer to prove the implementation matches them. Whether the rules are good is not a delivery check.
Fund access sets the liability boundary, and managed trading is a different business
Tool delivery needs no access to funds. When connecting to an exchange, API keys should allow read and trade only, withdrawals disabled, and ideally be bound to fixed IPs, with the client storing and rotating them. If a developer holds withdrawal rights, or places orders for multiple people or holds their money, the work becomes asset management or an investment service. Licensing and disclosure rules differ by jurisdiction, so check local regulation. Managed trading should be assessed separately, not folded into a development contract.
Write acceptance around behavior, not profit
Useful acceptance items: the same data and parameters reproduce identical backtest trades; backtest and live share the same signal and risk code, or differences are listed; the order state machine handles partial fills, rejections, timeouts and failed cancels; the system recovers after network loss or restart without duplicate orders; risk limits trigger logs and alerts; the build runs cleanly in paper or small-size trading first. An attractive equity curve does not mean acceptance passed. It only shows the rules ran correctly once.
Signals that should make you pause or switch vendors
Reconsider if the vendor promises returns, drawdown limits or capital protection; asks for withdrawal permission or for funds to go to an account they control; will not confirm requirements and test cases in writing; withholds source code, deployment docs or a dependency list so you cannot run it yourself; or offers a backtest report in place of test records. The baseline for a tooling contract is that you can deploy it, stop it and audit its logs on your own. If you cannot, a lower price does not make it worthwhile.