One project = one LBO
Why a project holds the whole LBO, how successive add-ons sit inside it rather than beside it, and the one question to ask before creating anything.
Overview
One project = one LBO. Not one company, not one transaction, not one wave.
A project holds the entire structure: the BidCo, every ManCo, and every add-on acquired along the way. It holds the shareholders across all of them, the events in their history, and every process that has been run.
This lesson exists to prevent one specific mistake, because it is cheap to avoid and expensive to correct.
What you'll learn
Why a project is the container for an LBO rather than for a company
The one question to ask before creating anything
What keeping the structure together gives you
Why splitting it fails quietly rather than loudly
Why this is counter-intuitive
Because a project usually carries the platform company's name. Open the project list and you see something like Solarys — which reads as a company, not as a container of companies.
That produces a specific, recurring mistake: reaching for New Project when what is needed is a new company.
The test to apply
Ask: is this part of the same LBO?
Situation | What you need |
|---|---|
A ManCo for the management package | Same project, new company |
An add-on acquired by the platform company | Same project, new company |
A newco inserted into the structure | Same project, new company |
A different LBO, different thesis, different platform | New project — contact Kapitable to set it up (A2.1) |
The dividing line is the LBO — not the legal entity, and not the calendar.
What you gain by keeping it in one project
One shareholder list across the whole structure. A participant who subscribes in three ManCos is one person with three positions. Split across three projects they would be three unrelated records, and reconciling them would be manual.
One hierarchy view. The group structure only makes sense drawn as a whole.
Processes that span companies. A single subscription process can produce transactions in several companies at once, and closing it writes an event to each. That is only possible if the companies live together.
A history that reads correctly. Successive waves appear in sequence against the companies they affected.
What happens if you split it
Nothing breaks loudly, which is the difficulty. You get a structure that works screen by screen and fails as a whole: duplicated shareholders, a hierarchy showing a fragment, processes that cannot reach across the companies they need.
Correcting it later means moving data rather than changing a setting. Much cheaper to get right at the start — which is why this is lesson three and not a footnote.
As the build-up grows
A build-up project gets larger over time: more companies, more shareholders, more events. That is expected and correct.
A project is not a container that fills up. It is the boundary of one LBO, whatever size that LBO reaches.
Related
A1.2 — How Kapitable is organised · the five objects and how they nest
A2.1 — How your project is set up · who creates it, and what to do when you need another
A3.1 — Three ways to create a company · adding companies inside the project
A3.6 — Project hierarchy · the structure drawn as a whole
