Trading platform development

It depends on what the platform has to do, and four things move the price most. How many brokers or venues you connect to, since each behaves differently and has to be normalised. Whether you need a matching engine of your own or route orders to someone else’s. How much risk and compliance logic runs before an order leaves. And how much history the system must reconcile against. A single-broker execution tool is a much smaller build than a venue, and most projects sit somewhere between the two. THWorks prices the job rather than the hours: after a scoping call you get a fixed price for the agreed scope, settled before the work starts. If a new feature or another broker comes up midway, that change is priced and agreed with you before it is built, so the total never moves without your say.

Yes. A lot of desks end up with orders managed in one product and execution handled in another, often a tool their broker supplied, and the gap between the two is where positions drift and nobody is sure which screen is right. THWorks builds them as one system. An order is entered, checked against limits, routed and filled in a single flow, and every step writes to the same event log. That log is what lets a desk replay a day, rebuild state after a failure, and answer an auditor without exporting spreadsheets. If you want to keep an existing broker or venue, it becomes one connection behind that layer rather than a second system to watch. TraderOps, the execution platform we run ourselves, is built this way, from strategy to order to fill.

Yes, on both sides. We have worked on WazirX, a centralised crypto exchange out of India, and on the decentralised exchanges tanX and ShibaSwap, as well as Bru Finance, a DeFi lending protocol. The parts that decide whether a crypto venue holds up are the ones equities share: matching, risk and settlement. Two things change the engineering. The market never closes, so there is no overnight window for maintenance or batch jobs, and everything has to be upgradeable while it runs. And on-chain settlement has its own finality rules, which the off-chain order book has to respect. An execution engine for a crypto desk, routing orders across exchanges rather than running one, is a smaller build, and it is where most teams start.

Yes. Our founder was lead product engineer at Multipli.fi, on the matching engine, trade executor and OMS, and we build matching as a production system rather than a prototype. The engine itself is short. What takes the time is the set of guarantees around it: orders processed in a deterministic sequence, so the same inputs always give the same fills; no order ever filled twice, even when a message arrives twice; and a book that can be rebuilt exactly from its event log after any crash. Price-time priority is the usual rule, and other rules are a configuration of the same core. Matching is where correctness under load is the whole job, so besides unit tests it gets tested by replaying real order flow through it.

TraderOps, the execution platform we built and run, connects to eight Indian brokers today: Zerodha, AliceBlue, Tradejini, Zebu, Dhan, Delta, Kotak Neo and Motilal Oswal. QuantLeap, an algo-trading platform we built for a client, executes across multiple Indian brokers from one platform, and we have built a MetaTrader 5 integration for MT5 broker setups. All of it sits behind a broker-agnostic layer that normalises how each broker names orders, reports fills and fails, so adding a broker does not disturb the ones already live. For a broker or exchange we have not connected before, the work is the same shape: read the API, model where it behaves oddly, and put it behind the same layer. On a scoping call we can say how much of a given connection already exists.

Yes. Indian equities and F&O are the market we know best. We are a Bengaluru team, and two of our trading systems run on it. TraderOps lets a trader backtest a strategy, paper-trade it and run it live on the same engine, with trigger prices kept paisa-exact between the three modes. QuantLeap, built for a client on AWS serverless, runs automated options and equity strategies across multiple Indian brokers, with stops that account for circuit limits. The specifics of Indian markets are built in rather than bolted on: exchange circuit limits, broker-specific order types, and the way each broker reports fills. If you need the same for other markets, the engine stays and the broker layer changes.

Yes for reconciliation, and for the compliance tooling around it. We build reconciliation engines that match trades, funds and statements automatically, so a break surfaces the same day instead of at month-end, with an audit trail behind every order and every change to it. Compliance is a different question. We build the mechanisms a compliance process relies on, such as audit logs, pre-trade checks and access controls, but THWorks holds no regulatory licence or certification. Whether a platform meets SEBI, FCA or other rules is decided by your compliance team and your auditors, and we build to what they specify.

Probably. A single strategy running against one broker’s API is a smaller job, and an off-the-shelf tool may already cover it. If it does, we will say so on the call. This work is for the systems underneath a desk or a venue, such as order and risk management, matching and reconciliation, where being wrong once costs real money and the load is real. A good middle ground is often an execution tool: one strategy engine with proper risk limits, which can grow into a platform later.