Services
AI Solutions
Payroll at scale is an engineering problem. Remote solved it by building software shaped around its own payroll operations.
Three numbers show what that shift produced:
reduction in payroll processing time in one of Remote’s products.
payroll accuracy sustained across two years of production, through a period of significant volume growth.
first-time approval rate, above the industry benchmark of the mid-80s.
João Horta, Payroll Engineering Lead at Remote, sums up what made it possible:
“We have complete control. It’s our code.”
Remote needed software that could take over spreadsheet calculations and cross-system data entry, freeing its payroll experts to focus on the tax and compliance problems that actually needed a person's judgment.
The challenge was that payroll doesn't come with a clean product brief. As Horta puts it, this was a mix of tax and payroll requirements with a bit of product in it, not a typical project with a standard spec to build against. Before building the platform, we first had to work out what it needed to do, and that work fell to the people building it.
Nobody handed us a finished spec for any of this. We worked directly from primary sources: tax law and compliance rules, and from conversations with the experts who understood how those rules applied in practice.
Horta describes how that worked in practice:
“The definition of what needs to be done was most of the time done by the engineers. What we got was the capacity to pick up even compliance and tax information on how some tax works and be able to transform that into the requirements that they would use to implement.”
He draws a clear distinction between the kind of engineers the project needed and the kind most teams expect:
“There is a difference between an engineer and a product engineer. We wanted engineers, and we got product engineers, which is very helpful in this case.”
In practice, this meant our engineers worked through ambiguous rules directly with the experts who knew them. Sometimes that meant independent research first, then going back and forth about why a particular tax rule worked the way it did, right down to specific legal articles. Building the software ourselves gave us a kind of ownership that let us keep evolving it without losing the people who understood it best.
We contributed to the general platform, one workflow at a time. The pattern was consistent: Remote’s experts would flag a manual step, we’d learn the rule behind it, and turn it into part of the software.
Larger architectural decisions were made the same collaborative way, jointly by Remote and Appunite engineers. We built the reporting module first for one country, scoped to what was needed immediately but designed with future use in mind.
That was a deliberate engineering tradeoff made with the Remote experts closest to the work, balancing speed to release against long-term platform health.
Every new country brought new requirements, and we had to adapt the shared core to accommodate them. The original approach stopped scaling, and as Horta puts it, “there was no SQL magic that would save it”, so we rebuilt it and moved on.
The numbers reflect a platform in active production, not a proof of concept:
That kind of reliability only happens when people actually trust the software they depend on every day.
More important than the numbers is what they freed people to do. Horta captures it well:
“Difficult tax problems their customers have, ones they can help solve, instead of pressing buttons and comparing spreadsheets.”
Learn more about Remote at remote.com
