Autonomy is an architecture, not a promise

Any vendor can write a paragraph about how much they respect your data. It costs nothing and it protects nothing. The only version of that claim worth anything is structural: build the product so the vendor is technically incapable of holding your records. That constraint shaped every decision below.

Three things we decided early

01

One product line, never a fork. The moment you let each customer's deployment drift, you have a consultancy pretending to be a product, and the customer whose environment is oldest quietly stops getting fixes. Every account runs the same tested release. What differs is configuration — region, domain, integrations, feature flags — never the code.

02

Managed has to mean managed. Handing someone a repository and calling it sovereignty is passing the operational bill to the customer. We keep the pipeline: releases, schema migrations, secret rotation, monitoring, upgrades. Your engineers should be writing business logic, not running a platform.

03

The exit has to be real to matter. A migration path that only works while the relationship is good is not a migration path. If we disappear tomorrow, the infrastructure keeps serving, the database keeps accepting writes, and your domain keeps resolving — because none of it was ever ours.

The product, up close

Ownership is the substrate. This is the part your team opens every morning — identical whichever cloud account it happens to be running in.

One place where context lives

Pipelines, records, content and ownership in a single view, instead of a spreadsheet reconciled against five browser tabs. Leaders read status without asking for it. Operators see what needs attention next without being told.

Structure that survives contact with reality

Your data model on day one is a guess. Tables, filters and relationships here are meant to be edited as the guess improves, and the same underlying records feed every CRM view, task and workflow in the app — so changing the shape once changes it everywhere.

Numbers, wherever you are

Real reporting on a phone between meetings, computed from the same definitions finance and operations already agreed on at the desktop. Live figures rather than a spreadsheet someone exported on Tuesday.

A board when stages matter more than rows

Flip the same records into a kanban view when the question is what stage something is in. Deals, tasks and content on one pipeline, which ends the argument about whose export was the final one.

Wired into what you already run

Billing, CRMs, productivity tools, AI services. Data moves in both directions automatically, which removes the copy-paste layer and the slow disagreement between two systems that each think they are the source of truth.

How it is built

The interesting engineering in a bring-your-own-cloud product is not the features. It is shipping the same release into dozens of accounts you do not own, every week, without breaking any of them.

  • Two backends, one platform

    postgraph on Django and PostgreSQL for relational and analytical work. nodegraph on Node and RethinkDB for live data and eventing. They hold the same contract, so a customer can run either or both without the front end knowing the difference.

  • Infrastructure as an artifact

    The entire footprint — networking, database, containers, load balancing, CDN, certificates, DNS, secrets, config — is Terraform. It goes up with one command and comes down with one, which is also what makes the exit credible.

  • Strictly ordered deploys

    Infrastructure first, then the backends in parallel, with migrations gated as a one-shot task before any new image goes live. If a migration fails, the new image never reaches the running service.

  • Evidence, not assurances

    “What is in production?” resolves to a pinned version, an image digest and a deployment history your platform team can hand to an auditor. Each environment rides the release train at the pace you choose.

Where this goes

We are building toward a fairly specific bet about the next few years.

AI made the ownership question urgent rather than academic. To be useful, a model has to read the real records — the deals, the documents, the history. Every team is about to discover that the price of useful AI, on the current architecture, is shipping their entire operating history to a third party. Running the model where the data already lives is the only version of that which survives a serious security review.

So the roadmap is aimed at making your account the best place to do that work: model choice under your control, retrieval that never leaves your boundary, and agents that act on your records through the same permissions and audit trail as a human user. Your data, your compute, your policy.

The wider goal is duller and more important. We want boring, well-operated software that a regulated team can adopt without a six-month legal detour — and to be the reason a founder stops treating data residency as the thing that blocks the deal.

If you want a fully operated platform that never takes custody of your data, let's talk.