You have a setup that works. You have traded it manually for months, you know its rhythm, and you are tired of missing entries because you stepped away from the screen. So you decide to get it coded. This is a guide to doing that well — what to write down before you approach anyone, what actually drives the price, how long a real build takes, and the warning signs that a project is heading nowhere.
It is written from the other side of the table. We build these systems for Indian traders, and the pattern is consistent: the projects that go smoothly are the ones where the trader arrived with clear rules. The projects that drag on are the ones where the rules were still being invented halfway through.
The gap between a strategy and a system
A strategy lives in your head as a feel for the market. A system is a set of instructions that a machine follows without judgement, at speed, including on the days the market does something stupid. Translating one into the other is mostly an exercise in removing ambiguity, and that work belongs to you, not the developer — because only you know what you actually intend.
Consider a rule you might state as: buy when price breaks the opening range with volume. That sentence contains at least six unanswered questions. Which opening range — the first five minutes, fifteen, thirty? Break by how much, and measured on close or on touch? Volume compared to what baseline? On which instrument, and at what quantity? What if it breaks in the first minute and again at noon — do you take both? And what happens if you are still holding when the market closes?
A developer who guesses at those answers will build something that runs, produces trades, and quietly bears no resemblance to your edge. You will then spend three weeks discovering that in revisions. That is where budgets go.
What a codeable specification actually looks like
You do not need technical language. You need decisions. The difference is visible immediately:
| Not yet codeable | Codeable |
|---|---|
| Enter on a breakout with momentum | Enter long when a 5-minute candle closes above the high of the 9:15–9:30 range, and that candle's volume exceeds the 20-candle average volume |
| Use a sensible stop | Stop-loss at the low of the entry candle, minimum 15 points, maximum 60 points. Skip the trade if the required stop exceeds 60 points |
| Trail the stop once it moves | Once the position gains 40 points, move the stop to entry. After that, trail at 25 points behind the highest price reached, stepping in 5-point increments |
| Book profit at a good level | Exit half the quantity at 1.5× the risk, the remainder on the trailing stop or at 3:20 PM, whichever comes first |
| Trade NIFTY options | Trade the NIFTY weekly expiry, ATM strike selected at signal time, one lot, CE for long signals and PE for short |
Every row on the right is something you already know. Writing it out is the whole job.
The seven things every specification needs
- Instruments and expiry. Exactly which symbols — index, stock, futures or options. For options, how the strike is chosen and which expiry.
- Timeframe. The chart the logic runs on, and whether any input comes from a higher timeframe.
- Entry conditions. Every condition, and whether they must all be true or any one is enough.
- Exit conditions. Stop-loss, target, trailing behaviour, time-based exit, and reverse-signal exit if you use one.
- Position sizing. Fixed lots, a rupee risk per trade, or a percentage of capital. State the maximum.
- Session rules. First trade no earlier than, last entry no later than, square-off time, and the maximum trades per day.
- Risk limits. Daily loss limit that stops trading, daily profit lock if you use one, and what happens after a limit is hit.
A screenshot of a chart with your entry and exit marked, alongside these seven answers, is a better brief than three pages of prose. Ambiguity hides in prose. It cannot hide in a marked-up chart.
The edge cases that decide whether it works
This is the section experienced traders read twice, because these are the questions that surface on day one of live trading and not before. Decide them now, in writing:
- Signal at the close. A valid entry appears at 3:24 PM. Take it, or ignore anything after a cutoff?
- Position open at square-off. Exit at market, or hold overnight where the instrument allows it?
- Partial fills. Your order for three lots fills one. Wait, chase, or cancel and stand aside?
- Order rejection. Insufficient margin, or the broker rejects for its own reasons. Retry how many times, then what?
- Terminal restart mid-trade. The system restarts while a position is open. It must recognise and resume managing that position rather than treating the account as flat — this is the single most common reason a working system loses money.
- Connection loss. The data feed or the broker connection drops for ninety seconds. Does the system hold, flatten, or stop taking new entries?
- Expiry day. Different rules on expiry, or the same?
- Gap openings. Price gaps past your stop overnight. Exit at open, or apply the stop as a market order?
- Duplicate signals. The condition stays true for four consecutive candles. One trade or four?
If a developer never asks you about restart recovery and rejected orders, they have not built a live system before. Those two alone account for most of the difference between code that backtests beautifully and code you can leave running.
Where it should run
The platform decision follows the strategy, not the other way round. In Indian markets there are three realistic homes for an automated system, and they suit different jobs.
| Platform | Best for | Constraint to know |
|---|---|---|
| MetaTrader 5 (MQL5) | Chart-driven strategies, options work, visual panels, anything you want to watch and intervene in | Needs a data bridge to see Indian symbols, since no Indian broker ships MT5 with NSE, BSE and MCX feeds by default |
| MetaTrader 4 (MQL4) | Simple index and futures logic on an existing MT4 setup | No custom-symbol API, so individual stock option strikes cannot be charted. Compiled MQL4 files do not run on MT5 — it is a rewrite, not a copy |
| Broker API direct (Python) | Scanning hundreds of symbols, basket and portfolio logic, anything with no chart at its core | You get no chart and no visual confirmation. Deployment, logging and monitoring become your problem |
A useful rule of thumb: if you would describe your strategy by pointing at a chart, build it on MetaTrader. If you would describe it as a table of numbers across many symbols, build it against the broker API. Our own MT5 Bridge exists precisely because the first group had nowhere to run, and the fuller comparison of MT4 against MT5 for Indian instruments is in the FAQ.
What it costs, and what drives the price
Honest answer: the range is wide, because the work is. What narrows it is scope, and scope is exactly what a written specification pins down. Custom development with us starts at ₹999, and every project is quoted at a fixed price after the specification is agreed — not billed by the hour, so a slow week is our problem rather than yours.
These are the factors that move a quote, roughly in order of impact:
- Order placement. An indicator that draws signals and alerts is a fraction of the cost of anything that sends live orders. Order routing brings rejection handling, position tracking, restart recovery and reconciliation with it.
- Options logic. Strike selection, expiry rolling and multi-leg positions are materially more work than single-instrument futures logic.
- Number of conditions. Not linear. Three conditions with clear precedence cost less than two conditions with a disputed interaction.
- State to remember. Anything the system must carry across candles, sessions or restarts adds real complexity.
- Interface. A panel with buttons, live figures and drag-to-modify orders is a build in its own right, separate from the strategy behind it.
- Specification quality. The one you control. A clear brief can halve the quote on the same strategy, because most of the cost of vague work is rework.
As a rough shape: a signal-and-alert indicator sits at the light end, a single-instrument automated entry-and-exit system in the middle, and a multi-leg options system with its own execution panel and risk controls at the top. Tell us the strategy and you get a number, a timeline and a scope boundary before anyone writes a line of code.
How long it takes
Coding is rarely the long pole. Specification and testing are.
| Stage | Typical duration | Who does the work |
|---|---|---|
| Specification and quote | 1–3 days | You write the rules, we ask the awkward questions and confirm scope |
| Build | 2 days to 3 weeks depending on scope | Us |
| Your testing | 1–2 weeks of live sessions | You, in paper or minimum quantity |
| Refinement | Within the 7-day support window | Us, on anything that does not match the agreed specification |
Resist the urge to compress your own testing. A system needs to meet a trending day, a choppy day, an expiry day and at least one connection hiccup before you know it works. That is a calendar constraint, not an effort one, and no amount of paying extra shortens it.
Testing before you risk capital
Three layers, in order, and none of them replaces the next.
Backtesting tells you whether the logic was ever viable. Treat Indian F&O backtests with care: historical option data is patchy, spreads in the tester rarely match what you get filled at, and a strategy tuned until it looks perfect on past data is a strategy fitted to noise.
Paper mode is the layer people skip and should not. The system runs against live prices and real signals, and produces simulated fills without anything reaching your broker. It catches the timing and sequencing faults that no backtest will, and it costs nothing but patience. Every one of our execution tools ships with it for exactly this reason.
Minimum quantity live is the only real test. One lot, or the smallest the instrument allows, for a week. You are not testing profitability at this stage — you are testing whether the orders that appear in your broker account are the ones you expected, at the prices you expected.
A specific thing to verify during that week: restart the terminal deliberately while a position is open, and confirm the system picks the position back up and keeps managing its stop. Better to find that out on one lot than on ten.
What you should get at handover
Agree this before the build starts, not after. A reasonable handover includes:
- The compiled, working tool, installed and confirmed running on your machine
- Every rule exposed as an input you can change — stop distance, target, quantity, session times — without coming back to the developer for a number tweak
- A written record of what was built, matching the specification you signed off
- A support window for defects, so a fault that shows up in week one is fixed rather than requoted. Ours is 7 days
- Clarity on source code. Whether you receive it is a commercial decision either way, but it should be a decision, stated up front, not a discovery
- Confidentiality on your logic. Your strategy is yours; a developer who might resell it is not one to use
Red flags when choosing a developer
- They quote before asking anything. A price given without a single clarifying question is a price that will change.
- They promise returns. A developer's job is to make the software do what you specified. Anyone attaching a profit figure to that is selling something else, and in India that is a regulated activity they almost certainly are not licensed for.
- They never mention edge cases. No question about square-off, rejections or restarts means no live experience.
- Hourly billing with no scope boundary. Ambiguity becomes their revenue and your budget.
- They resist paper mode or minimum-quantity testing. Confidence is fine; discouraging verification is not.
- No named business, no traceable contact. You are handing over your edge. Know who holds it.
A worked example brief
This is the level of detail that gets quoted accurately on the first pass. It took the trader about twenty minutes to write.
Instrument: BANKNIFTY weekly options, ATM strike at signal time, 1 lot
Chart: 5-minute BANKNIFTY spot; trend filter from the 15-minute
Entry long: 5-min close above the 9:15–9:45 high, AND 15-min 20 EMA rising. Buy ATM CE.
Entry short: mirror of the above. Buy ATM PE.
Stop: 30% of option premium paid
Target: 60% of premium paid; trail at 25% once 40% is reached
Time rules: no entry before 9:45 or after 2:30 PM; square off all at 3:15 PM
Limits: maximum 2 trades per day; stop trading for the day after 2 losses
Edge cases: ignore signals after 2:30. On rejection, retry twice at 2-second intervals then skip the signal. On restart, resume managing any open position. No entries on expiry day.
Interface: on-chart display of position, live P&L and the day's trade count. Manual exit button.
Nothing there is technical. It is a trader stating decisions. If you can produce that page for your own setup, you are ready to get it built — and our requirements form is structured around exactly these fields.
Frequently asked questions
Do I need to know programming to get my strategy coded?
No. You need to state your rules unambiguously in plain language, including what should happen in the awkward situations — signals near the close, rejected orders, a terminal restart with a position open. The translation into MQL5, MQL4 or Python is the developer's job. The decisions are yours.
How much does it cost to get a trading strategy coded in India?
Custom development with TradexCodez starts at ₹999, quoted at a fixed price once the specification is agreed. What moves the number is whether the system places live orders, whether options strike selection and multi-leg positions are involved, how much state it must carry across sessions, and whether it needs a user interface of its own. A clear written brief reduces the quote on the same strategy, because most of the cost of vague work is rework.
How long does it take to build a trading bot?
Specification and quoting take 1–3 days. The build runs from 2 days for a signal indicator to around 3 weeks for a multi-leg options system with its own panel. Your own live testing then needs 1–2 weeks, because the system has to meet a trending day, a choppy day and an expiry day before you can trust it. Coding is usually not the longest stage.
Should I build on MetaTrader 5 or directly on a broker API?
If you would describe your strategy by pointing at a chart, build it on MetaTrader 5, where you keep visual confirmation and the ability to intervene. If you would describe it as a table of numbers across many symbols — scanning, baskets, portfolio logic — build it against the broker API in Python, and accept that deployment and monitoring become your responsibility. MT4 remains workable for simple index and futures logic but cannot chart individual stock option strikes, as it has no custom-symbol API.
Can I test an automated strategy without risking real money?
Yes, in three layers. Backtesting shows whether the logic was ever viable, though Indian option history is patchy and tester spreads rarely match real fills. Paper mode runs the system against live prices and real signals with simulated fills, so nothing reaches your broker — this is the layer that catches timing faults, and every TradexCodez execution tool includes it. Finally, run one lot live for a week; that is the only test that proves the orders reaching your broker are the ones you intended.
Will my strategy stay confidential?
It should, and you should confirm it in writing before sharing anything. Your logic is your edge, and a developer who might reuse or resell it is not one to work with. Agree confidentiality, and agree separately whether source code is part of your handover — either answer can be reasonable, but it should be stated up front rather than discovered later.
The one-line version
Spend an hour writing your rules down, including the awkward cases, before you talk to anybody. That hour is worth more to the outcome than any decision you will make afterwards about platform, price or provider.
What a finished build looks like
An example of coded work in use: a one-click execution panel with stop-loss, target and trailing attached automatically on fill. This started as a specification much like the one described above.
Get your strategy quoted
Tell us the rules — MT5, MT4 or any broker API. You get scope, timeline and a fixed price before any work begins. Custom development from ₹999.
See how custom development works →TradexCodez supplies trading software and custom development services only, and does not provide investment advice or trading recommendations. Nothing above is a suggestion to trade any strategy described. MetaTrader is a product of MetaQuotes Software Corp.; we are an independent software provider, not affiliated with or endorsed by MetaQuotes or any broker. Broker API limits, exchange rules and regulatory requirements are set by those parties and can change. Automated trading carries risk of loss; test every system thoroughly before deploying it with real capital.
