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.

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. The copilot fills the form and waits.

Embedded just means the AI shows up where you were already headed. No new screen to learn. The copilot fills in the fields and lets you check it.

That placement decision is the whole point. The same pattern works for Kubernetes setup and Droplet provisioning now, because it meets people in the moment they're actually making something.

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 deliberately a little ambitious. They show you the copilot actually understands what you're describing, well beyond keyword matching.

The user types. The system parses. Step two opens up the result.

Step two is six summary cards in a grid, one per decision. Engine, plan, storage, region, name, 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. PostgreSQL because the prompt mentioned analytics. Two-node HA cluster because production was implied. 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, plus a final summary the user can screenshot if they need to share it. The next-steps card on the right gives them the four things they're most likely to want immediately: whitelist IPs, connect their app, test, copy 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 little tutorial. And if you'd rather set everything by hand, the manual flow is one click away at any step.

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 to MySQL, the configuration recalculates instantly because the copilot knows what that change means. The user is never locked in. They get a working draft they can change immediately.

Rerun is for when the prompt was wrong. The user types "low-cost dev MongoDB," sees the config, realizes they need backups, types again with that constraint. Two seconds, full reconfiguration. Past prompt history stays visible to compare.

Manual override is the safety valve. At any step drop down to the twelve-field flow and configure by hand. The copilot's choices come along as starting values. Nothing is lost.

These three patterns give the user real control. The copilot does the heavy lifting. The user is in charge.

The pattern transferred. Kubernetes setup is being redesigned with the same three steps. Droplet create is next. Each new flow takes less time because the control patterns, explanations, and manual fallback already exist.

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

The copilot does real work. The user is still the one who clicked Create. We aimed for that.