Designing every company so it could stand alone

Most companies in a group never leave it. But the ones that could are healthier than the ones that could not.

At Oryvelon we design every company so that it could stand alone: raise its own capital, bring in a strategic partner, be spun out, or be sold. We have no plans to do any of those things today. We design for them anyway, because separability forces a set of good decisions that make each company better right now.

This note explains what "could stand alone" means in practice, and the choices we make from day one to make it true.

Why separability matters even if you never separate

There are three reasons to care about separability before it is needed.

It keeps options open. Opportunities arrive unexpectedly: a partner who wants a stake in one company, an investor interested in one market, a buyer for a business that fits their portfolio. A company that can be separated in weeks can take those opportunities. One that needs a year of untangling usually cannot.

It protects customers. The same boundaries that make a company separable also keep its customers' data where it belongs. If a company's users live in its own database, they are not exposed to the others — and they can move with the company if it ever leaves. See Shared infrastructure, separate data.

It makes each company easier to understand. When a company owns its code, data, infrastructure and economics, anyone — a new team member, an auditor, the founders themselves — can see exactly what it is and how it performs.

What makes separation hard

It helps to know what goes wrong in groups that did not plan for separation. The common problems are:

Shared user databases. Customers of several products live in one set of tables. Separating them means migrating data, merging or splitting accounts, and hoping nothing breaks.
A shared identity system. One login for everything. Removing a product means re-issuing credentials to its users and rebuilding authentication.
Code with product-specific exceptions. Shared modules full of "if product == X" branches. Extracting one product means understanding and rewriting large parts of the shared code.
Mixed vendor accounts. One analytics property, one email account, one payment account, one AI key for everything. Separating them means rebuilding history and integrations.
Blended finances. Costs and revenue that were never attributed per product. Nobody can say what the company earns or costs on its own.
Undocumented decisions. Nobody remembers why things are the way they are.

Each of these is a reasonable shortcut on the day it is taken. Together they make separation a painful, expensive project. We avoid all of them.

What each Oryvelon company owns

From its first day, each company in the group owns a complete set of its own assets.

Asset	Owned by each company
Domains	Registered for the company, locked, auto-renewing
Website	Its own site on its own domain
Code	Its own repositories and release cycle
Database	Its own database containing only its data
Users	Its own accounts; no shared identity layer
AI	Its own AI project, keys, prompts, knowledge and budget
Email	Its own sending domain with SPF, DKIM and DMARC
Analytics	Its own properties and measurement
Payments	Its own payment setup where it charges customers
Legal pages	Its own privacy notice and terms
Economics	Its own attributed costs and revenue

The group provides standards, tooling and people who know how to use them. It does not own a platform the companies depend on.

Shared code that does not trap anyone

Companies still benefit from shared code — it would be wasteful for each to write its own form components, logging helpers or security headers. The trick is to share code in a way that never becomes a trap.

Brand-neutral. Shared packages contain no product logic, no brand styling and no business rules. They are building blocks that each company assembles in its own way.

Versioned. Each company depends on a specific version of shared code and upgrades when it is ready. A change in a shared package cannot force every company to release at once.

Replaceable. Because shared packages are small and focused, a separated company could keep using them, fork them or replace them without rewriting its product.

We discuss the boundary between shared and product code in Why we don't merge our products into one app.

Infrastructure that can be handed over

Infrastructure is organised so that each company's resources are grouped together and could be transferred as a unit: hosting projects, database projects, storage, background jobs, monitoring and AI projects. Naming standards — part of step six in our new-company protocol — make it obvious which resources belong to which company.

Access to each company's resources is granted per company and per role. That makes it straightforward, in a separation, to hand over administrative control to a new owner and remove the group's access cleanly. See Least-privilege access for small teams and contractors.

Records that make due diligence easy

When a partner or buyer looks at a company, they ask predictable questions. We keep the answers ready as a matter of routine, not as a special project.

What is this company? The source-of-truth document. See Why every company starts with a source-of-truth document.
How does it make money, and what does it cost? Per-company economics, tracked from day one. See Unit economics per product.
What data does it hold? The data sensitivity classification and data inventory.
Who has access to what? Access lists, reviewed quarterly.
What does it depend on? A list of vendors, tools and shared packages, with versions.
How is it secured? Domain, DNS, email authentication, security headers, secrets management and incident history.
What has it learned? Checkpoint reviews and the decisions made at each one.

