Why Rollout decided to rebuild their product from scratch: we describe challenges faced with our initial product and how we addressed these with the introduction of Rollout V2.
When we started Rollout, we had a simple plan: give developers Zapier-style integrations natively using React components. Our goal was to make a system where you only need to integrate once, and you get full-stack integrations with an intuitive UI with full control over the product experience.
We've since partnered with over a hundred software companies. We handle millions of API requests, and serve twenty percent more end users each month.
Despite this early momentum, we made the choice to pause and rebuild our product from scratch. This goes against the usual advice of never rebuilding your product, especially for a young startup where growth is key. So, why do this? We had two strong reasons:
Our startup began with a basic product. We added features as customers requested them. But we soon found that more features didn't always solve the real problem or offer the best user experience. And for certain requests, our existing architecture wouldn’t allow us to solve them in a robust way. Here are four recurring problems we heard:
In V1, customers define their triggers, actions, authentication and queries using our Graphical User Interface (GUI):
It was easy to get started with Rollout V1 - I’ve had many onboarding calls where we’ve helped companies implement their first use case in 10 minutes.
But over time, customers started needing more customization. They wanted to format the data from their API, enrich the data with API requests before performing an action, work with various data formats like SOAP/EDI, or run complex business logic in their actions.
So we added a Code Mode runtime so users could customize their triggers/actions by writing their own code. We provided a code editor in the browser, you’d write your custom code in Javascript, hit save and pray that it worked.
V1 Code Mode Runtime
You didn’t have the comforts of your heavily configured code editor like advanced syntax highlighting, linting, autocomplete and now, an AI copilot.
And if you had multiple environments to separate development from production, you’d just have to remember to copy the code to your production Rollout environment.
The common workflow for software developers is: write application code on your local machine where you test and debug it, push it to Github for review & collaboration, then merge it and let a CI/CD system deploy it.
A product that uses a graphical interface (GUI) disrupts this process. The code exists inside our dashboard, separate from any changes you make in your development branch. Testing and fixing problems need a complex setup with tools like ngrok and take more time. Deploying the code is not automatic but a manual process prone to mistakes, often causing your application code and integration code being out of sync.
As we grew to serve customers who sell to enterprise customers or need to comply with Data Protection laws like GDPR, we had to start supporting self-hosting or enabling customers to host in a given region.
We also found that some customers would have massive spikes in traffic which would slow down our task processing for other customers even though we have auto-scaling functionality. This genuinely sucks for customers who have no reason to expect their automations to run slow but are now getting support tickets complaining about this phenomenon.
Rollout's flexibility enabled use cases we hadn't thought of. We were sometimes surprised how many of these it supported, but some were beyond our capabilities. These included: creating custom or proprietary connectors, adding new or custom triggers/actions to our existing integrations, using any NPM package for tasks ranging from encryption to PDF creation, or even importing your own libraries to better integrate your code with your application's business logic.
As we looked at future-asks from our customers, or prospects that we weren’t a good fit for at the time, two themes emerged.
Integrations and automations are such a fundamental part of any SaaS product, companies wanted as much control as possible over everything from data to auth tokens to every aspect of the final product experience.
Customers wanted to build everything from robust 2-way syncs to an automations hub to a platform for other developers to build integrations into them.
To continue building features that enabled both ideas, we realized we needed a change.
Rollout V2 is a new approach to building integrations. It's a code framework for building full-stack integrations, similar to NextJS or Ruby on Rails. You can set up both the backend, like your trigger/action logic, and the frontend of how your users interact and configure the integration. We offer ready-to-use connectors for apps like Salesforce and Slack as well as the engine to manage auth and execute automations. We also host your Rollout application. You can think of your deployed Rollout application as your product’s integrations service.
This approach lets developers write and test code locally, have their integrations code live in the same repository as the rest of their code, and auto-deploy when they merge their code into a specified branch.
Every customer has their own servers, database, and Redis queues. This means your data and automation processing are separated, and you can host in any region easily. You can also directly access your database in SQL and soon, you'll be able to run your own migrations too.
With a framework approach, developers gain more control. They can import NPM packages, custom business logic libraries, or anything else just like in a regular JS/TS application.
Here are some helpful resources to learn more:
Our hope is V2 makes life better for existing customers and potential customers. We’ll report back in some time to let you know how it does!
