Professional experience · enterprise software
Engineering at Deluxe
R360+ and related work · frontend architecture and delivery
A path from demonstration to customer use, faster builds, and consistent frontend behavior across a large microfrontend environment.
- Confidential employer work
My role: Senior Software Engineer (SWE 5), Deluxe Corporation, October 2022–present.
- React
- TypeScript
- .NET
- AWS
- Harness
- Docker
A firsthand account of my work on R360+ and related Deluxe initiatives. Build timings are approximate; customer onboarding was a team outcome.
At a glance
- Problem
- Product asked for a Deluxe Exchange demonstration that later needed to become a customer-usable product, while the team worked around slow Harness builds, repeated environment assembly across roughly 14 microfrontends, and inconsistent behavior between applications.
- My contribution
- Frontend ownership with a backend counterpart: a mock/live service boundary so real services could replace demonstration data, an independent pipeline investigation, a shared development-only Docker setup, and shell-level ownership of organization eligibility.
- Outcome
- The team developed the cash-application microfrontend into a product customers could use and onboarded three trial customers, a shared outcome. Builds fell from approximately 30–45 minutes to 5–10 minutes by my recollection; other projects adopted the approaches.
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
01
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.
Tradeoff
The alternative was a demonstration built directly on mock data; the boundary was chosen so live services could replace that data without rebuilding the interface.
Outcome
Our 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.
02
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.
Outcome
Build 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.
03
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.
04
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.
Tradeoff
The alternative was fixing each microfrontend's copy; centralizing in the shell gives the behavior one owner at the cost of a shell dependency.
05
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.
Tradeoff
The 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.
06
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.