Thredd is an enterprise payments platform: card issuing, accounts, products, client lifecycle, payment integrations, and the operational access around them. My main surface was Client Access, the web console and API platform teams use to manage clients, accounts, products, cards, payment networks, key management, and the API hub.
I worked there as a staff engineer and technical lead contributor inside Client Access. It was a large, multi-team product, and my work ran the full height of it: frontend architecture, the design system, a GraphQL-to-REST migration, backend API and orchestration services, the API specs and contract tests, the documentation portal, and the AWS deployment around it.
What I built
On the frontend, I built and grew the Client Access console, the React shell, navigation, client scoping, auth gates and role checks, feature flags, and the domain module structure, then filled it with the actual workflows: client lifecycle administration (clients and sub-clients, financial and instrument products, account holders, ledgers, fee and limit masters, scheme reference data), customer account operations (search, account creation and views, ledgers, balance adjustment, transactions), and payment-integration management (connection wizards, network configuration, admin tables, dashboard metrics). Alongside that I worked on the shared frontend platform: design-system components and tokens, Storybook, generated GraphQL and REST clients, i18n, and the Vite/Biome/Vitest tooling.
I also led much of the GraphQL-to-REST migration, the Orval code generation, REST client hardening, region-aware configuration, and the role and feature-flag changes that came with moving live product areas across without breaking them.
On the backend, I built API and orchestration services: service scaffolding, async gRPC clients, domain routers and shared models, OpenAPI metadata, problem-details responses, JWT claim forwarding, request middleware, structured logging, and local mock servers. I ported and tested orchestration workflows across client lifecycle, customer accounts, instrument issuance, reference data, ACH, and credit.
The last piece was API governance: the documentation portal and API hub, OpenAPI source bundling, public versus internal spec generation, problem registries, change-classification tooling, Postman and spec downloads, and the guides, plus the validation, coverage thresholds, and AWS delivery (Terraform, Lambda, ECS, API Gateway, and the rest) that kept it all shippable.
Hard parts
The platform combined real payments operations with a sprawling internal API estate, so the frontend could never be a thin layer over endpoints. Client scoping, region config, roles, feature flags, the in-progress API migration, orchestration state, and operational visibility all changed what a given user could actually, safely do, and the UI had to reflect that honestly.
API governance was the other genuinely hard part. Moving product areas from GraphQL toward REST meant generated clients, consistent error models, OpenAPI discipline, contract tests, and backend parity work, all while still shipping product for teams who were on the platform every single day. There was no freezing the world to refactor it.
Stack
React, TypeScript, Vite, Apollo Client and TanStack Query, Orval, Ant Design, CSS Modules, Storybook, i18next; Python services with Strawberry GraphQL, Pydantic, async gRPC and generated protobuf clients, OpenAPI, Redocly and Bruno collections; Vitest, Testing Library, pytest and mypy; and an AWS estate (Lambda, ECS, API Gateway, Cognito, KMS, DynamoDB, CloudWatch, Grafana) wired up with Terraform and Bitbucket Pipelines.