What to Write Down Before Hiring an Algo Developer
A good brief for an algo trading developer in India has six parts: the exact trading rules, the broker and its limits, the risk caps, the test plan, the monitoring and logs, and who owns what at hand-over. If any part is missing, the developer has to guess, and guesses in trading software cost real money. Trading carries risk, and no brief or developer can make a strategy profitable.
This post is general information, not investment, legal or financial advice. Facts about the rules and the Kite Connect API were taken from the sources listed at the end, read on 25 October 2026.
Why write a brief at all?
A brief is a written specification: a document that says what the software must do, in words precise enough to test. Without one, two people can read "buy on a breakout" and build two different programs. A brief also lets you judge the finished work against the document.
What belongs in the trading rules?
Write each rule so that a person with no market knowledge could follow it with a calculator. For every strategy, state:
- Instrument and timeframe: for example, "NIFTY weekly options, 5-minute candles". Name the exact contract selection method, such as "nearest strike to the spot price".
- Entry condition: the exact test, with numbers.
- Exit conditions: profit exit, stop-loss exit and time exit. If an exit is missing, the program will not invent a safe one.
- Position size: a fixed quantity or a formula.
- What to do when data is missing: a skipped candle, a stale price or a feed outage.
If you cannot write a rule down in this form, it is not ready to automate. Our guide to backtesting a trading algorithm explains why vague rules produce misleading test results.
Which broker and API limits should the brief name?
Name the broker and the API plan, because the limits differ and the code must respect them. Ask the developer to read the broker's current documentation and list every limit that affects your design.
As an example, the Kite Connect documentation lists these limits at the time of reading: 10 order requests per second, 400 orders per minute, 5,000 orders per day per user or API key, and a maximum of 25 modifications per order. It also lists 1 request per second for quotes and 3 per second for historical candles. Exceeding rate limits returns HTTP 429, and the documentation says a 403 means the session has expired and the program must log in again. Our post on what to check with the Kite Connect API covers these in detail. Other brokers have their own numbers; do not assume they match.
Your brief should also say what the program does when it hits a limit: wait and retry, skip the signal, or stop and alert you.
What do Indian rules mean for the brief?
The regulatory framework for retail algo trading puts the broker at the centre. As summarised in our guide to whether algo trading is legal in India, NSE's implementation standards (circular NSE/INVG/67858, 5 May 2025) say a client using API access must provide the broker with a static IP address, that API sessions must be logged out every day, and that the threshold for registering an algorithm is initially set at not exceeding 10 orders per second. All algo orders must be tagged, and brokers must not allow open APIs.
Turn this into brief items:
- Who supplies the static IP, and what happens if it changes?
- How does the system handle the daily logout and the next-morning login?
- Which order types does the strategy use? Confirm with your broker which order types it accepts for algo orders, and redesign if the strategy depends on one that is not allowed.
- Where will the strategy run, and how does your broker classify that setup? Ask in writing and keep the answer.
Rules can change after publication. Ask the developer to confirm the current position with your broker before the build starts, and put the answer in the document.
What risk limits should the software enforce?
Risk limits are caps the program applies to itself. They matter most when something goes wrong, such as a bug, a bad price or a connection loss. Put numbers in the brief:
| Limit | Example wording | Who sets the number |
|---|---|---|
| Maximum order size | "No single order above N lots" | You |
| Maximum open positions | "Never more than N positions at once" | You |
| Maximum daily loss | "Stop trading and alert me after a loss of N rupees in one day" | You |
| Maximum orders per day | "Stop after N orders" | You, below the broker's limit |
| Kill switch | "I can stop all trading and cancel open orders from my phone" | Developer builds, you test |
The numbers above are placeholders, not recommendations. Choose amounts you could lose in full without harm to your finances. A developer cannot choose these for you.
How should the system be tested?
Ask for the test plan in writing, in this order:
- Backtest on past data, with brokerage, taxes and slippage included. A backtest shows how the rules would have behaved on past data. It does not predict the future.
- Paper trading to prove the machinery: logins, order flow, restarts. See paper trading vs live trading.
- Small live size with every risk cap switched on.
Agree in advance what counts as "done" for each stage. For example: "ran for N sessions with no unhandled errors and every order matched the signal log." Do not agree to a success target based on profit, because no honest developer can promise it. Treat any promised return as a red flag.
What logs and alerts do you need?
Ask for a record of every signal, every order sent, every broker response and every error, each with a timestamp. Kite Connect documents that an accepted order is not the same as a filled order, and its order statuses and tag field are there so you can track the difference. Your logs should show, for each order, the signal that caused it and the final status.
Also specify alerts: what message you get, through which channel, and for which events. Examples are a failed login, a rejected order, a breached loss cap or a stopped program.
Who owns what at hand-over?
Settle these before work starts:
- Source code: do you receive it, and under what licence?
- API keys: keys stay in your name. Never share your broker password, and keep keys out of shared code and public repositories.
- Hosting: who pays for and manages the server and the static IP?
- Support: who fixes the system when a broker changes its API, and how fast?
A one-page checklist
- Each strategy rule written with numbers, including exits and missing-data behaviour.
- Broker, plan and the limits that apply, with the documentation link.
- Static IP, daily login and order types decided and confirmed with the broker.
- Risk caps with numbers, and a kill switch you have tested.
- Test stages with pass criteria that do not mention profit.
- Logs and alerts defined.
- Ownership of code, keys, hosting and support agreed.
Frequently asked questions
Can I hire a developer without knowing how to code?
Yes. The brief is your part of the work. You need to describe the rules and risk limits clearly, and you need to be able to read the logs. You do not need to read the code, but you should ask for it.
Does a brief guarantee a profitable system?
No. It makes the software do what you intended. Whether the strategy makes money is a separate question, and past results do not predict future ones.
Should the developer have access to my broker account?
Not to your login password. API keys are issued in your name and can be revoked by you. Check your broker's rules on API access before you share anything.
Sources
All pages were read on 25 October 2026 unless noted.
- Zerodha Kite Connect documentation, exceptions and rate limits: https://kite.trade/docs/connect/v3/exceptions/ (order and request limits, HTTP 429 and 403 codes)
- Zerodha Kite Connect documentation, orders: https://kite.trade/docs/connect/v3/orders/ (order statuses, tag field; read 19 October 2026)
- NSE, circular NSE/INVG/67858, "Safer participation of retail investors in Algorithmic trading", 5 May 2025: https://nsearchives.nseindia.com/content/circulars/INVG67858.pdf (static IP, daily logout, 10 orders per second threshold, tagging; points taken from the summary in our legal guide, which was checked against this document on 17 October 2026)
This article is general information, not legal or financial advice.