LaunchKit
Designing infra orchestration for developers who shouldn't need to think about infrastructure.
Role: Lead Designer
Timeline: 8 weeks (Q1-Q2 2023)
Team: PM + Engineering
We want users to use multiple products
But DigitalOcean is built around single resources
multi-product adoption and integration requires technical understanding and a knowledge of DigitalOcean products. You have to navigate to multiple pages with over 30+ configuration options just to spin up something basic.
6x
Data showed using just two products increased spend by 6x more than single-product users
The platform had no experience for creating infrastructure as a connected outcome. One user wanted to host a video site but had no idea what resources he needed. Another rebuilt the same 3-droplet setup for every client and wished it could be automated. Both were underserved by the same gap. Three themes came up consistently:
- Time consuming — Users were recreating the same stacks across.
- Too complex — Less technical users don't know which resources they need or how to connect them.
- Lack of clarity — No way to tell how much your stack costs.
LaunchKit: a one-click orchestration for your infra stack
LaunchKit was the initiative to close that gap. A set of pre-configured "kits" based on best practices that would let users deploy a complete, connected infrastructure stack in a single flow.
Design challenge: How do you make a multi-resource infra setup feel as simple as spinning up a single Droplet?
Exploring the full experience
LaunchKit went from initial concept to shipped in ~6 months. The backend took longer than expected, which compressed the timeline. There were several key decision points where I advocated for the direction I believed was right. Some went my way, some didn't.
What I pushed for
Progress visibility
There was a window after clicking "create" where nothing visibly happened. Eng wanted to ship without progress indicators. I proposed two weeks of internal testing to confirm my hunch that this would be a blocker in adoption. Internally testing showed users who hit delays kept recreating their kit, leaving behind orphaned resources. This evidence got the decision reversed.
Feedback 1:
A UI change to show stack creation progress would be really nice. It seems the resources need to be created consecutively, so I just see a DB creation in progress for a couple minutes with no indications my other resources (the droplets and LB) are also going to be created.
Feedback 2:
Message about ”resources taking some time"
Feedback 3:
Provide a reminder / popup that the above the resource creation will take a while than normal and for the user to be patient. It would be best to provide an discrete time such as 10 minutes or 15 minutes, instead of a several minutes.
API only release?
Engineering's preference was an API-only beta, which was common at DigitalOcean. But the users most likely to benefit from LaunchKit were the ones least likely to adopt via the API. LaunchKit's value was strongest for less experienced developers who needed a UI, so I pushed for the console to be included in the beta scope.
No user segment
LaunchKit could serve a wide variety of users and use cases. Without narrowing that down, I couldn't make decisions like how technical the content should be. Whenever I pushed for this, the response was: let's launch and learn. So I designed for the less technical end of the spectrum, which shaped everything from the defaults strategy to the level of guidance in the flow.
Tradeoffs
Low discoverability
DigitalOcean's navigation was built around single resources so there was no obvious home for a multi-resource product. With one kit, there wasn't enough justification for prominent placement. Entry points for LaunchKit ended up buried in other pages.
One kit instead of many
Original intent was for a browseable number of kits. Launching with a single generic "high-availability web app" meant we couldn't learn which use cases resonated. It also cut the empty state page, a pattern that had increased creation conversions by 20%.
LaunchKit ran in beta for 3 months
The bet that a single generic kit could generate enough signal to justify further investment didn't pay off. During beta, we saw:
The feedback was consistent throughout the in-product survey and a handful of user interviews I ran.
The experience itself was simple and well-designed, but the single generic kit wasn't useful for production work. Users explored it, found it wasn't customizable enough for their actual needs, and moved on.
Without investment to expand beyond one kit, define a target audience, and solve the reliability issues, there was no path from proof of concept to product.
What I would do today in 2026
With agentic AI, the starting point changes. Instead of pre-building kits for assumed audiences, the system adapts to whoever shows up.
Intent-based creation
Say "I want to host a web app but I'm not sure what I need". We ask clarifying questions, propose a kit, and explain the tradeoffs.
Human-in-the-loop
Generate a visual infra map showing resources, connections, estimated cost, and the reasoning with the option to edit or approve before anything is provisioned.
Self-correcting
An agent that can retry creation, adjust configurations, and visibly explain what it tried in real time. Turns a dead end into a transparent recovery process.