My Story

The Need

Symmetry needed a Payments & Filing product — the ability to actually pay employees and file taxes, not just calculate them. I had just spent 18 months at Gusto learning exactly how to build this.

The Solution

Gusto's payments library was written in Ruby for internal use only. I extracted the library, figured out how to run it locally using Packwerk, then used JRuby to wrap the Ruby code behind a Java interface. This let our Java shop interact with battle-tested Ruby domain logic through familiar API calls.

We designed the initial POC as a stateless REST service, hoping to reuse as much of Gusto's rich domain logic as possible. The codebase was mature and well-tested, but the domain was deep — too much to fully understand in the timeline we had.

The Pivot

After product research, we realized a stateless REST interface wasn't ideal — payroll requires too much contextual data per request. In hindsight, we should have simplified the interface rather than trying to use the library's API as-is.

The POC worked technically, but it was the wrong product. We pivoted to building a new platform designed for scale, with a more traditional architecture for handling large payroll datasets. We're now leveraging AI to make the system more data-driven rather than porting hand-coded business rules.

The Outcome

Leadership approved the pivot and scaled the team. I grew from 4 to 10 direct reports. The JRuby experiment taught us what not to build — sometimes that's the most valuable lesson. I transitioned to full-time people leadership, only coding nights and weekends on personal projects.

The Need

After Gusto acquired Symmetry in 2021, they needed engineers to help migrate their payments and filing systems to a new internal platform. I volunteered to embed with their team.

The Experience

Mid-2022 to December 2023, I went on what I call a "safari" — joining a Gusto team of 20+ engineers spanning payroll compliance and agency relations. I was a newbie IC in a new domain, new culture, new codebase. The Ruby patterns took time to accept — implicit imports, test inheritance, sparse comments. But I adapted.

Each migration followed a defined pattern, but real-world implementations often required custom classes to communicate with external agencies. Not fully understanding the domain requirements upfront was the biggest challenge.

What I Brought Back

The Golden Master pattern — capturing expected system output as a snapshot, then verifying future changes don't break existing behavior. I've since applied this at Symmetry for safely refactoring complex payroll logic.

I also converted a high-performing contractor to full-time by making the case to Symmetry leadership. Too much domain knowledge to lose — and it maintained our project velocity.

The Outcome

Ultimately, it was a failure. We didn't provide the momentum Gusto needed, and the "one team, one dream" approach didn't align with Symmetry's roadmap. The migration completed in 2025 — well after I'd returned.

But I don't regret it. I came back with the Golden Master pattern, a deeper understanding of a domain Symmetry had never operated in — payments and filing — and a broader perspective on how larger companies work. I also converted a contractor into a full-time hire who's still contributing today. That domain knowledge directly enabled the Payments & Filing initiative I'd lead next.

In 2018, I was promoted to Chief Architect of PaycheckCity.

PaycheckCity Profiles → Payroll

The Need

Users wanted to save their paycheck calculations and run them repeatedly. We saw an opportunity to convert free users into paying customers. As they used it more, they asked for real payroll features — profiles evolved from a time-saving tool into a small business payroll system.

The Architecture

I chose Spring Boot for its simplicity and out-of-the-box features, paired with Angular 2+ over React. This was an application where state management was critical — NGRX made that straightforward. Angular's structure felt familiar coming from Java: opinionated, consistent, no repeating yourself.

For payments, I integrated Stripe with webhooks handling four events: refunds, cancellations, successful payments, and new subscriptions. Subscriptions are annual, and Stripe manages the lifecycle. I built a series of Spring interceptors that parse incoming webhooks, look up the account and subscription, and enrich the request context before any controller logic runs.

The Hard Part

Understanding payroll. I had very little domain experience when I started. I initially used the Calculators by Symmetry API I'd built years earlier as our tax engine interface — but it lacked features needed for a full payroll app. I had to switch to calling our core tax engine directly, which meant cross-team collaboration with engineers who understood the domain better than I did. Using the tax engine as source of truth while learning payroll required patience and a lot of questions.

Building the Team

I've onboarded all but one of my direct reports through this product. My approach: start small. New engineers begin on our Gatsby/React marketing site — smaller footprint, faster feedback loops. After a quarter or two of contributions there, we move to Angular, Spring, and payroll. Complexity explodes, and we spend the next few quarters building features together. It's easier to teach domain on a codebase you wrote yourself.

