How to organize projects, companies, and teams within ArduMaker

Published on 2026-09-12 by frfrand

La estructura de la plataforma explicada de una vez: qué es una Empresa, qué es un Proyecto, cómo se reparten los permisos y por qué esa separación resuelve problemas que después son carísimos.

Every platform imposes a way of organizing things. It is worth explaining ours, because structural decisions are the ones that are hardest to change later.

The Company is the unit

At ArduMaker, the central piece is the Company. It is not an administrative detail: it is the real boundary of the system.

Hanging from a Company are its VPS, its domains, its email accounts, its team, and its billing. And what matters is what does not cross that boundary: someone who belongs to a Company does not see the others.

The recommendation is direct: one Company per client.

At first it seems exaggerated if you have five small clients. The advantage appears later, and it appears all at once:

• The day a client leaves, they take their entire Company with them. There is no need to check which file belonged to whom.
• When someone asks how much is spent, there is a direct answer.
• When a freelancer joins for a project, they are added to that Company and do not see the rest.
• If something breaks for one client, it does not affect the others.

That last point is the most underestimated, and it is structural: it is not that permissions are well configured, it is that there is no place where things touch.

Roles, and why there are two

Inside a Company there are two levels:

Member. Works: administers VPS, deploys, configures domains, checks logs.

Admin. All of the above plus the administrative part: payment methods, billing, adding and removing people.

That it be two and not ten is deliberate. A permission system with twenty levels ends up misconfigured, because no one remembers what each one implies. Two levels are understood and used well.

The practical consequence: the developer who deploys does not need to see —nor does he see— the customer's card. And the customer can be Admin of their own Company without that giving them access to your other customers.

The Projects, which are another thing

Projects are the work management side: stages, tasks, checklists, calendar, attachments, meetings.

It is deliberate that they are separated from infrastructure. A project can exist before there is a server, can cover several servers, or may not touch infrastructure at all.

The useful thing about having them in the same place is that the conversation about the work and the things being worked on coexist, without jumping between tools.

SSH keys, per person

Each user of a VPS has their own key, loaded from the panel.

We already said it in another article and it is worth repeating, because it is the decision that avoids the most problems: adding someone is adding their public key; removing them is removing it. There is no shared credential to rotate nor a change to coordinate with the whole team.

And every command executed from the platform remains associated with whoever launched it, so "what changed here?" has an answer.

How to start well

Three recommendations that come from seeing how it is used:

Create the Company before the server. Moving resources afterward is possible and it's work.

Use names that survive. The client's name, not the current project's name. Projects change; the client doesn't.

Add people with their own account from day one, even if it's faster to share yours "for now." That "for now" is exactly the one that lasts two years.