November 15, 2022
Here at Stytch, we’re focused on building great developer experiences — for our customers and our coworkers. Engineers’ time is a precious resource, and we want to do everything we can to make sure it’s spent efficiently and effectively.
For customers, we’ve created a suite of developer-friendly auth solutions with our API and SDKs, which allow developers to experiment and compare authentication solutions easily, and get up in running in a matter of hours.
In house, we need an equally strong developer experience to deliver on continuous improvements and features. We owe a lot of our agility, responsiveness, and speed to working in a remote development environment.
But it wasn’t always that way! In this series, we’ll go over some initial challenges our engineering team faced with local development, why we moved to the cloud, and some of our favorite fixes and tools for making remote dev work as efficiently as possible.
In this first installment, we’ll go over:
Remote development requires moving your team’s development environment outside of your local machine. Typically, this means moving the development process into a container or virtual machine (VM) in the cloud, and having a tool to sync the code from a developer’s machine to that remote environment. From there, a developer can build and run their service without being bogged down by the limits of their local machine.
The biggest benefits of remote dev are centralization, scale, and efficiency. Remote dev centralizes tooling versioning and updates, as well as idempotent resources, so there are no surprise edge cases in individual devs’ machines. Remote dev also helps maximize developer productivity by no longer limiting engineers to RAM or CPU of their individual machines, by minimizing differences between development and production, and by creating consistent and repeatable steps for developers.
But migrating to remote dev is not without its challenges. Many companies delay their migration to remote dev because doing so creates a lot of initial friction to the development flow and requires a lot of time and person-power to get set up. This is why it’s more common for large enterprises like Google and GitHub to operate in a remote environment, but less common for startups like Stytch. For many, the up front costs are too great to justify when a company is getting off the ground.
We can think of the tradeoff between local dev and remote dev as a function of two variables: the size of your team and the size of your software services. As both of those sizes increase, the scale tips towards remote dev as the more productive way to develop.
In the first few months of Stytch’s life, we had one goal and one goal only: ship. A couple months after we launched our first product Email Magic Links, we took a step back to evaluate our development cycle. We wanted to take a strategic stance on what kind of developer experience we wanted to build in-house, and what we needed to meet our goals of becoming a preferred auth provider on the market.
Some things were apparent from the outset, just from roadblocks we’d hit in our day-to-day flow.
For example, doing something as simple as editing our email template in our dashboard required running every service. This turned what would optimally be small tasks into time and resource intensive undertakings. And when we did ship features, we couldn’t guarantee that the development process was consistent. We even shipped a bug very early on because an engineer was writing a feature in the API with Redis disabled on their local machine. Local development was starting to slow us down.
Before we took on our first customers, we wanted to minimize delays and mishaps like this as much as possible. As we looked at the bigger picture, we identified five main productivity drags in our dev environment we wanted to address:
With these five factors in mind, we set to work defining our ideal development environment.
To meet our goals of scale and deployment speed, we had clear specifications for what we needed from our development environment. It needed to:
With these requirements, we first considered improving our local development environment, to defer the leap to the cloud. We saw three options:
In the end, we realized we needed to move ALL development into the cloud to meet our full requirements. Whatever initial set-up or resourcing might be required up front, we felt it was well worth it. Especially when we saw other startups who had deferred the decision and paid for it, we wanted to save ourselves those kinds of headaches down the road.
Today, we couldn’t be happier with our decision. But there were some fun challenges along the way we needed to solve in order to make sure remote dev at Stytch could reach its full potential. Namely:
In the rest of this series, we’ll tackle each of these challenges one by one, breaking down each challenge and the steps required to fix them.
If tackling problems like this interests you, check out our career page!
Sign up or talk to an auth expert to learn how you can improve conversion, retention, and security with Stytch.