At a glance
- Problem
- R360+ serves millions of payment records; related delivery work included a customer-ready demonstration, slow builds, and a fragmented frontend environment.
- My contribution
- I owned the frontend service boundary and improved pipelines, shared local setup, and cross-application behavior.
- Outcome
- The team onboarded three trial customers, and builds fell from roughly 30–45 to 5–10 minutes by my recollection.
Conceptual illustration from the author's account; not an internal Deluxe diagram. The interface reads through one data access boundary that mock data or live endpoints can satisfy.
In words
- The application shell owns organization eligibility gating for the interfaces below it.
- The cash-application microfrontend renders the interface.
- That interface reads through one data access boundary.
- Mock data could satisfy the boundary during the demonstration, and live backend endpoints later.
- Backend authorization remains a separate responsibility.
Derived from the author's account on this page.
Engineering decisions
01decision
Give a demonstration a path to production
Product initially asked for a Deluxe Exchange demonstration. I owned the frontend and worked with a backend counterpart. I structured the frontend around a boundary between mock data and live endpoints, so real services could replace the demonstration data without rebuilding the interface. The demonstration helped Product and leadership decide to prioritize a customer-usable product.
TradeoffThe alternative was a demonstration built directly on mock data; the boundary was chosen so live services could replace that data without rebuilding the interface.
OutcomeOur team developed the cash-application microfrontend into a product customers could use and subsequently onboarded three trial customers. I owned the frontend contribution; product delivery and onboarding were shared outcomes.
02decision
Investigate the build time everyone had learned to tolerate
Slow, unreliable Harness builds prompted me to investigate beyond an assigned feature. I found redundant pipeline work, inefficient dependency installation, and inconsistent Python environments. I introduced Bun for package operations, uv for Python environment setup, and updated the pipeline's Node environment from 16 to 24. These changes addressed several sources of delay and inconsistency together.
OutcomeBuild times fell from approximately 30–45 minutes to 5–10 minutes, and other projects subsequently adopted the approaches. These are approximate timings from my recollection; a measurement window and build-log sample are not published here.
03decision
Make a large frontend environment practical to run
Local development spanned approximately 14 microfrontends and several backend services. I created and maintain a shared development-only Docker setup, documented onboarding, and automated startup of the relevant frontend applications. This moved repeated environment assembly into a common setup that engineers could reuse.
04decision
Put shared behavior at a shared boundary
Organization eligibility behaved inconsistently across microfrontends, particularly those receiving less maintenance. I centralized that frontend gating in the application shell so the user-facing behavior had one owner. This describes interface consistency; backend authorization remains a separate responsibility. I also organized frontend API access around backend domains reflected in Swagger/OpenAPI, giving new endpoints a predictable home.
TradeoffThe alternative was fixing each microfrontend's copy; centralizing in the shell gives the behavior one owner at the cost of a shell dependency.
05decision
Converge implementations in deliberate stages
I contributed to a staged consolidation of prototype and production implementations through routes, loaders, hooks, and tables. Continuing to improve both structures would have preserved their divergence. The aim was to converge the implementations and reduce future duplicate work.
TradeoffThe alternative was to keep improving both structures, which would have preserved their divergence; staging the convergence meant both implementations stayed alive until each stage landed.
06decision
Reproduce the customer's conditions during an incident
A customer could not reach the application while internal checks appeared healthy. I changed my observation point to reproduce the affected regional conditions and narrowed the investigation toward load balancing. The investigation identified an incomplete regional deployment. My contribution was reproduction and diagnosis in collaboration with the infrastructure team.
Basis for this account
- My professional history and firsthand notes supply the actions, approximate timing ranges, and team outcomes described here.
- Employer source code, build logs, customer records, and internal diagrams are not published on this site. These outcomes have not been independently verified here.
- Skillcheck, PixelParity, and AER offer public examples of related engineering practice. They do not substantiate employer metrics.
Source and release links checked .
Scope and limits
This page covers selected work at Deluxe; it does not imply that every initiative was part of the same release. The build ranges do not isolate each change's effect or establish a fixed speedup. Trial onboarding does not establish paid conversion or revenue. Local development tooling, frontend eligibility handling, and incident diagnosis each have the narrower scope described above.
Collaboration in practice
- 01
Make alternatives concrete. When a proposed interaction was unfamiliar, I first clarified the product goal, then prototyped a more familiar pattern so we could discuss the tradeoff using working behavior.
- 02
Support the team's decision. For a shared component library, I built a CSS Modules proof of concept and argued for fewer dependencies and less coupling. The team selected styled-components; I supported the chosen implementation.
- 03
Make review feedback reusable. I pair with engineers on React, TypeScript, state management, testing, and debugging. I have seen later changes need less repeated feedback and rework; this is an observation, not a measured review-time reduction.