Stack

Puzzle's Frontend Platform

Puzzle Financial

Background

Puzzle is accounting software for startups and their accountants. Its web application is a single Next.js, React, TypeScript, and GraphQL codebase.

When I joined, the frontend hadn't had a high-level owner for almost two years, and it showed. The codebase had many open security issues and a long tail of outdated dependencies. There was no shared architecture, no code style guide, and no common idea of where the frontend was going. Features reached into each other. A few global providers held most of the application state, and every new business bet increased the entropy of the codebase.

Role

As the Technical Lead for the frontend platform and application architecture, I set the technical direction while staying hands-on. Between January 2025 and July 2026, I authored around 2,000 pull requests and reviewed 1,300 more in 2025 alone.

I started by interviewing the frontend developers and their stakeholders to understand where the pain was. Their answers, along with our users' complaints about performance, shaped the changes I proposed. From there, I had the chance to:

  • Restructure the application into a modular monolith inspired by Domain-Driven Design, with more than 20 business domains, extract shared packages (dates, money, analytics, date pickers), and break up the global state providers.
  • Lead the Apollo Client 4 migration, GraphQL fragment co-location, and the lint guard rails for queries and schema changes.
  • Roll out server-side rendering to 100% of traffic and build the tools to measure performance: bundle-diff reports, Datadog Synthetics and RUM dashboards, and OpenTelemetry tracing.
  • Enable business initiatives: Light Mode with our Design team, white-labeling foundations for partner demos, and a consolidated analytics stack.
  • Evolve the design system by consolidating buttons and tokens onto one component library and theme package, introducing Storybook from scratch with Chromatic visual regression tests, and owning a new React Aria date picker family from PRD to app-wide rollout.
  • Use AI automations heavily to raise test coverage across the codebase and to review and fix security issues.
  • Shape what the AI tools work from by writing Claude skills that encode the codebase's architecture and quality standards, so generated code follows the same rules as ours.
  • Align the team through RFCs on state management, error handling, GraphQL, domain ownership, and performance, and through a frontend ownership model.

puzzle-transactions

Results

Splitting the transaction GraphQL documents cut the main application bundle by 22%. Fragment co-location reduced GraphQL payloads by about 20% in some cases. Light Mode, our top customer request, shipped across the whole application, and we were able to score some contracts thanks to our themeable UI.

One of the outcomes I am most proud of is the date picker family. It was my second accessible date picker suite after the one I built for Lyft's Design System. This time, adapting an existing library with AI made the work a lot faster and easier, and the new pickers replaced every legacy date input in the app.

Quality also became something CI enforced instead of something reviewers had to remember. As of July 2026, per-folder coverage gates kept the core domains between 96% and 99% coverage, much of it written with AI automations. Chromatic visual regression was a merge requirement, and weekly Content Security Policy violations had dropped by 70%.

A year after the first interviews, I talked to the frontend developers and stakeholders again to check which changes had landed and to plan the next ones.