Fintech software development for systems where a wrong state costs real money

Areas of work

• Trading systems development starts with how fast it has to be

  How fast a trading system must be depends on its job. A bot needs microseconds; most platforms gain more from a fast front end, correct data and scaling.

• Blockchain infrastructure that keeps your chain data correct and current, on Solana and EVM chains

  Blockchain infrastructure on Solana, Ethereum, Base, Polygon and Robinhood Chain: data that stays correct through reorgs, how to serve it, and what it costs.

• Smart contracts and financial applications on Ethereum and the EVM, built so a mistake has a limit

  Smart contracts and financial applications on Ethereum and EVM chains: minimal audited contracts, non-custodial deployment and flows that survive retries.

After an unclear response, send the same transaction again

When a broadcast returns an ambiguous answer, the tempting fix is to sign a new transaction and try again. That is how a system ends up with two trades where it meant one. I save the signed transaction before it is broadcast, and after an unclear response I rebroadcast that same signed payload instead of signing a second one.

A success is recorded from its receipt, matched on the transaction hash, and not from the last response the system happened to see. In one trading system a position was marked failed while its replacement had already succeeded, which is the state this approach removes.

A dashboard can show a price that is hours old

A number on a screen looks current whether it is or not. If the job that refreshes a price has stopped, the dashboard keeps showing the last value it had, and nothing on the page says so.

I put the time a number was captured next to the number, and I alert on a job that stops, so stale data is visible to the person reading it and to the on-call engineer.

A test of a trading system has to be able to fail it

A backtest that cannot say no only confirms what you hoped. I keep data back that the system was never tuned on, write the rule for what counts as a success before the run starts, and check that the simulator behaves like the live system it stands in for.

You keep your strategy. I build the checks around it, and I do not publish strategy results, rules or thresholds.

Reviewed changes arrive in your repositories

An engagement starts with a workflow review. I look at how work moves through your team from ticket to production and what my software factory can take on, and you leave with a plan either way.

After that the factory does the volume, I review what it produces, and you set the priorities without a calendar full of meetings.

Start with a workflow review of the system where a wrong state would cost you the most.