A company with these records can go through due diligence in a fraction of the usual time.

Customer relationships that belong to the company

Separability is not only technical. Each company's relationship with its customers belongs to that company:

customers sign up with the company, under its terms and privacy notice;
they receive communication from the company's domain and in its voice;
their support conversations happen with the company;
their consent — for product use and for marketing — is recorded by the company.

If the company ever left the group, those relationships would move with it intact. Nobody would discover that their data had been sitting in someone else's system.

Where the group relationship lives

A company that stands alone still benefits from being part of Oryvelon, and we are happy for that to be visible. The relationship appears in natural places:

a short "An Oryvelon company" note in the footer or on the about page;
a profile on oryvelon.com's Companies page;
mentions in press or partnership contexts where the group is relevant.

What we avoid is making the group part of the company's core identity — the Oryvelon mark is not part of any company's logo, and the group name is not placed larger than the company's own brand. A company's identity should survive intact if the footer line ever changes.

The cost of designing this way

Separability has costs. Some infrastructure is duplicated. Customers who use two products have two accounts. Each company has its own analytics to maintain. Shared code must be kept brand-neutral and versioned, which takes discipline.

We think these costs are small compared with the alternative. And many of them are costs a well-run company should bear anyway: its own data boundary, its own measurement, its own clear economics.

A separability checklist

For any company in the group, we can ask:

[ ] Could we list every resource that belongs to this company in an hour?
[ ] Does its database contain only its data?
[ ] Could its users keep their accounts if it left the group?
[ ] Are its AI keys, prompts and budgets its own?
[ ] Does it send email from its own authenticated domain?
[ ] Are its costs and revenue visible on their own?
[ ] Is its shared code versioned and replaceable?
[ ] Are its access lists current?
[ ] Is its source of truth up to date?

If every box is ticked, the company could stand alone. That is the standard every Oryvelon company is held to.

Three separation scenarios

It helps to think through what "standing alone" would mean in the situations where it could actually happen.

A strategic partner takes a stake. A partner — for example, a business that distributes to the same customers — invests in one company. Nothing needs to move technically. What matters is that the company's economics, data and governance are clear enough for the partner to understand exactly what they are investing in, and that the group's shared services to the company can be described and priced fairly.

The company raises its own capital. Investors want to see a company, not a slice of a group. The records described above — source of truth, economics, data inventory, access lists, vendor list — are exactly what they ask for. The company may continue to use group standards and shared packages under a clear agreement, or gradually take them in-house.

The company is sold. This is the fullest test. Domains, repositories, infrastructure projects, AI projects, analytics properties, email configuration, payment accounts and vendor contracts transfer to the new owner. Access for group staff is removed. Customers continue with the same company under the same terms. Because none of the company's data or identity lives in shared systems, there is nothing to extract — only things to hand over.

In all three scenarios, the work is administrative rather than surgical. That is the goal.

What would stay with the group

Separation also clarifies what belongs to the group rather than to any single company:

the shared standards and documentation;
the operating core's tools and know-how;
the group brand and oryvelon.com;
lessons learned, written into standards so other companies keep benefiting.

A company leaving would take its assets with it. The group would keep the knowledge of how to build the next one.

How separability shapes everyday engineering

Designing for separation is not a special project. It shows up in small, everyday decisions:

A developer adding a feature that needs data from another company is told no — and the feature is redesigned to work within the company's own boundary.
A new tool is set up per company rather than as one account for the group.
A shared package that starts to accumulate product-specific logic is split, and the product logic moves back into the product.
A new environment variable or secret is created in the company's own projects, never in a group-wide store that several companies read.
Costs from a new vendor are tagged to the company that uses them from the first invoice.

None of these decisions is dramatic. Together they are what keeps each company whole. You can see the companies we hold to this standard on the Companies page, and the operating model behind them on the Build page.

Questions partners ask, answered briefly

"If we work with one of your companies, are we also working with the others?" No. Agreements, data and relationships are with the specific company.

"Does the company depend on a group platform that could change under us?" No. It depends on versioned, brand-neutral packages and documented standards. Its product, data and infrastructure are its own.

