The client writes the conditions; the developer turns them into rules
The most common dispute in custom quant work is who decides the conditions. The workable split: you supply entry, exit and filter logic, and the developer implements it, tests it, and points out anything unexecutable or contradictory. The reason is practical. When a developer fills in a vague condition, that filler becomes part of your strategy without being your decision. If results later disappoint, you cannot tell whether the idea was weak or an implementation default was. Before ordering, confirm that you are the author of the condition document, not that it gets completed gradually during chat.
A signal is specified when two people compute the same result from the same data
Breakout on volume is a label, not a condition. An executable version states the candle interval, which trailing average volume is used and over how many bars, the multiple required, the lookback for the price high, whether close or intrabar price counts, and whether the comparison is strict. A simple self-check: give two people the same price table and ask them to judge by hand. If they disagree, the rule is unfinished. Typical gaps are parameters without numbers, windows without start and end, and unclear relations between conditions (all must hold, or any). For indicators such as moving averages or RSI, state the calculation basis and parameters, not just the name.
Frequency drives how data is fetched and whether the tool stays stable
Frequency is not a parameter you can tweak later. Triggering on candle close needs one data pull per period, which is simple and produces stable signals. Triggering on live intrabar conditions usually means subscriptions or frequent polling, which brings exchange rate limits, reconnects and latency, and raises hosting and upkeep cost. One more trap: a signal judged on an unclosed candle can vanish before the close, leaving an alert that no longer holds. So specify whether signals are close-based or intrabar, how long a repeated signal is suppressed, and roughly how many symbols are watched. Actual rate limits come from the exchange's current API documentation and change over time, so do not hard-code them into the brief.
Output format should follow how the output will be used
The same signal looks different for a person and for a program. A human-facing alert typically needs symbol, direction, trigger time, trigger price, a short summary of matched conditions, plus language and time zone. A machine-facing file or endpoint needs fixed field names, data types and timestamp format, such as CSV column order or a JSON structure. Paste one sample of the output you expect straight into the brief. Also agree on deduplication, retry on failure, which fields are logged, and whether a strategy version number travels with each signal. Changing format late tends to ripple into data structures and tests, which costs far more than writing it down at the start.
If your conditions are not formed yet, do not order yet
Some clients arrive with only a direction, such as a trend-style alert. A developer can offer standard implementations of common indicators as reference, but parameter values remain your call, and reference values say nothing about performance. If you cannot answer any of the three areas above, a safer step is to run the idea by hand against historical charts and write it down first. Another stop signal is repeated reversal during development. If the same condition set changes two or three times, the requirement has not settled. Pause, rewrite the document, and treat later changes as new scope rather than stacking them onto the original.
A one-page checklist and a rule for holding off
Compress the checks into one page: symbols and intervals in scope; full rules and parameters for each signal; close or intrabar trigger and the dedupe rule; output channel, fields and a sample; data source and whether history is needed; how changes are priced and scheduled. The decision rule is simple: if any line needs the developer to figure it out for you, it is not time to order. When you can fill every line and a stranger would read it without ambiguity, move on to quotation and scheduling, and acceptance will have something concrete to check against. Scope, fees and timelines are whatever both sides confirm in writing.