Systems · 3 min read

Who owns the system?

Domains, credentials, hosting accounts and source code accumulate around a venture faster than anyone records them. The questions to settle before launch, not after.

A ferry operations control room at dusk, seen from behind an empty chair

The quiet accumulation

A venture in its first two years acquires a surprising number of digital assets: domain names, hosting accounts, email systems, investor portals, booking engines, dashboards, design files, source repositories and the credentials that open all of them. Each is bought or built by whoever needed it that week, often an adviser, a contractor or a founder’s personal account. Nobody intends to leave ownership unclear. It simply never comes up until something must be transferred, renewed or recovered.

Title, custody and the right to use are three different things

A domain may be registered in an adviser’s account, paid for by the client, and used by a subsidiary that does not yet exist. Which of them owns it? The honest answer is that it depends on documents most ventures have not written. The same applies to source code, brand files, data and the accounts that hold them. Project association does not confer title, and payment does not settle custody.

The register

The remedy is unglamorous: a digital asset register, maintained from the first purchase. For each asset it records the registrar or provider, the account custodian, the beneficial owner, the rights of use, who pays, what triggers a transfer, where the backup is and how handover is performed. It takes an afternoon to start and a few minutes a month to keep. It saves weeks at the moment a holding company is formed, an investor conducts diligence or a relationship ends.

Design principles that make ownership real

  • Access control from the start. Named accounts, roles and revocation, never shared logins.
  • Auditability. A record of who changed what, kept somewhere the client can read it.
  • Documentation that outlives the builder. Enough that a competent successor can take over without a conversation.
  • Data held where the client can reach it. Exportable, in open formats, under the client’s own agreements with providers.
  • Pragmatic independence. Open and controllable software where it serves; vendor platforms where they are plainly better, with the exit path written down.
  • Three states, kept apart. A prototype, a deployed system and a handed-over system are different things, and the client should always know which one it is looking at.

Put it in the proposal

These matters belong in the engagement proposal, not in a post-launch tidy-up. A systems proposal that does not say who will own what, in which account, under whose name, is incomplete however elegant the architecture. We write that section first.

Tell us the decision in front of you.

Describe the venture and the question you need answered. We will say plainly whether we can help.