Most companies do not choose to run on a dozen tools. They arrive there one reasonable decision at a time. Sales picks a CRM, the product team picks a tracker, legal picks a signing tool, someone starts a wiki, and each choice is sensible on its own. The cost shows up later, in the gaps between them: the deal that closed without anyone telling delivery, the contract nobody can find, the status meeting that exists only because no single screen shows the truth.
Other companies sell one tool for one problem. We build Atlas on a different idea: everything about work should live under one login, one roof, one platform. This guide is the practical version of that idea. It explains what running a company on one platform actually means, which workflows to move first, how to move them, and what should stay outside. We also say plainly where Atlas stops today.
What does it mean to run a company on one platform?
It does not mean every piece of software your company touches is replaced by one product. Your payroll provider, your accounting system, and your source code host will probably stay where they are. Running on one platform means something narrower and more useful: the work that crosses team lines lives in one system.
That system has three properties. First, one identity: each person signs in once and is the same person everywhere, whether they are assigned a task, named on a deal, or invited to sign a contract. Second, one permission model: a role decides what someone can see and do across every module, instead of each tool keeping its own list of who can open what. Third, one set of linked records: a customer, the deal, the contract, the kickoff project, and the tasks that follow are connected to each other directly, so anyone with access can follow the thread.
If you have those three, the rest of the benefits follow. Search can return everything in one query. An assistant can answer from the whole picture. A report can count work that used to live in four places. If you lack them, you have a bundle of apps under one logo, and the gaps are still there.
Why do companies end up with one tool per problem?
Because each team buys for its own pain, and each pain is real. A sales lead needs a pipeline today, not after a company-wide platform decision. Point tools are also easy to try: one team signs up, and the tool spreads by invitation. Nobody owns the space between tools, so nobody is measured on the cost of the gaps.
The result is not a bad decision. It is the absence of a decision about how the company works as a whole. Moving onto one platform is mostly that decision, made on purpose.
Which workflows should move first?
Start with the workflows that cross the most teams, because that is where separate tools cost the most. The table shows the common ones and where each lives in Atlas.
| Workflow | Typical stack today | On one platform (Atlas modules) |
|---|---|---|
| Lead to signed customer | CRM, email, a signing tool, a spreadsheet for handoff | CRM with Gmail sync, Contracts with built-in e-signature, Tasks for follow-ups |
| Signed customer to delivery | A tracker, a wiki, a kickoff meeting to transfer context | Projects and Tasks linked to the deal, Docs for the plan, Meetings for notes and action items |
| Request intake | A form tool, email, manual copy into a tracker | Forms, where each submission becomes a task |
| Weekly status | A status meeting and a slide built by hand | Analytics dashboards built from the work, and a daily standup digest from the Assistant (paid plans) |
| Finding anything | Search in each tool, one at a time | One permission-aware Search across modules |
Pick one row. The best first choice is usually the handoff that fails most visibly, because the improvement is easy to see and easy to explain to the next team.
How do you move a company onto one platform?
- Name the workflow, not the tool. Write the first workflow as a sentence, such as "a signed deal becomes a staffed project within two days." You are moving that sentence, not replacing an app.
- Map who touches it. List every team and every handoff in the workflow. The handoffs are the point: each one should become a link between records instead of a message.
- Run it with one real team. Atlas is free to start with no credit card, so one team can run real work before anyone signs anything. Use real records, not a demo workspace.
- Connect identity before the second team joins. Turn on SAML single sign-on and SCIM provisioning so accounts follow your directory, and map directory groups to roles. Doing this early stops a second, shadow list of users from forming.
- Import, then run in parallel. Bring data across with the CSV and Markdown imports (we have guides for Notion, Asana, and HubSpot). Keep the old tool read-only for one full cycle of work.
- Add the next workflow. Each new workflow reuses the records the last one created. The second move is faster than the first, and the third is faster still.
- Retire the old tool deliberately. Export what you need, cancel, and tell people where the work now lives. A tool nobody cancels keeps collecting work.
What should stay outside the platform?
Systems of record that are regulated or highly specialized: payroll, accounting ledgers, source code, and anything holding protected health information. Atlas is not set up for health data, and there is no BAA, so that data should not go in. Keep specialist tools where a team needs depth that a broader platform does not offer, and connect them where a connector exists. Today the connectors that work are Gmail, Google Calendar, and Google Drive. ZoomInfo, Granola, and Twilio are in beta, and the other 21 listed connectors are in development. The Atlas REST API, webhooks, and MCP server cover the rest if your engineers want to build a link themselves.
A useful rule: if a tool is where the work happens, consider moving it. If a tool is where a regulated record is kept, connect to it instead.
What does Atlas not do yet?
Honest limits matter more than a feature list when you are deciding where a company runs. Atlas has 16 modules, but some are on paid plans only: the free plan covers tasks, projects, calendar, and docs, and the CRM, Ask Atlas, audit logs, and single sign-on come with paid plans. Diagram Studio is in beta. Most listed connectors are not connectable yet. There is no SOC 2 or ISO 27001 report, no uptime SLA, and no choice of data region or on-prem install. If any of those are hard requirements for your company today, Atlas is not the right home for that workflow yet, and we would rather you know that before you start.
Who this approach is not for
Companies whose teams genuinely never share work, such as holding companies with fully independent units, gain little from one platform. Companies with a heavy, deeply customized system already at the center (for example a large CRM build that the business depends on) should connect to it before replacing it. And if your procurement rules require a certification or a hosting option Atlas does not have, start with a team the rules do not cover, or wait.
Can a whole company really run on one platform?
Most of the shared work can, but not every system. The work that crosses teams (customers, projects, tasks, documents, and agreements) fits on one platform, while payroll, accounting, and code hosting usually stay in specialist systems that you connect to.
Which workflow should we move first?
Move the cross-team handoff that fails most visibly, often lead to signed customer or signed customer to delivery. It touches several teams, so the improvement is easy to see.
Is one platform the same as single sign-on?
No. Single sign-on gives one login to many separate apps. One platform gives one login to one system where records, permissions, and search are shared, which is why the gaps between tools close.
How long should we run the old tool in parallel?
Keep it read-only for one full cycle of the workflow you moved, such as one sales cycle or one project, so you can check that nothing was lost before you cancel it.
Does Atlas cover every module on the free plan?
No. The free plan includes tasks, projects, calendar, and docs. The CRM, Ask Atlas, audit logs, and single sign-on are on paid plans, and large organizations can agree custom terms on the Enterprise plan.
What if a tool we rely on has no connector?
Keep it and connect it later, or build the link yourself with the Atlas REST API and webhooks. Today Gmail, Google Calendar, and Google Drive are available, three connectors are in beta, and 21 are in development.
Where this lives in wrxstack: pricing.