As applications grow, their size and complexity erode away at their efficiency. As engineers, we know that there are two basic ways to achieve scalability: money and architecture.


We can brute force the problem by throwing dollars at it. App cannot handle enough requests? Buy more servers. It’s taking up too much memory? Resize! It’s the short-term, easy solution, but it isn’t pretty. While your CFO shudders at the soaring operational costs, your engineers watch in horror as hundreds of thousands of lines of unmanageable code pile on top of their once quaint application.


The other, more sustainable solution is distributing both the load and business logic across multiple applications. Each handles a defined subset of the problem and optimizes accordingly. Adopting Service Oriented Architecture means that each individual piece is more focused, and the system as a whole is more efficient as a result. Instead of building one application to do everything ‘okay,’ build multiple applications that solve one problem as well as possible.

Amazon CTO Werner Vogels revealed that constructing their homepage resulted in over 100 service requests. And that was in 2006. Asked about adopting an SOA at Amazon:

It has been a major learning experience, but we have now reached a point where it has become one of our main strategic advantages. We can now build very complex applications out of primitive services that are by themselves relatively simple. We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration.

We believe that what is true of strong engineering practices is also true on the business side. When building Gusto, we specifically set out to solve one problem. It’s right there in our name. But, like a highly distributed architecture, we knew that everything we built could make a much bigger impact if it could communicate and work well with other back-office software.

Traditional business software has been the equivalent of a MonoRail: overcrowded, inefficient, brittle, and sluggish. But we know that payroll is just one distinct piece of a multi-faceted system. Our mission is not only to build a complete payroll solution that’s modern and delightful, but also to actively develop an API to communicate with every related business tool.

For example, imagine you’re managing a large sales force. At the end of every month, you review your team’s performance in your sales CRM. You calculate who hit or exceeded their goals, note that in your performance tracking application, and then give them a bonus on Gusto. That’s far too many steps.

But what if your applications could talk to each other?

Your sales CRM automatically pushes monthly data into your performance tracking application, which seamlessly adds bonuses to your employee’s next paycheck. The future of the back office is defining what you’d like to be done and feeling confident that your tools will handle the execution.

The individual business owner should be able to use us with any other software they like, whether that’s a time and attendance solution or even a custom-built tool. We’re taking what we know about designing scalable web applications and applying them to all the tools required to run a business.