Designing a Partnership Without an Interface
Gusto serves 300,000+ US small businesses with payroll and HR. Remote provides Employer of Record services in 80+ countries. In 2023, they partnered so Gusto customers could hire internationally from within the platform they already use.
The catch: this wasn't a typical integration where you "connect" two apps. Remote's product had to appear inside Gusto's UI—pricing, terms of service, account creation, employee onboarding—while Remote handled everything on the backend. The employer sees Gusto. The employee sees Remote. The systems talk to each other constantly. My job was to design that conversation.
The Problem
The problem wasn't just connecting two apps; it was about hiding our complexity
Both platforms had existing flows for onboarding, time tracking, and employee management. Both had different APIs, different data models, different assumptions. Gusto's team had deep expertise in US payroll but had never dealt with global EOR—visa requirements, local labor laws, country-specific benefits. Remote had all that complexity, but no presence in Gusto's interface.
We needed to surface just enough of Remote's product inside Gusto so employers could make informed decisions (pricing, terms, country requirements), while keeping the experience cohesive. White-label, but not invisible—customers needed to know they were signing up for something, they just shouldn't feel like they were leaving.
What I Actually Did
The strategy was to design the system as the product itself
Mapping the APIs side by side
I worked with engineers from both companies to document where data flowed and who owned what. For example, when Gusto collects company details (address, bank account, owner email, country code, desired currency), that data hits Remote's companies endpoint with a specific schema. When employee details come through, different endpoint, different schema. I mapped every field so both teams could see exactly what was required and when.
Designing the visible moments
Inside Gusto's flow, there were specific points where Remote's product had to surface: a popup showing Remote's Terms of Service and EOR pricing before the employer proceeds; the account creation step (though we designed it so "Gustomers" didn't need a separate login); the employee invitation flow where they'd receive a co-branded email. I designed the logic and content for these touchpoints on Remote's behalf.
Defining every email trigger
The employee experience was mostly emails. I mapped five distinct triggers: when the company owner is invited to set up credentials, when an employee is invited to join, when company onboarding completes, when the employment agreement is signed, when the employee finishes self-enrollment. Each email had to introduce Remote clearly without creating confusion about who the employer actually was.
Building the error matrix
A huge part of the work was documenting failure states across both platforms. What if the country isn't supported? What if bank details fail validation? What if employment terms change after contract signing? I catalogued errors from both APIs so engineering could handle edge cases with clear messaging instead of cryptic failures.
process
The process was about mapping every detail of an invisible experience
My core deliverable was a series of Service Blueprints that became the single source of truth for the project. I mapped critical journeys like "Employee Onboarding" and "Time and Attendance Processing," showing who did what, which system was responsible, and how data flowed between them.
This required deep technical collaboration. My role was to constantly ask, "What does this mean for the user?" even when the "user" was another company's system. I focused on the few visible touchpoints, like designing the logic for the co-branded email an employee would receive. This single email had to perfectly establish trust and clarity, introducing Remote as a seamless partner.
By mapping the entire system, we could anticipate edge cases and design for them, ensuring the integration was not just functional, but resilient.
outcome
The process was about mapping every detail of an invisible experience
The integration launched successfully, becoming a major strategic win for Remote. It created a powerful new go-to-market channel and proved the scalability of our platform for these types of embedded experiences.
The success was defined by what users didn't experience: no friction, no confusion, no feeling of being passed between different companies. My biggest takeaway was a lesson in systems design: sometimes the most impactful design work has nothing to do with pixels. It's about architecting the underlying logic that makes
By mapping the entire system, we could anticipate edge cases and design for them, ensuring the integration was not just functional, but resilient.