The Platform We Built Because We Kept Rebuilding the Same Backend

Each client site needed the same foundations: analytics, form handling, SEO data, content, a CRM to receive leads. Building those per project meant a tenth of the functionality for three times the development time, and every site aged separately.

We built the platform once. Two NestJS APIs, one for business data and operations and one for AI, sitting behind a shared multi-tenant model of organizations, projects, and plans.

New sites connect to a mature backend on day one instead of growing a thin one over months.

A powerful API that every project has to integrate by hand is just a different kind of repeated work.

We built an SDK. One npm package with 100 public entry points covering SEO, analytics, forms, blog, commerce, bookings, reputation, images, redirects, sitemaps, and AI discovery, authenticating with a single project key so sites never handle project identifiers. Seven of those exports are versioned wire contracts shared by the sites and the servers, with a runtime version-skew warning when they drift.

Connecting a site is an install and one environment variable, and every site inherits improvements as the package version moves.

An agency managing dozens of client businesses, an independent business managing itself, and the platform operator all need genuinely different access to overlapping data.

We modeled organizations by type with agencies managing client organizations, projects carrying their own plan tier, and a plan guard that gates AI features at the request level. The tiering is data, not scattered conditionals, and platform administrators bypass it explicitly rather than accidentally.

One system serves agencies, their clients, independents, and operators without forking the product.

An assistant that can change a live business system is only safe if there is a structural answer to what it may do without asking. Ten separate features each inventing their own approval flow is how that goes wrong.

We built the Action Ledger, with one rule: new capabilities do not create their own proposal tables, status enums, or autonomy switches, they register on the ledger. Autonomy is a per-project policy with a mode for each action class, a daily cap on automatic changes, a confidence floor that demotes automatic to proposed, and automatic revert. The agent itself can only file proposals; it never applies changes directly.

Agent capability and agent authority are separated by architecture rather than by prompt instructions.