Building Cascade

Cascade started with a simple observation: the tools that hosting businesses rely on have not kept up with how the industry has grown. Billing is fragmented. Provisioning is manual. Client management is spread across five different systems that do not talk to each other.

The opportunity was not to build another control panel. It was to build the operating layer — the system of record and action that sits beneath everything a hosting business does.

The problem with panels

Traditional control panels solve a narrow problem: giving end users access to their server resources. They were not designed to run a business. As a result, hosting operators end up stitching together WHMCS for billing, Virtualizor for provisioning, a CRM for clients, and spreadsheets for everything in between.

Cascade treats these as a single domain. Billing, provisioning, client management, and product configuration all live in one coherent system with a shared data model.

Building for breadth

One of the earliest decisions was to support multiple product types from the start. Web hosting, game servers, LXC containers, databases — these are distinct product categories with different provisioning models, but from a business operations perspective, they share the same fundamental needs.

The Cascade architecture reflects this: a shared core with product-specific modules that extend it without fracturing the experience.

Where we are

Cascade is currently in early access. The billing and client management systems are live. Provisioning integrations are being expanded. The interface has gone through several rounds of refinement to get to something that feels as precise as the work it supports.

Building infrastructure software quietly is one of the harder things to do. But it is the right kind of hard.