Kinsta
Kinsta expanded beyond WordPress, but adoption was slow. I pushed to remove the paywall and redesigned fragmented flows into one clearer journey, cutting time‑to‑first‑deployment by 62%.
Hosting services
4 months
2023
At a glance
Reduced median time to first application deployment by 62%, from 8 to 3 minutes.
Removed upfront payment for first deployments by introducing free, limited‑usage credits with background fraud checks.
Redesigned authentication and first‑deployment flows across previously fragmented services.
Simplified signup and authentication while aligning multiple teams and stakeholders around single, coherent flow.
Team setup
I was the Senior Product Designer leading this work, owning the journey from signup to first application deployment end‑to‑end.
I reported to the Head of Design and Head of Product, and worked with PMs, designers, and engineers across several teams, as well as partners in security, legal, support, and marketing, since the changes to signup, authentication, and first deployment touched most parts of the product.
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.
That new audience were used to trying several platforms and only committing once they had seen their own code deploy. They judge the platform on logs, reliability, and deployment behavior, not marketing pages.
The idea was to leverage Kinsta's established WordPress reputation to position custom hosting as the new flagship product.
Charging before proving value
I analysed the end‑to‑end experience of our competitors from signup to first deployment, when looking at our own platform one pattern stood out: developers coming from app‑hosting campaigns dropped off at signup far more than our WordPress audience.
Payment before evaluation
New users were asked to pay before they had any evidence that the service fit their use case, while several competitors let you deploy first and only asked for signup or payment once your app was already running.
Slow path to value
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.
Fragmented journeys across services
Each service had their own patterns and flows, making Kinsta feel like three loosely related products rather than a single platform with a clear mental model.
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.
Misaligned with how developers actually evaluate tools
Insights from the research team and interviews with developers, showed that the minimum requirement was “my own code is running and I can see detailed logs”, before other platform capabilities were considered.
There were no explicit success metrics, so I defined mine as: number of new signups who made a first deployment, and a median time from signup to deployment below 8 minutes.
We were forcing custom‑hosting developers through a WordPress subscription mindset and, in practice, charging before proving value.
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.
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.
Designing the first deployment
With payment no longer blocking the door, I focused on getting developers through their first deployment in less than 8 minutes.
Mapping the end‑to‑end journeys surfaced around 80 separate points of friction 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 and using modals only for optional configuration.
Using the new brand, I explored several approaches to guide users to the first deployment, from a minimalist flow to more advanced setups that exposed a lot of configuration up front.
With the release still positioned as a visual refresh and the functional scope unclear, I presented four technically feasible directions, each requiring a different level of effort.
Reviewing these options with stakeholders made it clear that small, incremental tweaks to the existing modal flows would not be enough for custom hosting to earn its place as Kinsta’s flagship.
We decided to move forward with a more opinionated design I had initially discarded because it required more implementation work.
The resulting design satisfied the need for simplicity and reduced friction in the most common case: authenticate with Git, pick a project, and deploy without unnecessary dropdowns or configuration steps.
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.
Supporting changes that made it work
Simplifying signup 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.
Unifying authentication
I redesigned the authentication flow to reduce friction and unify the experience. 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. That collaboration later informed a decision to give one team clear ownership of authentication.
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. This moved us much closer to the “try before you buy” experience we saw in competing platforms.
Removing the upfront payment requirement for first deployments, combined with the simplified flow, increased the share of new signups who deployed an application.
I no longer had access to detailed product analytics after leaving the company, but early feedback from the team showed more developers using free credits to try the new hosting services.
Reflections
Not everything about this shift landed smoothly.
While the new flow made it easier for developers to try Kinsta, long‑time WordPress users felt their core use case was being deprioritised.
Referral partners who had sold Kinsta as “the safe, fast home for WordPress” found it harder to tell a simple story about a broader, less focused platform, and sentiment on social channels reflected that tension.
After I left, the business ultimately chose to separate WordPress and custom hosting into distinct services again.
Looking back, I would have pushed for more research into how the core WordPress audience and partners might react to new services, and for more explicit, early communication about what was not changing for them.