01
Result
Kinsta’s new hosting product was growing slowly. I removed the paywall and cut deployment time 62%.
Role
Senior product designer
Team
Head of Design, Head of Product, PMs, designers and engineers across several teams
Company
Kinsta · Developer tools, B2B / B2C
Timeline
4 months, 2023 ·
62%
Reduced median time to first application deployment by 62%, from 8 to 3 minutes.
80
Around 80 separate points of friction surfaced across authentication, onboarding, and deployment.
Removed upfront payment for first deployments by introducing free, limited-usage credits with background fraud checks.
02
Problem
From WordPress to custom hosting
Kinsta had earned trust as a safe, fast home for WordPress sites, with a clear promise and a loyal developer community.
As growth in new WordPress sites slowed, we expanded into application and database hosting to reach more technical developers.
The plan was to borrow Kinsta’s WordPress reputation and make custom hosting the flagship.
New audience, new behaviour
The new audience was used to trying several platforms and only committed once they had seen their own code deploy.
They judged a platform on logs, reliability and deployment behaviour, not on marketing pages.
One pattern stood out: developers coming from app-hosting campaigns dropped off at signup far more than our WordPress audience.
03
Friction
8
Median time for a new user to deploy a project.
Depending on configuration, project size, and the path a user took, it could take 3-20 minutes to deploy a project, with new application-hosting signups averaging around 8 minutes.
I analysed how our competitors handled the path from signup to first deployment and compared it with our own.
Charging before proving value
We asked new users to pay before they had any evidence the service fit their use case. Several competitors did the opposite: you deployed first, and they only asked for signup or payment once your app was running.
The research team’s insights and our interviews with developers pointed to the same minimum bar: “my own code is running and I can see detailed logs.” Developers looked at other platform capabilities only after that.
We were forcing custom-hosting developers through a WordPress subscription mindset and, in practice, charging before proving value.
Fragmented journeys across services
Each service had its own patterns and flows, so Kinsta felt like three separate products.
Configuration-heavy
To reach a first deployment, users passed through multiple configuration screens and nested modals, even for simple projects. Competitors who felt faster relied on sensible defaults and exposed minimal configuration on the first run.
There were no explicit success metrics
There were no success metrics, so I set two: how many new signups made a first deployment, and a median signup-to-deployment time under 8 minutes.
04
Paywall
Removing the paywall
Given how many developers dropped off at signup, I proposed moving the mandatory payment step after the deployment, so developers could try the service before committing any billing details.
Concerns from security and risk teams
This immediately raised concerns from security and risk teams. The credit-card gate was our main abuse deterrent, and free access to compute is attractive to bad actors.
Because custom hosting targeted developers who evaluate several platforms in parallel, I argued that we needed to lower the barrier to a first deployment if we wanted them to even consider Kinsta.
Leadership agreed to try the idea by rolling it out slowly and monitoring abuse metrics in exchange for broader access.
We landed on offering free, limited-usage credits for first deployments, backed by heuristic fraud detection running in the background.
That decision let me design a first-deployment flow where a new user could get an application running without ever seeing a payment form.
05
First deploy
The first deployment
With payment no longer blocking the door, I focused on getting developers through their first deployment in less than 8 minutes.
80
Points of frictions surfaced after mapping the end-to-end journey across authentication, onboarding, and deployment.
One of the most pressing issues was that core actions were buried in nested modals that could stack, close accidentally, or fail to load, leaving users stuck.
I proposed moving the deployment steps into a single page
Using the new brand, I explored several ways to guide users to their first deployment, from a minimalist flow to more advanced setups that exposed a lot of configuration up front.
Four potential directions
The release was billed as a visual refresh and nobody had defined the functional scope, so I brought four feasible directions with different levels of effort.
Walking stakeholders through them made it obvious that tweaking the modals wouldn’t make custom hosting a flagship.
We decided to move forward with a more opinionated design I had initially discarded because it required more implementation work.
Reviving discarded work
The resulting design satisfied The most common case: authenticate with Git, pick a project, and deploy. No dropdowns, no config screens.
This layout became the default pattern across services, so application, database, and WordPress deployments felt like variations of one platform rather than three separate products.
06
Authentication
Unifying authentication without breaking legacy systems
I reduced the amount of information collected at signup to lower friction, but had to keep the name fields because they were repurposed as user IDs deep in legacy systems. I worked with engineering to confirm what could be safely removed and what needed to stay.
Three different teams owned different pieces of authentication, so I worked with them to simplify inputs, reuse shared components, and apply the new design language consistently.
Sorting this out across three teams later informed the decision to give one team ownership of authentication.
07
Outcome
62%
Faster deployments, more trials.
Against the metrics I defined, the median time to first application deployment dropped from about 8 minutes to around 3 minutes, a 62% decrease. That put us level with the competitors who let you try before you pay.
Removing the upfront payment for first deployments, together with the simplified flow, increased the share of new signups who deployed an application. I no longer have detailed analytics since leaving the company, but early feedback from the team showed more developers using free credits to try the new hosting services.
08
Reflections
Not everyone was happy.
Long-time WordPress users felt deprioritised, and referral partners who had sold Kinsta as “the safe, fast home for WordPress” struggled to pitch a broader platform. Social sentiment showed it.
After I left, the business split WordPress and custom hosting into separate services again.