Engineering problem
Build one maintainable frontend around several connected fintech workflows, dense data, permissions and changing product states.
Research Platform
- Focus
- Frontend Engineering / Fintech
- Year
- 2024-2026
- Stack
- React · TypeScript · TanStack Query · Tailwind CSS · Puppeteer
My role
Frontend Engineer + Product Designer. I owned the client-facing implementation and carried interaction decisions into production.
Scope
React architecture · TypeScript · API integration · reusable components · responsive states · PDF templates · analytics and testing
Outcome
Shipped a production client portal spanning company discovery, research ordering, report management, AI-assisted analysis and secondary-market workflows.
I built the client-facing application for a fintech research platform, taking product requirements from interaction logic to production React code. The frontend had to support several connected workflows — company discovery, custom research ordering, report access, secondary-market activity and AI-assisted analysis — while keeping permissions, loading states, responsive behaviour and reusable UI patterns consistent across the product.
Production footprint
20+
production routes
5
connected product areas
3
analytics & feedback layers
50+
automated test suites
The application grew into a multi-area product rather than a set of isolated pages. I implemented shared navigation, reusable data and interaction patterns, route-level product states and consistent behaviour across discovery, research ordering, report management and secondary-market workflows.
Turning product requirements into application structure
The starting requirements described business areas and relationships rather than implementation details. I translated them into application boundaries, navigable workflows, interface states and reusable frontend patterns that could expand as new research and market features were added.
From early implementation to reusable architecture
Early implementations exposed where page-specific solutions would become expensive to maintain. As the scope grew, I moved recurring behaviours into shared components and clearer product boundaries, reducing duplicated UI logic and making new workflows easier to integrate.
Building a maintainable product system
The resulting frontend is organised around reusable product primitives instead of one-off screens. Discovery, research ordering, report access and secondary-market functionality reuse the same state patterns and component language, giving the application a more stable base for continued development.
Keeping complex workflows usable on mobile
The same application states and permissions had to work on narrow screens without simply compressing desktop layouts. I changed information priority, action placement and component composition while preserving the underlying workflow logic.
PWA support and runtime caching made the portal more resilient as a mobile web product and reduced the gap between responsive web and an installable application experience.
Mobile was treated as a constrained product environment rather than a scaled-down desktop. Information priority, action placement and component composition changed for narrow screens while the underlying permissions, research states and workflow logic stayed consistent.
Design system implemented in React
The design system became a production component system with tokens for colour, typography, spacing and state, plus reusable controls and domain-specific components for company data, filters, research access, ordering actions and financial content. The goal was not visual consistency alone, but predictable implementation behaviour across the application.
The production UI was built as a reusable React component system rather than page-by-page markup. Components encapsulated visual states, interaction rules and responsive behaviour so that changes could propagate through the product without duplicating implementation logic.
Server-side PDF rendering
I also built the client-side report templates for a separate PDF rendering pipeline. React-based A4 layouts handled financial data blocks, charts, paginated tables and print-specific composition, with headless Chromium/Puppeteer producing consistent server-side documents.
Working across product design and frontend implementation reduced the handoff gap: interaction decisions could be checked against real component behaviour, API constraints and responsive states instead of remaining assumptions in static mockups.