Depth when you want it.
Safety when you don't.

Before this project, getting started with Aerospike meant installing the database yourself, provisioning your own infrastructure, and figuring out configuration from the docs. For expert users, that was fine. For everyone else, it was a reason not to bother.

Aerospike Cloud was the managed offering that was supposed to change that. For it to work, customers needed a self-serve path to production-ready clusters. Not a tutorial, not a preview. A reliable first experience that felt trustworthy from the start.

Managed services have a different bar than self-managed ones. Defaults have to be safe. Misconfiguration has to be hard. Errors have to actually tell you what went wrong. And the whole thing has to be fast. Aerospike's customers are backend, platform, and operations engineers who know their infrastructure and expect precision. A flow that felt dumbed down or opaque would lose them immediately.

Getting infrastructure running was only part of it. The real measure was whether a team could connect their application and get data flowing, all in the same session.

I was the sole designer on the provisioning flow, and took on a large amount of product and frontend ownership alongside it. I defined the overall step structure and sequencing, decided what configuration to expose versus abstract, shaped how advanced settings and JSON/YAML were introduced, wrote tickets, tested implementations, and drove decisions when ownership was unclear.

I worked most closely with the engineering manager, frontend engineers, and backend and database engineers. Product was involved throughout, but I often drove prioritisation to keep things moving.

The engineers who built Aerospike knew the product deeply and wanted the UI to reflect all of it: every configuration option, every advanced parameter. I kept pushing back on that. My read was that real power users were not going to use a web UI anyway. They would be in the API, the CLI, working with configs directly. The UI needed to serve new and intermediate users well, and trying to match the depth of the API would have buried the people who actually needed guidance.

The other thing I pushed hard on was terminology. Aerospike has its own language. Namespaces, sets, records, bins. It needs to be consistent across the UI, the APIs, the docs, and the database itself. If they do not match, users lose trust and the learning curve gets steeper. I spent a lot of time pulling people back to that when things started to drift.

The real problem was not how to build a form. It was how to support two completely different expectations without splitting the product or forcing anyone down the wrong path.

Some users wanted to move fast and trust the system. They were not here to tune replication factors — they wanted a cluster that worked. Others needed visibility and control. These were engineers who ran self-managed Aerospike in production, and they were not going to hand that over to a form with hidden settings.

Design it too simple and the second group would not trust it. Design it too complex and the first group would stall. The goal was to let users choose how much control they needed, without making that choice feel like a burden.

Defaults that reflect how Aerospike actually works. Defaults were not generic cloud presets. They were based on Aerospike best practices and validated with engineers who run and support the database every day. If a user accepted every default, the result had to be something the Aerospike team would stand behind.

Progressive control without punishment. Advanced settings were available without forcing everyone into expert mode from the start. For users who wanted full control, JSON/YAML configuration was exposed deliberately. It wasn't hidden, and it wasn't required. And it was possible to move between modes without restarting the flow or losing context.

Guardrails instead of surprises. Provisioning mistakes can be expensive. Throughout the flow, constraints and validation were designed to prevent invalid or risky configurations before launch. When something was wrong, errors were explicit about what needed to change and why. Error paths got as much design attention as success paths.

Docs as part of the system. Contextual guidance appeared alongside decisions, matched the language and behaviour of the UI, and reinforced the same mental model across UI, APIs, and docs. Users could learn and validate choices without leaving the product.

Provisioning a cluster takes around 20 minutes. Rather than treat that as dead time, the design puts it to use. Once a cluster is launched, users are directed immediately to the two tasks they need to complete before data can flow: set up network access and create a database user. Both are available before the cluster is live, so by the time provisioning completes, most users have already worked through them.

VPC peering was the most technically demanding part of that setup, and the most unusual design problem in the project. Establishing a peering connection requires steps taken inside AWS, an environment Aerospike does not control. Users have to leave the product, navigate their AWS console, collect specific values, come back, and fill in the form. The contextual docs panel, which serves as optional guidance during provisioning, becomes something closer to essential at this step. It opens with a step-by-step guide for exactly that AWS workflow. Around 1 in 4 users who reached the VPC peering form opened it, typically several minutes in, which suggests the inline layout handled most routine cases and the panel caught genuine complexity.

Database user creation was designed to be fast. The main decision was the password: auto-generation was available, and the password was shown once on creation. A CSV export let users store it securely. A small detail, but the kind that becomes a support problem if it is handled carelessly.

The flow shipped as the foundation for Aerospike Cloud's general availability. Completion through the full provisioning wizard came in well above expectations for a multi-step technical configuration flow. The step with the highest average time was the advanced configuration step, at 24 seconds — intentional. Speed where it should be fast, depth where it needs to be.

The average end-to-end provisioning time came in at 72 seconds. The benchmark we had been aiming for was 90. For engineers evaluating a managed service, that is the difference between "this might work for us" and "let's keep looking."

The trend over time was the most telling signal. Validation errors and documentation opens during provisioning both started high and declined steadily as the experience matured — not because usage slowed, but because the UI was doing more of the explaining itself. The default cluster path dominated, confirming the core design bet: defaults were not a fallback. They were the primary experience.

The underlying goal was a team that could go from first click to running cluster to connected application in a single session. Provisioning, the setup prompts, and the network access flow were all built toward that.

Speed and safety turned out not to be opposites here. Advanced users still got a lot from having clear defaults. Error paths and recovery needed as much design time as the happy path.

The other thing I'd carry forward: documentation, APIs, and UI have to tell the same story. When they don't, users lose confidence fast. When they do, people move faster than you'd expect.

For engineers evaluating whether to use a managed service, provisioning is basically the whole pitch. Get it wrong and they're looking elsewhere.

The feedback since launch has been good. I built with growth in mind, so I think the foundations are there. But each new addition will bring its own questions. Pricing models, other cloud providers, backup options. Whether the same principles stretch that far is what I'm looking forward to finding out.