Why Code Branches are Sometimes the Best Option
What is “contractor-only”?
In the first-party Gusto experience, companies can onboard on different “tiers”, each tier offering more and more features. The most basic tier offered is called “contractor-only”, wherein the company can only onboard and pay contractors, as opposed to contractors and employees.
This tier is actually quite relevant to newer companies who might hire only contractors at first, and then employees as their business scales.
How is the experience different from employee-supporting companies?
Besides the additional features included when a company onboards on an employee-supporting tier, there are some significant differences between the employee-supporting vs. contractor-only onboarding experiences. Specifically, employee-supporting companies require the following onboarding information that contractor-only companies do not:
- State tax setup
- Information / setup of at least 1 employee
- Pay schedule setup
Not only are these steps unnecessary for a contractor-only company, but some are not possible to complete. For example, contractor-only companies may not have registered with any state tax agencies since it’s not required of them.
Why do we need to support contractor-only companies?
Since the early days of Gusto Embedded Payroll (GEP), our partners have wanted the ability to support contractor-only companies on their platforms, but have had to turn away contractor-only companies due to GEP not supporting Gusto’s contractor-only tier. One common use case: accounting and vertical SaaS platforms that are focused on helping newly formed businesses, where their first hires are likely contractors. Supporting those companies was a necessary step in empowering our partners.
Roadblock #1: Front-end validations
As an embedded payroll offering, we rely on much of the first-party Gusto logic to power our API. There are times, however, where our partners’ needs might differ from first-party’s, and we need to adapt.
One example that we ran into was the obfuscation of employee-supporting features for contractor-only companies. Most importantly, we wanted to prevent contractor-only companies from running payroll. First-party Gusto handles much of this on the front-end, i.e. if a company is contractor-only, don’t show this “Run payroll” button.
 |
 |
| First-party Gusto employee-supporting company sidebar, “Run payroll” button present | First-party Gusto contractor-only company sidebar, “Run payroll” button not present |
Since we cannot utilize such front-end validations, because frontends are handled by each partner, we created a new “contractor-only” payroll blocker type. By utilizing our existing payroll blockers infrastructure, we were able to block payroll for contractor-only companies in a clean and simple way.
Roadblock #2: Fast ACH speeds
Fast ACH is the ability to pay at 1-day or 2-day payment speeds, rather than 4-day. Fast ACH is a feature of Gusto’s employee-supporting tiers, but not its contractor-only tier. For Gusto Embedded, Fast ACH is a necessity for our partners, regardless of company tier.
The data modeling responsible for first-party Gusto’s contractor-only tier not including Fast ACH is the same data modeling used for “contractor-only” logic throughout the app, and was not something we could simply discard. We looked into the following three solutions:
- Convince the owning team to enable Fast ACH for first-party Gusto contractor-only.
- Not doable: they wanted to preserve the existing tier/feature structure.
- Change the data modeling to enable Fast ACH for GEP contractor-only →
- Not doable: this likely would’ve resulted in unintended downstream effects.
- Create a custom codepath to enable Fast ACH for GEP contractor-only
- Doable: this was our selected solution!
Though branching codepaths are generally less maintainable, sometimes they’re the right decision. In order to minimize downstream effects, it was the right solution in this case.
Project completion
After working through implementation, writing tests, staging test fests, iterating, and writing documentation, we were finally able to release GEP contractor-only! This included API changes, like the ability to create and update a contractor-only company, as well as UI changes in our Flows, like the difference in the onboarding experience for contractor-only companies. This was a big win for us, since it unblocked a large number of companies from joining our platform.
