The business wanted fewer clicks. What people actually needed was fewer decisions. Setting up a managed database on DigitalOcean means picking an engine, version, region, plan, storage size, availability tier, name, and project. Every choice costs money and affects performance. Cutting clicks without cutting decisions would solve nothing.

So we said: just tell us what you need, and we'll set it up for you.

Making that real without losing the legitimate complexity underneath was the work.

The flow that shipped lets you type one sentence and get a working database minutes later, with every choice editable and every choice explained. It was one of the first non-chat copilots DigitalOcean shipped, and Kubernetes and Droplet create are being redesigned on the same three steps.

Don't change what someone came to do just because a chat box is easier to build. People come to create a database, so that's where we met them. The copilot is a new way to drive the existing flow, sitting next to the manual way, one click between them.

Most teams borrowed the chat-box pattern from ChatGPT and put it everywhere. For production software it's usually wrong. A create flow has a shape: decisions, a result to check before committing, real consequences for errors. A form is where that lives, so the copilot fills the form and waits.

Step one is a single text box that asks you to describe what you need. We pre-load four sample prompts so the empty box isn't intimidating: a staging Redis cache, a production MySQL with backups, a low-cost dev MongoDB, a sensitive-health-data scenario. The samples are a little ambitious on purpose, to show the copilot understands a description and isn't matching keywords.

Step two is six summary cards in a grid, one per decision: engine, plan, storage, region, name, and project. Each card shows the choice the copilot made and a “Why this choice” link that explains it in plain terms, tied back to what you typed. It picks PostgreSQL because the prompt mentioned analytics, a two-node HA cluster because production was implied, and the Frankfurt region because your IP suggested EU traffic. You can accept any card or change it right there, no reload.

Step three is confirmation and creation. The provisioning screen shows a progress bar with a realistic estimate, a final summary the user can screenshot to share, and a next-steps card with the four things they're most likely to want right away: whitelist IPs, connect the app, test, copy the connection string.

For someone who knows what they want, the whole thing takes about thirty seconds. For someone less sure, the “Why this choice” explanations turn it into a small tutorial.

Control is harder. The user has to feel like they can intervene at any point, even when the copilot got it right. Three patterns solve this: inline editing on every card, a one-click rerun at the top of step two, and a one-click manual override at any time.

Inline edit was the biggest win. Each card is a real input with the copilot's choice pre-filled. Click engine, change it to MySQL, and the configuration recalculates because the copilot knows what that change means. The user gets a working draft they can change on the spot.

Rerun is for when the prompt was wrong. The user types "low-cost dev MongoDB," sees the config, realizes they need backups, and types again with that constraint. Past prompts stay visible to compare.

Manual override is the safety valve. At any step you can drop down to the twelve-field flow and configure by hand, with the copilot's choices carried over as starting values.

What I'm proudest of is how it changed the way the team thinks. The default question stopped being "should we add AI" and became "where would AI help without getting in the way." The second question leads to better products.

The copilot does real work. The user is still the one who clicked Create.