"Can we see this company's numbers on their own?" Yes. Costs and revenue are attributed per company from the start.

"Who owns the domain and customer relationship?" The company does, with the group ensuring the domain is secured and renewed.

"What happens to customer data if the company changes ownership?" It stays with the company, under the same privacy commitments, and moves with it. It was never stored anywhere else.

These answers are short because the design makes them simple. That simplicity is the practical value of building every company to stand alone.

Worked example: what a hand-over would involve

To test whether separability is real, it helps to walk through an actual sequence. Take KeşifAtlası as a hypothetical case: imagine a partner wanted to take full ownership. Nothing like this is planned; the point is to check that every step is administrative.

Inventory. List every resource tagged to the company — the naming standards make this a query, not a search.
Access freeze. Pause non-essential changes, and record who currently has access to each system.
Domains and DNS. Transfer the registrar account for kesifatlasi.com, then confirm DNS records and email authentication (SPF, DKIM, DMARC) still pass after the move. See Domain, DNS and email security.
Code and infrastructure. Transfer repositories, hosting and database projects, storage and background jobs as whole units.
AI project. Hand over the company's AI project, prompt versions and knowledge. The verified rules database goes with it, because it is the company's core asset.
Secrets. Rotate every key and credential after transfer, so nothing the group once held still works. See Secrets management basics.
Analytics, payments and vendors. Move properties, payment accounts and contracts, each already registered to the company.
Remove group access. Close group staff access last, once the new owner confirms control.
Tell customers what changes — ideally very little: same product, same domain, same privacy commitments.

The shared AI gateway is the one piece that does not move. The company either keeps using it under an agreement or points its calls at its own setup. Because the gateway never merged its prompts, keys or users with anyone else's, switching is a configuration change.

Mistakes that quietly erode separability

Separability rarely fails in one big decision. It erodes through small, convenient ones.

Domains in a personal account. A domain registered by a founder or contractor under their own login is a separation problem waiting to happen. Every domain sits in a company-controlled account.
One marketing list for every brand. Collecting emails into a group-wide list feels efficient, but consent was given to a specific company. A shared list is both a separation problem and a consent problem. See Marketing consent vs product consent.
A "temporary" data join. An analysis that copies two companies' customer data into one place "just this once" tends to become permanent.
Shared test data. Test environments populated with another company's real data blur boundaries in the places nobody reviews. See Environments and test data.
One payment account for convenience. Revenue that lands in a shared account has to be untangled later, along with refunds and disputes.
Tenancy inside a shared app. Keeping companies apart by a column in one database is weaker than separate databases. We explain the difference in Tenant isolation explained.

Each one saves an hour today and costs weeks later. Naming them makes them easy to refuse.

Testing separability without separating

We do not wait for a real separation to find out whether a company could stand alone. Once a year, each company goes through a short drill:

rebuild the product from its own repositories into a clean environment, using only its own configuration;
produce the full resource inventory and compare it with what is actually running;
confirm that no credential used by the company is stored outside its own projects;
check that its source of truth, access list and vendor list match reality.

Anything the drill finds is fixed as ordinary work. A drill that finds nothing is the goal, and it becomes more likely every year the discipline holds.

Summary

Designing companies to stand alone is a set of ordinary, repeated choices: each company owns its domains, code, database, users, AI project, email, analytics, payments and economics; shared code stays brand-neutral, versioned and replaceable; records are kept ready for due diligence; and small shortcuts that blur boundaries are refused before they become habits. We have no plans to separate any company from Oryvelon, but building as if we might keeps customer data where it belongs, makes every company easier to understand and run, and turns any future separation into a hand-over rather than a surgery.

Questions and answers

Can Oryvelon companies be separated from the group?

Yes, that is a design goal. Each company has its own code, data, infrastructure, domains and economics so it could be separated cleanly.

Why design for separation if there are no plans to sell?

Because it keeps options open, protects customers' data boundaries and makes each company healthier and easier to understand today.

What is hardest to separate in a multi-company group?

Shared user databases, shared identity systems and code full of product-specific exceptions. Oryvelon avoids all three.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Company Building

NextWhy every company starts with a source-of-truth document →