Why Upsun? Crafting a new developer experience through user research
Our newest offering, Upsun, is now live—and we wanted to give you an insider's look into how it came to be. Over the course of a year, we gathered feedback from developers (our primary users) to better understand some of their key Platform.sh product challenges.
Through extensive user research and testing, we identified three key product areas to improve:
Streamlining onboarding and project creation
Providing flexible, container-based resource allocation
Creating a usage-based billing model to cater to flexible resources and more
To set some context, when Platform.sh was built 10-plus years ago, our key target users were building Drupal websites. Today, we have users around the world who build a diverse set of applications, not only Drupal sites. This, along with insights from our research, led us to build a new product with a wide range of new features and to enable functionality, onboarding, and configuration for any application. Read on to find out how we did it!
Making a good first impression: it all starts with onboarding
To begin our journey to optimize our product and deliver the ultimate developer experience, we first needed to streamline our onboarding process.
From feedback gathered through surveys, interviews, and data analytics, we learned that some of our users found our onboarding process simple enough—mostly engineers, backend devs, and those with expert-level knowledge—and had no issue creating a project and deploying code. There was, however, a large portion (48.1%) of our users who found it far too complex to create or build a project, even with our documentation and our at-the-ready support team. Some users found account creation tedious while others had considerable difficulty configuring their projects, connecting their repository and other integrations. In Platform.sh, these setup steps are not in a combined flow. Rather, they’re disjointed and need to be accessed from different areas in the Platform.sh product.
In aggregate, these factors led us to reset our goal: for all new customers to create and build a project with ease—without the need to rely on documentation. We wanted users to see the power and magic of our product sooner by eliminating unnecessary complexity. To reimagine our core onboarding experience, the team stripped back the flow through customer-journey mapping while our engineers led discussions about new and improved ways we could create and configure projects. Our product team pushed for a demo-project-first user experience, enabling users to quickly see how simple projects could be created. In parallel, our product design team led efforts to streamline a new stepped flow and interface that enables users to focus on completing certain tasks without distraction. Our design team prioritized both mobile and desktop views for these experiences.
We shortened our account creation process from four steps to two, introduced an organization-first approach, and moved users straight into project creation, where one of the first steps requires users to connect to their repository; previously, this had been a disjointed step for users and lived within the product’s integrations’ area.
From user experience and interface design perspectives, we created a new onboarding flow for our key account, project, and conversion flows within the product. These new flows are all full-page experiences—a design approach that limits distractions for users during some of our key product moments (e.g., sign up, organization creation, project creation, integration setup). The result? The simpler, smoother onboarding experience developers asked for.
With resource flexibility, the choice is yours
Our next goal was to enable users to size their application and service containers themselves rather than default auto-sizing. We know that every project has different needs—think what you’d need to create a Headless Chrome project vs a WordPress site or ecommerce store. On top of that, every application and service naturally has different CPU (computing), RAM (memory), and disk (storage) needs. We set out to provide this flexibility as well as usage-based pricing for resources.
Originally, our plan sizes (e.g., Standard, Medium, Large, X-Large) restricted flexibility because they had total resource limits. For example, a Standard plan with 0.96 vCPU and 0.75 GB RAM might require a big jump in plan size to get more resources when you may have needed just a little more, for a short period of time. Think Black Friday traffic increasing the CPU and RAM you need only over that weekend.
Our UX team set out to find user flows that intuitively and easily enable users to configure and size their own application and service containers. We looked to the obvious pathways:
From the metrics page, when users review the CPU, RAM, and disk performance of their containers
From the Apps and Services cards, which are the visual representation of all user applications and services, with links to view the services page details of those containers
From our environment overview cards, where we summarize total CPU, RAM, and disk resources of the environment
From the services page, the detailed overview of each and every container
And, last but not least, from within our Projects billing page, where users can compare the resource allocation of all environments and view resource costs
With Upsun, users can now set the size of any container's CPU, RAM, and disk as well as increase the number of instances for any application (a brand new feature) through the product. Memory ratios are now also configurable through the CLI (the CPU-to-RAM ratio), and we provide more transparency to containers’ memory ratio in the configuration screen.
Giving users the flexibility and control to size their projects, applications, and services allows them to size containers however they need to suit their applications and sites while only paying for the resources they want and use. This freedom has underpinned the Upsun flexible-resources initiative, and, in turn, led us to change our pricing model. Moving away from set plans into resource-based and flexible, usage-based pricing as well as looking more broadly at our tiers and business offerings.
Organization-first user pricing
Flexible resources were just the beginning of our new pricing model exploration. When we dove into creating a new pricing model, we found an opportunity to change how our user licenses are built and charged. Previously, users were billed for every user on every project. To put this into perspective, say you had a team of five agency developers working on new website projects every week/month/year, at four projects/month. For every project, you would be charged $10 USD/user/project. This looks like this:
Project 1 x 5 users = $50 USD
Project 2 x 5 users = $50 USD
Project 3 x 5 users = $50 USD
Project 4 x 5 users = $50 USD
Total user license fees for the month = $200 USD, (even if it’s the same development team users working on your projects).
This model isn’t ideal for an agency; typically PaaS and SaaS products bill per user license not per project access granted. So, we looked for ways to move our user licenses to an organization object, where user licenses are billed once, with the ability to grant access to any projects without incurring any additional costs. This results in a cost similar to:
Organization A, with 50 projects and 5 users = $50 USD total user licenses
Moving to an organization-first experience in our onboarding flow—and moving our billing to the organization—were fundamental shifts not only in user experience, but architecturally through our billing infrastructure. Both have resulted in huge benefits for Upsun users.
Building Upsun
A lot of what we’ve done with Upsun is built around giving users more freedom and control to do more of what they want, how they want, and when they want. We’ve created a product that targets diverse applications, with a user experience tailored for individual contributors. We achieved this in under a year by introducing self-service and usage-based billing, with an organization-first approach.
Upsun became a playground to try, fail, and iterate rapidly in many ways, across many features. In building Upsun, we’ve worked on more than 20 new feature projects this year alone, encompassing emails and conversion flows, repository connection, scaling resources vertically and horizontally, teams—and let’s not forget the big visual branding changes on the frontend side, which we’ll cover in an upcoming article. Stay tuned for that because it’s a fun one.😉
In the coming months, as we continue moving through its beta phase, Upsun will continue to evolve and improve with all of the user feedback we receive. So, if you haven’t already, sign up for a free trial to test Upsun. Let us know what you think, and then watch its evolution firsthand.
