Context
Nasdaq Private Market (NPM) provides liquidity to private companies, their employees and their investors: a place to see what you hold and to trade shares that are not on a public exchange. The data behind it is complex and heavily customised, and the people reading it expect it to be both exact and immediate.
I worked on NPM through OAK’S LAB, as part of a multidisciplinary international team of about thirty people across product, design and engineering. The frontend is a large Nx monorepo, split into a shared design system and one workstation per user type: investor, issuer, broker.
My role
I took end-to-end ownership of core features, including the portfolio holdings experience and the pre-platform onboarding flow. That meant shaping requirements with stakeholders, agreeing scope with product and design, building the feature, and then watching it behave in production rather than handing it over at merge time.
After every sprint I presented progress and technical decisions to senior, non-technical stakeholders. Translating a trade-off into business language (“we can ship this next week with a manual step, or in three weeks fully automated”) is what let decisions happen in the meeting instead of after it.
Portfolio: the feature I lived in
Investors needed to see everything they hold across private companies, next to the platform’s own valuation data, and keep it current without re-typing it.
I built that surface from an empty folder and then owned it for a year:
- Holdings. The table, the holding form and the drawer, across every asset type the platform supports: common and preferred stock, options, warrants, SAFEs and funds, each with its own fields, validation and cost-basis rules.
- Import. A multi-step flow that takes an investor’s existing spreadsheet, matches each row to a company on the platform, shows what will be created before anything is written, and reports per-row errors from the API in language a human can act on.
- Marks. Investor-entered valuations over time, plus the platform’s own marks, drawn together so a holding’s value has a history rather than a single number.
- The portfolio company view. One company at a time, with its charts, its holdings and the market data around it.
The pieces that were hardest were never the screens. They were the reconciliation rules: which holding matches which security, what happens when the same position arrives twice, and how an import behaves when half of it is valid.
The dashboard that got slower
The financial dashboard is where users land and form their first impression. It combines many interactive charts and per-customer customised views, and as the underlying data grew it had become slow to load.
I profiled it and fixed it from both ends:
- Data fetching. Removed redundant calls, broke up request waterfalls, and loaded only what each view actually renders instead of everything the page might need.
- Rendering. Cut re-renders triggered by unrelated state, and made the heavy Chart.js visualisations cheaper to draw and redraw.
Average loading time came down by 66%.
Market intelligence and trading
Beyond portfolio I worked across the platform’s data and trading surfaces: the company summary chart and its bid and offer history, financing rounds and primary-round visualisations, the market feed and its company-centric stat cards, orders and their renewal and expiry flows, sell indications across multiple holdings at once, matches between buyers and sellers with their notes and access rules, and finally an order book for the platform’s new events, which was the last feature I shipped there.
Most of that work is about roles. The same screen has to behave differently for an individual investor, a sponsored investor, an issuer, a broker acting on behalf of a client, and a read-only observer. A surprising share of the engineering is making one component honest about who is looking at it.
Observability and business integration
I instrumented my features with Datadog custom actions, so we could see how real users moved through onboarding and opt-in instead of waiting for a support ticket to tell us. The pre-platform onboarding flow I built feeds Salesforce, which is how the customer-facing teams pick up a lead the moment it exists.
Code reviews and architecture
Alongside delivery I led code reviews and argued for the decisions that keep a codebase this size maintainable: generated API clients over hand-written fetch calls, feature libraries with real boundaries, and a shared component layer that the three workstations actually reuse.