Skip to main content
Mateusz Miszczak

Case Studies

Case Studies

Selected production areas I worked on across fintech applications, delivery and infrastructure, and CMS-driven websites.

  1. 01Realtime · Fintech

    Realtime fintech interfaces

    Frontend Engineer
    Partner panel
    Fintech
    PROBLEM

    The internal admin panel lacked a coherent view of customer accounts. Portfolio data, asset prices and transaction history were scattered across separate screens, with no way to navigate between levels or initiate trading actions directly from a customer's portfolio.

    APPROACH

    Built a multi-level portfolio view with animated account drawers, asset detail panels showing price and transaction history, and transaction tables with type filtering. Rather than refreshing on navigation, portfolio values, asset prices and table contents are synchronized through WebSockets, because in a trading context stale prices are worse than no prices. I also pre-filled the wallet and asset when a trade is launched from an asset panel, so the context the user is already in carries over.

    RESULT

    Users can now navigate from a customer's full portfolio down to a specific asset and launch buy or sell flows directly from the asset detail panel, with the wallet and asset pre-filled. All data updates in realtime, without any manual refresh.

    • React
    • TypeScript
    • Redux Toolkit
    • React Query
    • REST API
    • WebSockets
  2. 02Financial Flows

    Multi-step financial flows

    Frontend Engineer
    Trading
    SEPA
    PROBLEM

    Users needed to execute asset trades and bank withdrawals from within the application. Both flows look similar on the surface, but they have entirely different business logic, validation rules, data models and backend operation states, which made a shared implementation impractical.

    APPROACH

    I deliberately did not unify them behind one abstraction. The surface similarity would have forced conditional branching through every step, and the two flows have no reason to change together. Instead I built two independent three-step flows, an asset buy/sell trading modal and a bank withdrawal system, each with its own Zod schemas, state machine and error handling. Both react to real backend confirmations delivered through WebSockets, not just the initial request response, because a request that returned 200 does not mean the money moved.

    RESULT

    Both flows correctly handle edge cases, including failed transactions, intermediate pending states and network interruptions. Because they are separate, each one can be changed, tested and reasoned about without touching the other, which has already paid off as the trading flow grew more advanced order types.

    • React
    • TypeScript
    • React Query
    • REST API
    • WebSockets
    • Zod
  3. 03Admin Systems

    Admin systems and client onboarding

    Frontend Engineer
    Admin panel
    Partner portal
    PROBLEM

    Administrative operations required complex multi-step forms with regulatory compliance requirements. Search across large user datasets fired a request on every keystroke, because no debounce strategy was in place.

    APPROACH

    Implemented the full user account lifecycle: status changes, access control, account closure and account access recovery. For client onboarding, built multi-step forms validated with Zod and integrated structured compliance data, validating each step on completion rather than on submit, so an operator is not told about a mistake five steps after making it. Added a 500 ms debounce to the search input, tuned to be long enough to absorb typing but short enough that results still feel immediate.

    RESULT

    Search went from one request per keystroke to one per completed phrase, cutting lookup traffic by roughly an order of magnitude on a typical query. Multi-step onboarding forms with Zod validation prevent invalid submissions and give clear feedback at every step, and the account lifecycle is covered end to end, including edge states such as account access recovery.

    • React
    • TypeScript
    • Redux Toolkit
    • REST API
    • WebSockets
    • Zod
  4. 04Tax & Compliance

    Tax management and document flows

    Frontend Engineer
    Tax
    Compliance
    PROBLEM

    Customers needed to view their tax history, select tax years and manage tax document requests, but the UI had no mechanism to stay synchronized with backend operation states during multi-step workflows. Submitting a request gave no reliable feedback on whether it had succeeded.

    APPROACH

    Implemented customer tax history views, tax year selection, tax document tables and complete flows for creating and editing requests. Because tax documents are legally binding, I drove every state from actual backend confirmations delivered over WebSockets instead of updating optimistically, accepting a slightly slower perceived response in exchange for never showing a customer a status that is not real.

    RESULT

    The tax request flow handles all intermediate states, from submission to backend confirmation, without a page refresh. Customers see an accurate status at every step, and support no longer fields questions about requests that appeared to submit but did not.

    • React
    • TypeScript
    • Redux Toolkit
    • React Query
    • WebSockets
    • Zod
  5. 05Marketing & CMS

    Multilingual landing pages and CMS-driven websites

    Frontend Engineer
    Next.js
    Strapi
    Turborepo
    SEO
    Analytics
    PROBLEM

    Two multilingual marketing websites needed to be maintained within a shared Turborepo ecosystem, both using CMS-managed content, cookie consent, Google Analytics and locale-aware rendering. One had to be built from scratch, the second developed further, without duplicating shared frontend logic between them.

    APPROACH

    Built one multilingual Next.js marketing website from scratch and continued developing a second in the same monorepo, working with Strapi content, responsive landing sections, animated layouts and locale-aware rendering. Rather than implementing consent and analytics twice, I extracted them into a shared Turborepo package that both apps consume through a single import and a configuration object, so a change to consent logic is made once and cannot drift between sites.

    RESULT

    One website was delivered from scratch with multiple subpages, animated sections and CMS-managed multilingual content, while the second continues on the same shared architecture. Neither app carries its own copy of consent logic, and new landing sections or locale content can be added without touching frontend code.

    • React
    • Next.js
    • TypeScript
    • Strapi CMS
    • Turborepo
    • Tailwind CSS
    • Framer Motion
    • Google Analytics
    • Cookie Consent
    • SEO
    • Responsive UI
Case Studies | Mateusz Miszczak