Decide whether the tool alerts, backtests, or touches orders
The first line in the spec is the boundary. An alert tool is one-directional: data comes in, rules evaluate, notifications go out. Backtesting adds historical data, fill assumptions, and result statistics. Connecting to a broker or exchange order API adds key custody, permission scope, risk controls, and liability, which changes both cost and timeline. Keep phase one to alerts plus backtesting. A simple test: if the tool can move a user's money, it should not be scoped together with an alert tool.
Check licensing, conventions, and latency of the data source, not just whether it responds
Six items to confirm before ordering: whether the source is an exchange, an aggregator, or scraped; whether the license allows display and redistribution inside your product; whether quotes are real-time, delayed, or daily only; the adjustment method (forward, backward, or none); timestamp timezone and precision; and how gaps and later corrections are handled. Free APIs often bring rate limits, field changes between versions, and vague commercial terms. Backtests and live alerts must share one convention, otherwise a signal that held in testing will not line up in production. If commercial use cannot be confirmed in writing, change the source at the quoting stage.
Write trigger rules so they can be reproduced
"Alert me on a breakout" is not a rule. These are: which candle interval, close price or intraday price, the breakout threshold, whether N consecutive confirmations are required, the cooldown after a trigger, priority and de-duplication when several rules fire, and whether missed alerts are replayed after a data outage. Intraday evaluation produces signals that appear and vanish before the candle closes, so users see an alert they cannot find on the chart. A practical acceptance test: rerunning a rule on the same historical data twice must give identical results, and live alert logs should be reproducible in the backtest engine. If not, hidden state is missing from the rule.
Backtest credibility depends on assumptions that are often skipped
Four common distortions: using data not yet available at the time (look-ahead bias), keeping only surviving instruments, ignoring fees and slippage, and inconsistent adjustment. At acceptance, ask the tool to expose its fill model: next-bar open or same-bar close, fee settings, and handling of halts and limit moves. Keep an in-sample and out-of-sample split. If returns look good without costs and collapse to near zero with them, the strategy is too cost-sensitive; stop and review instead of tuning parameters further. Backtests describe the past and should not be presented as expected returns in product copy.
If it ships on Android, settle the developer account type first
Alert and backtest tools often ship as apps, and Android needs a Google Play developer account. The question to settle early is ownership: personal or company app, personal or organization account, who holds payout and tax details, and whether a later change of holder affects published apps. Apps with market data or investment content may also face financial-feature declarations; the exact requirements depend on the platform's pages at the time, so do not rely on memory. If you buy a fresh account or one with an existing app through Fayá, put the app type, the data license holder, and the account holder in one checklist before ordering. The account is only the publishing vehicle; it does not replace data licensing or compliance disclosures.