If you can't handle the heat of 1 lot, 3 lots will burn down the business.

https://preview.redd.it/q8v0hjrbpn1h1.png?width=1672&format=png&auto=webp&s=b50455077087fc8525fa240ba3953381e61a1f01

In corporate expansion, a business doesn't double its inventory overnight without testing its supply chain and cash flow limits first. In trading, the biggest mistake an option seller makes is scaling up their position size purely because they had a good month. Scaling up is a structural milestone, not a reward for feeling confident.

1. The Mathematical vs. Psychological Reality

On a spreadsheet, the math of scaling is linear: if 1 lot makes ₹2,000, then 3 lots will make ₹6,000. But psychologically, risk is non-linear. When a trade goes against you with 1 lot, a ₹1,500 loss feels manageable. With 3 lots, seeing a ₹4,500 red flash on the screen can cause instant panic, leading you to cut trades prematurely or freeze and ignore your stop loss. Capital badhana 'Easy' hai, par larger drawdown sehna 'Difficult' hai.

2. Testing the Infrastructure

When you scale up, everything is amplified—including your execution errors and slippage. If your system takes an extra few seconds to execute an exit via the API on a volatile Tuesday expiry, the slippage cost on multiple lots will eat a larger hole in your margins. Size badhane se pehle 'Execution Speed' aur 'Slippage' ko process karna seekho. You must ensure your operational infrastructure can handle the increased size before you deploy the capital.

🛠️ My View:

• The Staged Milestone: I don't jump from 1 lot to 3 lots in a single session. I scale by earning the right to trade larger—requiring a fixed number of green weeks or specific equity milestones before adding the next lot. Growth 'Systematic' honi chahiye, 'Sudden' nahi.
• Focus on Percentages, Not Rupees: As a Data Analyst, I train my mind to look at the P&L in terms of percentages or points, not the absolute rupee value. This normalizes the higher numbers and keeps emotional decision-making at bay.
• The Reality: Scale up tab karo jab aapka 'Process' boring lagne lage. If you are still feeling an adrenaline rush at your current size, you are absolutely not ready to increase your risk exposure.

Scale your business based on the stability of your data ledger, never on the high of your last win.

— IAm#Mansis

something thats bugged me for a while. every "which broker API should i use" thread on this sub turns into a brokerage debate. 15rs vs 20 vs per lot, on and on. fine, brokerage matters. but ive been running an intraday options bot for 14 months now and brokerage is probably the 4th or 5th thing id rank when choosing infra.

for context, ive been on Kite Connect the longest, briefly tested Dhan a few months back, and recently moved part of my options execution to Nubra. too early to call any of them perfect. the differences only became visible after i started logging live trades properly.

heres what i now think actually matters, in order. happy to be told im wrong.

1. order-to-ack latency under load

not the marketing number. the actual p95 when nifty moves 60 points in 3 minutes and your bot fires 5 orders in 30 seconds. on quiet days most Indian broker APIs feel fine. its expiry afternoons that expose them. Kite has been the most consistent for me on normal sessions but spikes hard during the 2:30-3:15 window. Dhan felt cleaner in my limited testing. Nubra has been noticeably lower for me on the same Mumbai VPS, especially during expiry spikes, but i want more cycles before treating that as universal.

2. websocket stability during market events

nobody talks about this enough. ive had reconnect handlers fire 3-5 times a week on certain setups, mostly during the last 45 minutes of expiry. heartbeats, exponential backoff, the whole song and dance just to keep the bot alive. so far my newer setup has been calmer on reconnects, but im not ready to make broad claims with this little data. cant overstate how much mental overhead websocket stability removes when you have a day job though.

3. RMS predictability

margin calculations should not surprise you mid-strategy. ive had margin shortfall errors on a hedged position because the hedge leg was still in transit when the margin check ran on the second leg. ended up writing pre-trade margin estimation on my side just to avoid this. multi-leg basket evaluation seems to differ across brokers in subtle ways. worth testing this in your own setup before trusting anyone elses claims.

4. order execution behaviour. partial fills, modify/cancel, rejection clarity

partial fill handling differs wildly. modify-then-cancel race conditions can leave you with phantom orders. rejection codes that just say "RMS:Margin Exceeds" with no detail when youre trying to debug at 3pm. this stuff is invisible in backtest but kills you live.

brokerage is fine to optimise once these 4 are sorted. otherwise youre saving ₹2000/month while bleeding 5x that to slippage from infra issues.

what would you reorder or add? curious if anyone weighs OMS architecture (vendor vs in-house) heavily. ive started caring about it but havent decided how much it matters in retail size.

I run a small Nifty options bot using delta + IV shifts for entries.

Backtests were stable, but every Thursday my live fills looked worse. Same signals, same logic, but entries were coming 6 to 12 points off during fast moves. For a few weeks I assumed the strategy itself was bad.

Then I started logging timestamps properly:

• signal generated
• order submitted
• broker acknowledgement
• fill/update received

That changed how I looked at the problem.

During expiry spikes, one broker API was taking around 350 to 500ms before I got a clean order acknowledgement. Another setup started hitting rate limits when the bot tried to adjust quickly.

I ran the same script from the same Mumbai VPS across Zerodha Kite Connect, DhanHQ, and later Nubra. Same strategy, same server, same order type.

The biggest difference was not the signal logic. It was the API and WebSocket path.

On calm days everything looked fine. But during fast Nifty option moves, the difference between a clean 100 to 150ms flow and a random 400 to 500ms delay was enough to turn a good entry into a bad fill.

Nubra was the one that made me start looking at this more seriously because the API side felt more built for actual bot workflows. Not saying any broker magically fixes expiry chaos, but the infra differences were more visible than I expected.

After logging this, my backtest assumptions became way more realistic. I started modelling delayed entries, wider spreads, and occasional missed updates instead of assuming the bot gets the exact candle price.

For people running algo trading in India, what do you log before blaming the strategy?

Do you track:

• signal to order submit
• submit to broker ack
• ack to fill
• WebSocket reconnects
• rate limit errors
• slippage by broker

Because honestly, I wish I had done this before spending weeks tweaking indicators.