Most tools assume one thing:
your project is either open-source or closed.
In reality, many projects sit somewhere in between.
Last year I joined a SaaS project as a consultant.
When I arrived, everything was closed — including internal tooling and documentation.
Six months later:
- documentation is open-source
- one integration is open-source (MIT)
But the system is still partially closed.
And that creates a specific kind of friction.
During routine reviews, I would hear things like:
- “This invite link is outdated, we have a verified integration now”
- “Don’t document this feature, it will be removed soon”
The insight exists — but only in the founder’s head.
This doesn’t scale.
If you want to grow a team, knowledge cannot depend on one person’s memory.
The problem
Open-source parts live on GitHub.
Closed-source parts live somewhere else.
Decisions live in conversations.
There is no single place where the system is visible as a whole.
The solution: a meta repository
Instead of trying to force everything into one system, I introduced a simple layer:
a meta repository
An empty Git repository with a README that explains its purpose.
That’s it.
Now you can:
- create issues for the product as a whole
- track decisions across open and closed parts
- discuss changes in one visible place
As if the entire system was open — even when it’s not.
Taking it further
If you want structure:
- create a GitHub Project (Kanban is enough)
- define a small set of labels (area, priority, status)
This turns the meta repository into a coordination layer.
Why this works
You don’t fight the system.
You don’t force the founder to change tools.
You simply create a visible layer above everything.
Setting this up takes 30–60 minutes.
It pays off immediately.
