ops0: Preventive Cloud Security Website Redesign

ops0 is preventive cloud security for cloud infrastructure. It reads what is running across live cloud, finds exposure, drift, unmanaged resources, policy gaps, and cost risk, then moves safe fixes through policy, approval, pull request, and audit.

This is the third website evolution we have built together.

The first two were not wrong. The company moved.

As the product matured, its position became sharper. ops0 was no longer a broad AI DevOps story. It had a clear problem to own: Stop cloud risks before they become incidents.

The third site had to say that quickly, prove it to a technical buyer, and give the ops0 team a system they could keep extending without us.

The brief

Stop explaining yesterday’s product.

ops0 had grown into a deep platform with a simple commercial problem: the old story was wider than the value buyers needed to understand first.

A CTO wants to know where ops0 sits in the stack. A platform lead wants to know how it works with live cloud, IaC, and Git. A security leader wants proof that policy, approval, and audit stay in the path. All three need depth. None wants a twenty-minute orientation before the product makes sense.

So the brief was not a visual refresh. It was three jobs:

1. Own preventive cloud security in the opening screen.

2. Make a technical product legible without flattening it into generic SaaS copy.

3. Build a website system the internal team could continue without an agency queue.

The product was already substantial. The website needed a cleaner way in.

The approach

Positioning before pixels.

We replaced the broad infrastructure-and-AI story with one sequence the whole homepage could support: Find the risk → explain what it affects → move the fix through an approved pull request.

That sequence became the information architecture. It begins with live cloud because production does not always match the repository. It shows impact because an isolated finding is not enough to make a decision. It ends with policy, cost, approval, Git, and audit because a fix is only safe when the path around it is controlled.

Find the risk in live cloud.

Explain what changed, what it affects, and why it matters.

Move the fix through an approved pull request.

The same flow works at different altitudes. A business reader gets the operating model. A technical evaluator gets the mechanics. Neither has to fight through the other’s version of the story.

Every claim had to survive technical scrutiny. Read-only first. Approval before apply. Git stays the source of truth. For a security product, precise copy is part of the interface.

The design system

Security without the theatre.

The category is full of shields, glowing clouds, anonymous AI objects, and feature cards that could belong to any product. ops0 needed a language built from what the platform actually sees and controls.

Resources. Relationships. Findings. Blast radius. Code changes. Policy checks. Pull requests.

Black and graphite create the working surface. White holds the hierarchy. Cyan marks the moments that matter. Motion connects a finding to its dependencies and then to the governed fix. Product UI is used as proof, not decoration.

A brand object in motion, built into the product story.

The system feels like the product: technical underneath, controlled on the surface.

The build

Design and production stayed in the same loop.

We built the homepage in Next.js and judged copy, layout, interaction, and responsive behavior together in the browser. No static handoff followed by a second interpretation of the work.

We ran the workflow from Website designers can’t skip Paper.design. The system lives on a Paper canvas. Claude Code reads it over MCP and writes components into the Next.js repo. Every change is a commit. Codex reviews the pull requests. The canvas is not a picture of the site, it is the same HTML and CSS the site is made of.

ops0 is that workflow on a security product, where a loose claim in the copy is a loose claim about what the software does. AI shortened the route between a decision and a working page. It did not set the standard.

The people making the design decisions stayed with the work until it was live. That is the point of the workflow: fewer translation layers, faster iteration, and clear ownership all the way through production.

The best proof was the pages we did not build

Rango designed and built the homepage. The ops0 team built the rest of the website themselves.

They used the same page logic, components, type and spacing rules, visual treatments, and motion behavior established in the homepage. New product and use-case pages could move quickly without breaking the language of the site.

Rango established the system. The ops0 team carried it across the rest of the site.

That matters more than a long handoff document. A system has done its job when the internal team can produce in it without waiting for the people who made it.

The result is ownership, not dependency.

The result

ops0 now opens with the position the product has grown into: preventive cloud security for cloud infrastructure.

The website moves from live risk to business impact to a governed fix in one connected story. Technical buyers can go deeper without losing the main thread. The ops0 team can keep adding to the site without starting another redesign each time the product expands.

Three rounds of work together gave us context a first engagement cannot. We knew what had changed, what still mattered, and which parts of the old story the product had finally outgrown.

“Great work again. You brought what was in our thoughts to live.”

Suresh Paulchamy

Co-founder and CEO, ops0

View the original LinkedIn post

A growing product will outgrow its website. The job is not to stop that. The job is to leave behind enough clarity and structure that the next change is easier.

For ops0, the third site says what the product has become. The system leaves room for what comes next.

Common questions

What does ops0 do?

ops0 is a preventive cloud security platform. It scans live cloud infrastructure read-only, finds risks such as exposure, drift, unmanaged resources, policy gaps, and cost leakage, explains their impact, and moves reviewed fixes through policy, cost, approval, pull request, and audit.

Why did ops0 redesign its website for a third time?

The product and its positioning had matured. The third redesign replaced a broad infrastructure and AI story with a sharper position: preventive cloud security. It organized the site around finding risk early and moving fixes through a governed path.

What did Rango change on the ops0 website?

Rango reshaped the positioning, messaging, page structure, visual system, motion direction, and homepage experience. Rango also built the homepage in Next.js and created a reusable system that the ops0 team used to build the rest of the website.

How is ops0 different from a cloud security scanner?

A scanner usually ends with a finding or prioritized list. ops0 connects the finding to impact and a reviewed Terraform or OpenTofu fix, then moves it through policy, cost, approval, pull request, and audit before anything changes.

What was the most important result of the website redesign?

The ops0 team could extend the website without Rango. The homepage established the story and system; ops0 used the same components and rules to build the remaining pages while keeping the experience consistent.