The Bid & Offer application was an internal tool for reviewing and acting on market opportunities. By the time I took it on, traders were routing around it — entering trades elsewhere, or not at all. That meant the business was quietly losing bid, offer, and spread data that analysts depended on.

On the surface it looked like a performance problem. It was, partly. Grids of 20,000+ records, everything loaded upfront, browsers crashing on the heaviest users. But the deeper issue was that the tool no longer matched how traders worked, and they had voted with their feet.

I owned the rebuild: technical direction, workflow design, and delivery.

Help traders move from information to action faster, with less noise and more confidence.

Context

Trading tools are not generic business applications. They sit inside fast-moving workflows where timing, context, and small interface details change what people do.

A slow or cluttered screen doesn't just frustrate. It changes behaviour. People open extra tabs, export to spreadsheets, build shadow workflows, and eventually stop trusting the product at exactly the moments it should be most useful.

The Bid & Offer app had passed that point. It still worked. It was just asking too much of the people using it, and they had found cheaper ways to get their job done.

Problem

The page loaded everything upfront. Backend queries did more work than they needed to. The frontend then had to render all of it at once — and on grids of 20,000+ records, that meant multi-minute waits and, for some users, a dead browser tab. The infrastructure response had been to add servers, which treated the symptom.

The interface had a separate problem. Important fields sat alongside secondary ones with equal weight. Traders had to scan a lot to answer simple questions: is this relevant, is it actionable, what changed, what do I do next?

And a lot of information arrived in messy formats — email threads, chat messages, copied text, documents — which someone then retyped into the system. That was slow and it introduced mistakes.

Constraints

This was not greenfield. The application supported live trading workflows, an existing data model, and years of operational habit.

  • No big-bang redesign.
  • No interruption to active workflows.
  • Preserve the details traders actually relied on, even the obscure ones.
  • Improve performance without making the system harder to maintain.

A large part of the work was translation. When a trader says a page is slow, they might mean the API is slow. They might also mean the useful information is hard to find, or filtering takes too many steps, or the screen doesn't match how they think about the market. Often all three.

What I did

I spent time with traders during real workflows rather than starting from the UI or the schema. We started from their decision process: what they check first, which fields give them confidence, which details only matter later, which actions repeat, where they hesitate, and where they leave for another tool.

That split the work into two tracks — simplify the interface around the decisions that matter, and fix how data is loaded, queried, and rendered.

Design decisions

The main call was to treat focus as a feature. The old interface showed everything at once. Every field had a reason to exist; not every field deserved the same attention.

  • Primary trade information stayed visible.
  • Secondary details receded.
  • Rarely used information moved into deeper views.
  • Repeated actions became easier to reach.
  • Filters and sorting followed how traders actually hunt for opportunities.

The goal wasn't to hide complexity. Trading is complex and expert users need control. The interface needed to reveal complexity at the right moment instead of all at once.

Engineering decisions

  • Introduced pagination so the app stopped loading everything upfront.
  • Optimised database queries to cut unnecessary work.
  • Returned smaller API payloads scoped to the current view.
  • Rebalanced filtering and sorting between backend and frontend.
  • Reduced rendering cost on large table views and cut unnecessary re-renders.
  • Cached stable reference data where it made sense.
  • Added clearer loading and refresh states.

The point wasn't only the technical metric. A screen that technically finishes loading but leaves users waiting, guessing, or scanning too much still feels slow.

AI-assisted capture (prototype)

Manual data entry was the other drag on the workflow. Bids arrive as email threads, chat messages, copied text, PDFs.

I prototyped an AI capture layer at an internal hackathon — extracting counterparty, product, volume, price, and delivery period from unstructured text, flagging missing or ambiguous fields, normalising inconsistent wording, and surfacing likely duplicates. It got a good reception internally but hasn't been built into the product.

The principle I'd keep if it were: AI reduces admin work, it doesn't replace trader judgment. The trader still reviews and confirms.

Outcome

The rebuilt application went from something traders were bypassing to a tool they open daily. It now takes hundreds of entries a day from users across Europe, Asia, and North America.

Initial load went from minutes to seconds. The browser crashes on large grids stopped, and so did the need to scale servers to compensate. Most importantly, the bid, offer, and spread data the business had been losing started arriving again — because entering it was no longer the slowest part of a trader's day.

What I learned

Trading software isn't only about data and execution. It's about language, trust, and workflow.

Engineers talk about APIs, queries, state, payloads, rendering, permissions, maintainability. Traders talk about price, exposure, counterparty, urgency, confidence, action. You need both vocabularies to build anything useful.

The other lesson: when users abandon an internal tool, nobody files a ticket. They just stop, and the cost shows up somewhere else entirely — in our case, as missing data in an analyst's model. Adoption is a signal worth watching directly.

Reflection

This is the kind of work I like most: close to users, grounded in real workflows, honest about trade-offs.

A faster page is useful. A clearer workflow is useful. A tool people choose to open is worth considerably more than either.