Hiring an Algo Trading Developer in India: Scope, Handover and the Questions Nobody Asks
Most traders hire an algo trading developer the same way they would hire someone to build a website. They describe the idea in a WhatsApp message, ask for a price, pay half up front, and wait. Four weeks later a zip file arrives. It runs on the developer’s laptop. It has one hard-coded broker key. There is no README. The backtest that justified the whole project exists only as a screenshot.
That is the standard outcome, and it is not because developers are dishonest. It is because a website has an obvious acceptance test — you open it in a browser and look at it — and a trading system does not. A trading system can look completely finished and still be wrong in ways that only show up at 09:20 on an expiry morning when one leg of a four-leg order fills and the other three do not. The trader is the only person in the room who knows that. The developer usually does not, and the quote almost never covers it.
This piece is written for the trader side of the table. It is a commissioning guide, not a coding guide. The aim is that you walk into the conversation knowing what you are buying, what the spec has to say before anyone writes a line of code, what you must physically receive at handover, and which lines in a quote should make you stop and ask another question.
You are not buying software. You are buying three separate things.
The single most expensive mistake in these engagements is treating the job as one deliverable with one price. It is three deliverables with three very different cost structures, three different skill sets, and three different time horizons. Price them separately or you will end up paying for one and assuming you got all three.
1. Strategy logic
This is your idea. Entry rule, exit rules, strike selection, instrument, sizing method. It is the part you already have in your head or in a spreadsheet. It is also the part that is quickest to code and cheapest to build — a time-triggered short strangle with a stop-loss on each leg is maybe a hundred lines of real logic. If a developer’s price is dominated by this piece, they are either charging you for your own idea or they are planning to sell you theirs.
Strategy logic is also the part that is yours in every sense that matters. Keep it that way. More on that in the IP section below.
2. The execution layer
This is the part traders consistently forget to buy, and it is where most of the real engineering sits. It includes order placement and the retry policy when an order is rejected, websocket or polling reconnect when the broker feed drops, position reconciliation against the broker’s own book rather than against the bot’s internal memory, order-state tracking across restarts, rate-limit handling, a hard risk kill-switch that can square off everything on one command, and logging good enough that you can reconstruct what happened three Thursdays ago.
None of that shows up in a demo. All of it shows up in a bad week. A strategy that is right and an execution layer that is wrong will still lose money, and the loss will look exactly like a strategy failure, which means you will spend months tuning parameters to fix a plumbing bug.
3. Operations
Someone has to be awake and watching on expiry morning. Someone has to be reachable at 09:20 when the bot has placed two legs and stopped. Someone has to know what to do when the broker changes an API response format with a week’s notice, or when a token expires, or when the exchange publishes a new lot size.
Operations is a recurring cost, not a one-time cost, and it is the line that fixed-price quotes almost always omit. If your quote has no support term, no response-time commitment, and no stated scope for what counts as a bug fix versus a new feature, you have bought a build with no operations and you are the operations team whether you know it or not.
ComponentWhat it isCost shapeWho should own itStrategy logicEntry, exits, strike selection, sizingOne-time, smallYou, fully and permanentlyExecution layerOrders, reconnect, reconciliation, kill-switch, logsOne-time, largeYou own the code; developer may reuse generic partsOperationsMonitoring, incident response, broker-API upkeepRecurring, monthlyContracted, with a stated response time
Ask for the quote broken into these three lines. The request itself is informative. A developer who has built live trading systems before will break it down without blinking, because that is how they already think about it. A developer who has not will resist, because splitting the price exposes that the execution and operations work was never scoped. If you are sampling the market first, it is worth reading up on how algo trading companies and developers in Delhi NCR structure their engagements, because the build-versus-support split is the clearest signal of whether a shop has actually run capital or only written code.
Writing a spec an algo trading developer can actually build from
A spec is not a description of your strategy. It is a description of every decision the program will have to make, including the ones you have never had to make consciously because you were doing them by hand. A discretionary trader resolves ambiguity by instinct a hundred times a session. Code cannot. Every gap you leave in the spec becomes a guess the developer makes silently, and you will not find out what they guessed until money is on the line.
Entry condition, including the exact timestamp convention
“Enter at 9:20” is not a spec. It leaves at least four things open. Does 09:20 mean the candle that opens at 09:20:00 or the candle that closes at 09:20:00? Is the signal evaluated on the 09:19 candle’s close and acted on at 09:20:00, or evaluated on 09:20’s own close and acted on at 09:21:00? If the bot starts late at 09:22, does it enter immediately or skip the day? Which clock — the broker’s timestamp, the exchange feed’s timestamp, or the server’s system time?
That last one matters more than it sounds. A server whose clock has drifted by forty seconds will enter on the wrong candle and you will never see it in the logs unless the logs record both the local time and the feed timestamp. Write the convention down in one unambiguous sentence: “Signal is evaluated on the close of the 1-minute candle timestamped 09:19 using exchange feed time; order is placed immediately after; if the order is not placed by 09:21:00 the day is skipped.” Now there is nothing to guess.
Exit conditions, in priority order
Not a list — a priority order. Real strategies have several exit rules and some mornings two of them fire in the same second. Stop-loss on one leg, a trailing stop on the book, a time-based square-off, a daily loss limit, and a re-entry rule can all be live at once. Which wins? What happens to the re-entry rule after the daily loss limit has triggered — is it disabled for the rest of the day, or will it cheerfully re-enter and breach the limit again?
Write exits as a numbered list, highest priority first, and state explicitly which rules are disabled once each one fires. This single section prevents more live-trading accidents than any other part of the spec.
What happens on a partial fill
You asked for 5 lots. Three filled. The spec must say what the bot does next: chase the remaining two at a worse price, cancel the rest and run with 3 lots, or square off the 3 and skip the day. All three are defensible. Only one is what you actually want, and the developer cannot know which without being told.
Then the harder question: if the strategy is multi-leg, does the stop-loss recalculate on the filled quantity or on the intended quantity? A stop sized for 5 lots sitting on a 3-lot position is a different trade from the one you designed.
What happens when one leg fills and another does not
This is the orphan-leg problem and it is the most common way a well-designed option-selling strategy turns into an unhedged directional bet. You intended a short strangle. The call leg filled. The put leg was rejected because of a margin check or a price band. You are now short a naked call with no spec for what to do about it.
The options are: immediately square off the filled leg and abandon the trade, retry the unfilled leg a stated number of times within a stated price tolerance, or accept the single leg and apply a separate, tighter stop to it. Pick one. Write down the retry count and the price tolerance as numbers. Also write down the alert — you want a message on your phone the moment the bot enters a state it was not designed for, even if it handles it correctly.
Behaviour on a mid-session disconnect
The feed drops at 11:40. The bot has an open position. What does it do? Does it try to reconnect silently, and for how long? Does it place a protective order with the broker so the position is covered even if the bot never comes back? When it reconnects at 11:44, does it trust its own memory of the position or does it query the broker’s book and reconcile?
The right answer is almost always: reconcile against the broker, never against memory. A bot that trusts its internal state after a reconnect can double a position or place a square-off order for a quantity it no longer holds. Make reconciliation-on-reconnect an explicit, written requirement, because it is extra work and it will not be built unless it is asked for.
The hard daily loss limit
One number, in rupees, checked on every tick, that squares off everything and stops the bot for the day when breached. Not a percentage of a notional you will have to recompute. Not a “soft” limit the strategy can trade back through. A hard rupee figure, with a stated behaviour afterwards: flat, no re-entry, manual restart required.
Then test it on purpose. Set it absurdly tight — say two thousand rupees — on a paper-trading session and confirm the bot actually stops. A loss limit that has never been triggered in testing is a line of code nobody has run.
Why “it works in the backtest” cannot be your acceptance test
Traders routinely accept delivery on the strength of a backtest equity curve. That is the wrong test, and there is a specific, measurable reason why.
A backtest summary reports what the position was worth at the close. It says nothing about the path the position took to get there. And on expiry-day option selling, the path is most of the story. In a study of 163 NIFTY and SENSEX weekly expiry sessions between January 2025 and July 2026, a plain short ATM straddle entered at 09:20 gave back a median 42.8% of its peak intraday profit by the close. More than half the days — 86 of 159 usable sessions — gave back over 30% of the peak. And on 48 of those 159 days, 30% of the sample, a position that was showing a profit at its intraday peak finished the day as a loss.
Peak-to-close behaviour, short ATM straddle entered 09:20 (159 expiry days)ValueMedian give-back as % of peak profit42.8%Days giving back more than 30% of peak86 / 159 (54%)Days giving back more than 50% of peak78 / 159 (49%)Days where a positive peak closed as a loss48 / 159 (30%)
Read that as a commissioning problem rather than a strategy problem. If 30% of days cross from profit into loss before the close, then your spec must define behaviour on the mark-to-market path and not just at the exit. Specifically: is there a profit lock? At what level, measured how — a rupee figure, a percentage of premium collected, a multiple of the stop? Is there a trailing stop on the book rather than on individual legs? Does the bot evaluate the book’s MTM on every tick or once a minute, and is “MTM” computed off last-traded price or off the bid-ask mid? Those are four separate questions, each with a different answer, and every one of them changes the result on a day that peaked at 11:00 and sagged into the close.
So the acceptance test is not “show me the backtest”. It is “show me a backtest I can re-run on my own machine, and show me the intraday MTM series, not just the daily P&L”. If the developer can only produce a closing-P&L summary, the system has no visibility into the exact behaviour that decides whether you keep half your good days.
The handover checklist
Handover is the moment the engagement either leaves you independent or leaves you captive. Decide which before you pay the final instalment. Six things, and treat them as non-negotiable.
Source code in a repository you own. Not a zip file over WhatsApp. A git repository under your own account, with the developer added as a collaborator and removed when the project ends. The commit history is part of the deliverable — it is how you later work out when a behaviour changed and why.
A written data-dependency list. Every external thing the system needs to function: which broker API and which version, which market-data feed, instrument master or symbol-mapping files and where they are refreshed from, any lot-size or expiry-calendar file that has to be updated, and what happens when each one is unavailable. This is the document that saves you when a vendor changes something.
Environment and dependency pinning. Exact language version and exact library versions, locked in a requirements or lock file, plus a one-command way to recreate the environment from scratch. “It works on Python 3-something with the latest packages” is not a deliverable. A library update six months from now can silently change a rounding behaviour or a timezone default, and without pinning you will have no way to tell whether the strategy changed or the environment did.
A runbook for restart. One page, written for a tired human at 09:20, not for a developer. How to stop the bot. How to check whether a position is open at the broker. How to square off manually. How to restart and what the bot does on restart if a position already exists. What the three most likely error messages mean. Make the developer write it and then test it yourself by following it literally, without asking them anything.
Where credentials live. A stated location and mechanism — environment file, OS keychain, secrets manager — and confirmation that no key, token or password appears anywhere in the source code or the commit history. Keys committed and then deleted are still in the history. Check.
A reproducible backtest. Code, data (or a documented way to fetch the same data), and a command that produces the same numbers the developer showed you. Run it on your own machine before the final payment. If the numbers differ, you have found something important while you still have leverage.
IP and confidentiality, in plain terms
This is the section traders skip because it feels like lawyer territory, and then regret eighteen months later. You do not need a complicated agreement. You need four questions answered in writing, in ordinary language, before work starts. This is practical commissioning hygiene, not legal advice, and if the sums involved are material you should have a professional look at the actual document.
Who owns the strategy logic? Default position: you do, because it is your idea. Say so explicitly, because in the absence of a written term the person who wrote the code often has a stronger claim than the person who had the idea. Separate the strategy logic from generic infrastructure in the agreement — it is entirely reasonable for a developer to keep reusing their own order-management or reconnect library across clients, and unreasonable for them to keep your entry rule.
Can the developer reuse it for another client? Ask directly. Get the answer in writing. A “no” that exists only in a phone call is not a no.
Is there a confidentiality term, and does it survive the engagement? A confidentiality clause that expires when the project ends protects nothing. It needs to continue after delivery and it needs to cover your parameters, not just your source code — the structure of a short strangle is public knowledge, your specific strike-selection and stop numbers are not.
Is there a non-compete, and is it realistic? A narrow, time-boxed term that stops the developer selling the same specific system to other traders in the same instrument is reasonable. A sweeping clause barring them from all algo work is unenforceable in practice and will simply be ignored.
Now the uncomfortable part, which almost nobody says out loud: an edge you hand to a third party is an edge you now share. This is not a comment on anyone’s integrity. It is arithmetic. Expiry-day index-option selling is crowded, the behaviour is well documented, and the same desk study found that the expiry close sits a median 0.083% from the max-pain strike — about 34 points on NIFTY. When the profitable zone is that narrow and that well known, incremental crowding into the same strikes at the same minute measurably changes your fills. Every additional person who knows your exact parameters raises the chance that someone is standing in front of you at 09:20.
Two practical consequences. First, scope what you disclose. A developer can build a complete, correct execution layer while the specific thresholds live in a configuration file you fill in yourself. Give them a working set of numbers for testing and keep your live numbers to yourself. Second, treat the most sensitive part of the logic as the last thing you hand over, not the first.
Credential and access hygiene
Five rules. They are boring and they are the difference between a bad outcome and a catastrophic one.
Never hand over your broker login. Not the password, not the trading PIN, not the two-factor seed. If a developer asks for your account credentials “just to test”, that is the end of the conversation. API access exists specifically so this is unnecessary.
Use API keys with the narrowest scope that works. Most broker APIs let you create app-level credentials that are separate from your login. Create a dedicated set for the project. Do not reuse the keys your other tools already use.
Keep withdrawal rights separate from trading rights. A credential that can place orders should not be able to move money. Check what your broker’s API can and cannot do before you issue anything, and confirm that funds transfer sits behind your own authentication only.
Rotate on handover. The day the project ends, revoke every key the developer touched and issue new ones. Also remove their repository access, their server access, and any shared drive folder. Diarise it — this is the step that gets forgotten because the project is “over”.
Test with small size on a real account, not a big one. Paper trading does not test credentials, rejections, margin blocks or rate limits. The first live run should be one lot, on a day you are watching, with the kill-switch tested first.
Worth knowing as context: SEBI has been formalising how retail algo access works through brokers, including registration of algos and tagging of orders. The framework is published on the SEBI website and it affects how your developer connects to the broker, not just what the strategy does. Ask whether the proposed approach fits the current broker-approved route, because a system built around an unapproved connection method is a system with a short shelf life.
Red flags in a quote
These are the lines that should stop you. Not because they prove bad faith, but because each one marks a gap that will cost you later.
Red flagWhat it actually tells youWhat to ask insteadFixed price, no specScope is undefined, so every clarification becomes a dispute”Can we agree the spec first and price against it?”Any promised return figureNobody can promise returns. Walk.Nothing. End the conversation.”We will share our proven strategy”If it were proven and scarce, they would trade it, not sell it”Show me a backtest I can re-run myself”Refusal to let you re-run the backtestThe numbers cannot be independently reproduced”What stops me running it on my machine?”No mention of reconnect or reconciliationThe execution layer was never scoped”What happens on a feed drop with a position open?”Flat rate covering build and support togetherSupport has no defined scope, so it will quietly end”Split build from support. What is the response time?”Code stays on their serverYou are renting, not commissioning”Which repository will this live in, under whose account?”
The “proven strategy” one deserves a note. There is a legitimate version of it — a firm that licenses analytical software and publishes its logic and its historical behaviour transparently is a normal product business. EliteAlgo, for instance, positions what it builds as analytical software rather than advice. The illegitimate version is a bespoke-development quote that quietly becomes a strategy sale, where you pay for engineering and receive a signal service. If you are weighing up vendors as well as individual developers, the criteria for evaluating algo trading firms in India are mostly the same questions in a different order: who owns what, what is reproducible, and who answers the phone on an expiry morning.
One more test that costs nothing. Ask the developer to describe a live incident they have handled — not a bug, an incident, with a position open. People who have run real systems have a story immediately and it has specific details in it: the time, the error, what they did first. People who have not will answer in generalities.
Paying against milestones you can actually verify
Milestone payments only work if each milestone has a test that you can run and that produces a yes or a no. “Development 50% complete” is not a milestone. Here is a structure that is.
MilestoneVerification you run yourselfShare of fee1. Spec signed offYou read it and cannot find an unanswered “what if”Deposit2. Backtest reproducible on your machineYou run one command and get the developer’s numbersNext tranche3. Paper-trading parity for N sessionsLive paper signals match the backtest’s signals for the same days, within a stated toleranceNext tranche4. Live with small size, kill-switch testedOne lot, stop triggered deliberately, bot stops as specifiedNext tranche5. Handover completeAll six handover items received; runbook followed by you aloneFinal
A note on milestone 3, because it is the one people get wrong. Paper-trading parity does not mean the paper account made money. It means the system generated the same decisions at the same times as the backtest would have for those sessions. You are testing that the live code and the backtest code agree, which is a question with a clean answer, rather than testing whether the strategy is profitable, which fifteen sessions cannot tell you. Pick N in advance — ten to fifteen sessions is a reasonable band for a weekly-expiry strategy, which in practice means several weeks of calendar time, and the contract should say so.
And on milestone 4: deliberately trigger the daily loss limit and the kill-switch while you are watching. Both. A kill-switch that has only been tested in a unit test is a kill-switch you are trusting on faith.
What good looks like from the trader’s side
The engagements that work tend to share a shape. The spec takes longer than anyone expected — often a week of back-and-forth before any code — and that week is where the money is saved. The developer asks awkward questions early, about partial fills and timestamps and what to do with an orphan leg, which feels like scope creep and is actually competence. The first live run is one lot. The trader can restart the system alone, from the runbook, without a phone call. And the support arrangement has a number attached to it, because operations is a real cost and pretending otherwise just means someone eats it later.
The engagements that fail share a different shape. They start with a price, not a spec. The acceptance test is a screenshot. Nobody discusses IP. The broker password gets shared “just this once”. And the first the trader hears about the execution layer is on a morning when it was needed and was not there.
If you only take one thing from this: the spec is the product. The code is an implementation detail of the spec, and a good developer with a precise spec will build you something that works. A great developer with a vague spec will build you something that works beautifully and does the wrong thing.
Risk and positioning
Algo trading carries a real risk of loss, and automating a strategy does not reduce that risk — it removes the hesitation that sometimes saved a discretionary trader from their own rule. Index-option selling in particular can lose more than the premium collected. Nothing in this article is investment advice, no outcome described here is a prediction, and the desk figures quoted are historical measurements of past sessions rather than an indication of what any future session will do. Tools such as EliteAlgo are analytical software, not investment advice, and the responsibility for sizing, risk limits and the decision to deploy capital stays with the trader. If you want the standard definitions behind the order types and risk terms used above, Investopedia is a reasonable neutral reference.
Frequently Asked Questions
How much should I pay an algo trading developer in India?
There is no single market rate, because the three components price very differently and most quotes bundle them. What you can do is insist on the breakdown — logic, execution layer, operations — and compare like with like across quotes. A build quote that is lower than the others usually turns out to have no execution layer and no support term rather than a better price. The recurring operations line is the one to scrutinise hardest, because it is the cost you will pay every month for as long as the system runs.
Should I search for an “algo trading developer near me” or does location not matter?
Location matters less for the build and more for the operations. Code can be written anywhere. But the first few live sessions are much easier with someone in your own timezone who can be on a call at 09:15, and a developer in the same city is noticeably easier to hold accountable than one three timezones away. If you do hire remotely, make the response-time commitment explicit in Indian market hours and name the specific window, 09:00 to 15:45 IST, in the agreement.
Who owns the code if I paid for it?
Whatever your written agreement says. Paying for work does not automatically transfer ownership, and in the absence of a term the position is often less favourable to the buyer than people assume. Agree it in writing before work starts, separate your strategy logic from the developer’s generic libraries, and have a professional review the document if the amounts are material.
Can I just give the developer my broker login? It is faster.
No. Broker APIs exist precisely so this is unnecessary, and sharing your login typically breaches your own broker agreement as well as exposing you to loss you may have no recourse for. Issue scoped API credentials, keep money-movement rights separate from order-placement rights, and revoke everything on handover.
The developer showed me a backtest with a great equity curve. Is that enough to accept delivery?
No, for two reasons. First, a backtest you cannot re-run yourself is a claim, not evidence — make reproduction on your own machine a payment milestone. Second, a closing-P&L curve hides the path. Across 163 NIFTY and SENSEX expiry sessions studied between January 2025 and July 2026, a short ATM straddle gave back a median 42.8% of its peak profit by the close and 30% of days turned a peak profit into a closing loss. Your acceptance test needs the intraday mark-to-market series, and your spec needs to say what the system does along that path.
What is the single most important clause to get into the agreement?
The handover definition. Write out the six items — repository you own, data-dependency list, pinned environment, restart runbook, credential location, reproducible backtest — and tie the final payment to receiving all of them. Everything else is recoverable. A system you cannot run, audit or modify after the developer stops answering is not.
