Available now · Fintech engineering · Freelance & full-time
Jigyasu Dhingra
Trading engines, execution infrastructure and financial SaaS - engineered for the millisecond, the edge case, and the audit. Available for project builds, retainers, and the right full-time role at a firm where the infrastructure is the product.
MT4 / MT5 · Binance · Bybit · CoinDCX · CoinSwitch · WebSocket pipelines · Atomic locks · RAG · AI Agents
Every figure is technical and verifiable. Client names and commercials are kept private - as yours would be.
I work with algorithmic traders, trading SaaS operators, and fintech founders who need software that behaves correctly when real capital is on the line.
That means execution engines that fire in milliseconds, integrations that survive a broker dropping mid-trade, and platforms that stay correct under concurrent load. Not demos - production systems, currently running, handling live money.
Since late 2024, I have acted as de-facto CTO for a trading SaaS company - fourteen systems, one engineer, zero missed deadlines. The hard problems get automated. The architecture gets documented. The system keeps running.
If your problem is in this domain, you are in the right place. If it isn't, I'll tell you honestly and point you somewhere better.
Fourteen production systems, grouped into three distinct capabilities. Each card links to the work that backs it.
Simulated demos of three core problems from production: real-time feeds, execution pipelines, and concurrency control.
Not designed to impress with effects - designed to show exactly how these systems behave under load.
Market feed
LIVE SIMOrder pipeline
12msEnd-to-end: <60ms · pre-warmed, no blocking I/O
Atomic lock
exactly-once executionConcurrent requests → only one acquires · rest rejected at lock boundary
Anyone can connect to an exchange API. The value is in what you do when the connection drops mid-trade, when two events fire at once, or when a price won't round cleanly. A few problems I've had to solve properly:
Exchange WebSocket feeds occasionally redeliver the same order event. In a copy-trading engine that means a duplicated trade and real losses. I used an atomic distributed lock with a double-checked read inside it, so each downstream order is placed exactly once - even under a redelivery storm.
One major exchange's REST API is geo-blocked from the deployment region. Rather than relocate infrastructure, the engine rebuilds a live order book in memory purely from the exchange's WebSocket delta stream, with staleness detection and a deadline-based cold-start - so execution never depends on the blocked endpoint.
Under concurrent purchases, a naive stock check lets two buyers claim the final inventory slot. I replaced it with a single atomic decrement that rejects and rolls back the instant it crosses zero - no database lock, no queue, no oversell.
For a hedged position only the spread between the two legs matters, not the absolute price. I built an execution algorithm that scores order-book levels on both exchanges against the target spread and fills both legs in one shot - turning a slow, leaky close into a single clean one.
Languages & runtime
Real-time & data
Infrastructure
Fintech & AI
We get specific before any code is written - the real requirement, the constraints, the failure modes that matter. You get a clear architecture and a plan you can hold me to.
Work ships in reviewable pieces, not a silent black box that appears at the end. You see progress continuously and can change direction early, while it is cheap.
In a real-money system, 'it works' is the start, not the finish. Concurrency, edge cases, failure recovery and security are tested deliberately before anything goes live.
I deploy it, document it, and stay reachable. Ongoing work can move to a retainer so the system has a maintainer who already knows it deeply.
Service 01
A defined system, designed and delivered end to end - an execution engine, a broker integration, a trading platform, a data pipeline. Clear scope, clear architecture, production-ready at handover.
Discuss a project →Service 02
Continuous engineering capacity for a live system - maintenance, monitoring, new features and fast response when markets or brokers change. Your system keeps a maintainer who already knows it inside out.
Discuss an EaaS →
Engineer who chose a hard specialism. I work alone and deliberately - one person accountable from architecture to deployment.
Read the longer story →"Handed him the entire engineering side of the business from day one. Fourteen systems shipped, not one deadline missed - and every hard problem ended up automated."
Ready to talk
Tell me what you're building. If it's in my domain, you'll get a direct, technical answer - and an honest view of whether I'm the right person for it.
Free 30-min call · No pressure · calendly.com/jigyasudhingra