The Growth Challenge

Our Stripe dashboard tells the whole story: $0 MRR to over $25,000 MRR, all organic. We've never purchased an ad.

The challenge is persona mismatch. Our free site attracts users searching "paycheck calculator" — a one-time action for individuals. PaycheckCity Payroll targets small business owners running recurring payroll. Different user, different search intent. Needle in a haystack.

We never fully optimized for the SMB persona, yet weekly sign-ups have remained consistent for years. There's untapped potential here — the right SEO and positioning could unlock significant growth.

The Outcome

• 2019: Brought on my first direct report — a UI/UX developer
• 2020: Rebranded as PaycheckCity Payroll. Added an Angular developer.
• 2022: 1,500 active users generating $280,000/year

PaycheckCity.com

The Need

January 4, 2011. I joined Symmetry Software as employee #11. My first task: migrate PaycheckCity.com off Classic ASP on IIS. The site had 1.5 million unique users per year and 13 calculators that clients embedded on their own sites.

The Solution

I rebuilt it as a Spring MVC application over 18 months. As a junior engineer working solo, I was paranoid about breaking things — unit tests, integration tests, and JMeter load tests for every calculator. Each release was coordinated with clients who needed to migrate their embedded calculators too.

The site was ad-supported, so I owned that revenue stream. I studied ad formats and placements, built custom JS/CSS to keep high-performing ads sticky as users scrolled, and optimized placement without spamming users.

Responsive & Mobile (2012-2013)

In 2012, I built PhoneGap apps for iOS and Android. Fun project — lots of platform-specific assets, developer accounts, Xcode setup — but overwhelming to maintain as OS updates rolled in. Mobile ads also performed terribly, so we eventually sunset the apps.

On New Year's Eve 2012, I launched a fully responsive redesign — custom CSS optimized for mobile, iPad, and desktop. Our founder sent me a photo of the site running on all three devices at midnight. This was early for responsive design; most sites still had separate mobile versions.

The Outcome

Traffic grew from 1.5M to 11 million uniques by 2019. Ad revenue grew from $120,000 to $600,000 — a 5x increase. In 2019, I migrated the stack again to Gatsby with Prismic CMS (now on Gatsby 5, though I'd choose Astro today).

Traffic has since declined due to lack of active development. Competitors now hold the top two spots for our main keyword — a reminder that SEO requires constant attention.

Calculators by Symmetry (2013-2015)

The Need

We had Calculators by Symmetry running on IIS. I was tasked with migrating it to a modern stack without disrupting existing customer implementations — they had links with API keys embedded in URLs.

The Solution

I architected it as two applications: a frontend widget (jQuery) and Symmetry's first public API (Spring with HATEOAS). I chose HATEOAS so the API would be machine-readable — probably overkill since most clients just used the widgets, but it was a good learning exercise.

I switched from URL-based API keys to embeddable script tags with keys in the tag itself. Used Grunt as a build pipeline to minify, obfuscate, and cache-bust the widgets.

Security was a concern since we charged base fees plus usage. I built a backend system that captured the hostname where scripts were loaded. Clients could enable a flag to restrict their API key to specific domains — preventing unauthorized usage.

Some larger clients were initially wary of running third-party scripts. We hosted their calculators directly for a while until trust was established. Eventually everyone migrated.

The Outcome

The system is still running today with minimal maintenance. Employees can self-serve and determine what their paycheck would be based on W-4 or benefit changes — no HR call required.

Examples of clients using it today:

• PrimePay Salary Calculator
• SurePayroll Salary Calculator

This product generates approximately $1 million ARR.

The Need

Computer Guidance Corporation — a 150+ person company with around 60 engineers in high-walled cubicles — needed help modernizing their enterprise construction management software.

The Experience

As a Junior Software Engineer, I converted legacy UI pages to JSPs with modern CSS styling and fixed Java bugs. The environment was chaotic — my boss was let go after my first quarter, along with 10+ other developers. Some were rehired a few quarters later. I'm proud I survived those layoffs. It was stressful, but I met some smart people who pushed me to grow.

The Outcome

I almost followed a colleague to another corporate job. But when I interviewed at Symmetry, something felt right. Eleven employees, no layers of management, real ownership. I knew I'd have to learn a lot on my own — and that was exactly what I wanted.