Starting alone: using a chief of staff before your company decides anything
Opitor is an AI-native operating system for small companies, where every person gets their own AI chief of staff. The usual way to adopt something like that is to decide as a company: a meeting, a trial, a comparison, a date everybody moves. In a ten-person company that sequence can stall before anyone has tried the product.
The smaller decision is for one person to try the product in their own work, then decide whether it is useful before asking the company to change anything. That path is for people who already have access. Self-serve sign-up is currently closed: /signup sends new visitors to the company BMS login, and the website waitlist is a request for an invitation, not an account-creation form. If you do not have access yet, use the waitlist; the steps below apply once you do.
Why the company-level decision stalls
Watch a small company try to choose a tool and the same thing happens every time. Somebody raises it. Everybody agrees in principle. Then the question becomes what it would mean for everyone, and the answer involves migrating history, retraining habits, and deciding what happens to the three places work currently lives.
None of that is anybody’s job. It is extra work laid on top of shipping, and it lands on whoever cares most, usually the founder, in a week when four other things are more urgent. So it gets deferred to next month, where it meets the same week again.
The deeper problem is that the decision is being made at the wrong size. A company-wide change has to be justified before anybody has used the thing, which means it is argued from screenshots and opinions rather than from a week of real work. That argument is unwinnable, because nobody in the room has the evidence.
What starting alone actually means
For someone with access, it means you set it up for yourself and nothing about anybody else’s day changes.
You can begin with one person’s messages, todos and deadlines before inviting a colleague. That does not establish who else can access those records. Check message, todo, calendar, search and export permissions by role before putting sensitive information into the system.
This is not a trial mode or a reduced version. It is the product, working for one person, which is the unit it was designed around in the first place: one chief of staff per person, not one for the company.
The practical effect is that the cost of being wrong collapses. If after two weeks you decide it is not for you, the thing you wasted is your own attention, not a company-wide migration and the goodwill you spent arguing for it.
Three things to do in the first week
Do these three and skip everything else. The rest can wait until you know whether this works for you.
Put your real commitments in as todos with real due dates. Not a tidy list of aspirations, the actual set of things people are waiting on you for, with the date each one is actually due. The calendar lays them out by due date, so a week where you promised four things on the same Thursday becomes visible immediately, which is usually the first useful thing that happens.
Move one real conversation in. Pick something ongoing with a real other party, not a test thread with yourself. You are trying to find out whether having your messages and your todos in one place changes anything, and that only shows up on live material.
Ask how memory works before relying on it. The current project review has not verified the production creation or approval flow, model access, role-based visibility, or deletion and retention behavior. Ask for those details before treating the feature as personal-only or assuming an approval step controls future use.
That is the whole first week. Three habits, all of them things you were already doing in some form.
When to bring the first colleague in
Not on day three, and not because you are excited. Bring somebody in when you have a specific piece of work that would be easier if the two of you were in the same place, and you can name it.
The right first colleague is the person you already exchange the most with. If most of your day is with one other person, that is who it should be, regardless of seniority or job title. What you are testing next is whether the shared parts hold up, and that only gets tested by traffic that would have happened anyway.
The way to say it matters more than the timing. Do not ask them to evaluate a tool, because that makes it a project and projects need justification. Say what you are doing and what you want from them, in about that many words: I have been running my own work in this for two weeks and it is working, I want to try our thread in it, give it a week and tell me if it is worse. That framing is honest, it is small, and it has an end date. It also makes it easy for them to say no without it becoming a whole conversation.
Then leave them alone with it. Somebody who is watched while they try something new spends the week performing rather than working, and you learn nothing.
What changes when the team arrives, and what does not
What changes is that shared things become shared. Group messages have more than two people in them. The company’s quarterly goals, managed by administrators, become something more than one person’s context.
What does not change is the product’s per-person chief-of-staff model. That description does not prove private access boundaries. The deployed revision is unknown, and production administrator/non-member checks across all private-message read paths remain pending. Memory access and deletion behavior are also unverified.
That last point is worth discussing with the first colleague you invite, because they may assume that the founder can see everything in the founder’s tool. Administrator access across production read paths has not been fully verified; the private-message administrator/non-member comparison is still pending. Avoid promising a complete visibility boundary until those checks are done.
It also means the thing you learned in your first two weeks transfers. You were not building a founder’s private setup that everybody else will have to fit around. You were using the same product they will use, in the same shape, which is why starting alone works as a way in rather than as a detour.
Where Opitor fits
When you have access, Opitor is designed for a one-person start before a team joins. Its materials describe messages, a Todo List, deadlines, administrator-managed quarterly goals and a Memory feature. Production role checks across private-message read paths remain pending; memory creation, model access, role-based visibility and deletion behavior are also unverified. AI replies are drafts you choose to send and are signed in purple. Self-serve sign-up is closed; new users can request an invitation through the website waitlist. The product also runs in a phone browser. See what is an AI chief of staff and the questions and answers for current verification limits.
Updated 2026-09-25