Who It's For

FoundersOS is built for one kind of person: a solo founder, or a small team of people who already trust each other with the keys to the business. If that is you, the design fits you exactly. This page explains why, so you know what you are running before you put real data in it.

One set of keys

FoundersOS runs on your own database. To connect to it, you hold a set of secret keys. Anyone who has those keys can read and write everything in the system - your customers, your tasks, your notes, your finances. There is no separate login wall, no truly locked-down “view only” account that holds up against someone with the keys.

That is not an oversight. It is the right shape for who this is for. As a solo founder you are already the admin, the finance person, the salesperson, and the only “user” the data belongs to. Wrapping that in a full permission system would be machinery you would spend time managing and never actually need. So we kept the tool simple and built the trust model around the keys.

If you have a co-founder or one or two people you would trust with the company bank login anyway, the same logic holds. They get the keys, they get the whole picture, and that is usually what a tiny team wants: everyone sees everything, nobody is blocked waiting on access.

Light guardrails, not a permission wall

There are a few small checks inside the tools, and it is worth being clear about what they are for. A team member can be marked as an owner or not, financial tools can be set to none, read, or write per person, and a memory can be saved as “personal” so it stays out of shared team recall.

Read those as guardrails against honest mistakes, not as a security boundary. They exist so the AI does not casually rewrite your finances on a stray instruction, or surface a private note in front of the whole team. They do not stop a person who holds the keys - that person can always reach the data directly underneath the tools. The guardrails keep a trusted team from fumbling; they are not there to contain someone you do not trust.

The one rule

Because the keys are the real security model, the whole job comes down to a single habit: keep your keys secret. Treat them like the password to your bank, because in effect that is what they are. Do not paste them into a public chat, do not commit them to a public repo, do not hand them to someone you would not hand your company finances.

Do that, and your data is not floating around the internet for anyone to grab. It sits in your private database, reachable only by someone holding your keys. The boundary is real. It is a trust boundary - “do I trust this person with everything” - rather than a roles boundary - “what is this person allowed to see.” For a small trusted team, a trust boundary is the honest one anyway.

Where the line is

There is a clear point where this model stops being the right fit: the moment you want to let someone in but genuinely scope them down. A contractor who should see tasks but truly cannot see the bank balance. A teammate you are still getting to know. A client you want to give a narrow window into their own project and nothing else. The guardrails above were not built to enforce that, and the keys cannot express it, so you should not lean on either one to try.

If you reach that point, you have outgrown what this tool is shaped for, and that is a fine problem to have. Until then, everyone-you-trust-holds-the-keys is not a limitation to work around. It is the design.

The short version

If you are a founder or a small trusted team, FoundersOS is built for you as is. Keep your keys secret and you are in good shape. The light role and memory checks help a trusted team avoid mistakes; they are not a wall against someone with the keys, so do not treat them as one. The day you truly need to put someone on a leash rather than hand them the keyring, you have outgrown the tool, not hit a bug.

Next: Try the Demos.