Platform and integration · Coming Soon
SimpleOS

SimpleOS
The planned shell where the products a customer already has are used together.

For Operations and IT leaders who expect to run more than one Simple Intelligence product and want to know how those products will be reached, entitled, and administered together.

A customer running four Simple Intelligence products signs into four applications, and the seams between them become their problem to manage. SimpleOS is the planned answer: one place a person signs in with their existing Microsoft work account and sees the products their organization is entitled to. A shell of it is built and deployed internally. It is not open to customers, it does not bill anything, and it is not the same thing as Simple Ops, which is the planned suite of operational products rather than the surface they would be reached through.

Replaces A separate sign-in for every tool A hand-maintained internal portal page A folder of bookmarks nobody keeps current
Web Planned Copilot Planned

When you can get SimpleOS

Coming soon

Not open yet. Tell us where to send word when it is.

What you can do now

Get product updates

None of these creates an account, a trial, or access. Each one records what you asked for so a person can answer it.

Where this stands

Availability
Coming soon

What it costs

No published price yet. Pricing is set before this product opens.

Routes that are not open

  • Direct trial with Simple Intelligence Not open yet
  • Direct subscription from Simple Intelligence Not open yet
  • Microsoft Marketplace Not published yet
  • Sponsored subscription for member companies Not open yet

What a shell is, and what it is not.

SimpleOS is a way in, not a place your work lives. It is planned as one signed-in surface that knows which products your organization has and takes you to them. The products keep their own applications, their own data, and their own approval seams. Nothing is absorbed, and using the shell is not a precondition for using anything it lists.

Why it opens products rather than containing them.

The built shell links out to each product rather than embedding or proxying it, and that is a deliberate constraint rather than a stage on the way to something else. A shell that proxies becomes a second copy of every product's permissions, and the copy is what goes wrong. Sending you to the product means the product decides what you may do, using the same rules it applies to anyone arriving directly.

How far this has actually gone.

Sign-in works, the module list is real, and the entitlement read behaves the way it should when the service behind it is down: it locks. What does not exist is any of the commercial machinery. There is no sign-up, nothing is billed, no tenant is provisioned, and the deployment is internal. It is a working shell nobody outside can reach, which is why this page says Coming Soon rather than preview.

What the shell does today, and what it does not.

There is more built here than a plan and less than a product. Both halves are stated below rather than one of them.

Working today

  • A person signs in with their existing Microsoft work account
  • A module registry lists sixteen entries grouped into tiers, each carrying its own stage rather than a single suite-wide status
  • A tile opens the product's own application. The shell does not embed or proxy a product
  • Entitlement is read per tile and fails closed: when the entitlement service cannot be reached, every tile locks
  • It is deployed and in use internally for review

Not yet

  • It is not open to customers. There is no sign-up, no billing, and no tenant provisioning
  • Even internally the root address does not serve the shell, so it is reached by a specific path
  • Tiles for three of the products that are already available have not been added to the dashboard
  • There is no single tenant and no single bill across products. Each product is still bought, signed into, and billed on its own
  • There is no approved date, and none will appear here until there is one

Verified against the product on 2026-08-24.

SimpleOS is not another name for Simple Ops.

The names are a character apart and the things are not related in the way that suggests. Both are planned, and they are planned as different things.

Nothing on this list is available today. This is the product we intend to build, written down so you can tell us whether it is the right one, and it will change.

SimpleOS is the surface

A shell you sign into that shows the products your organization has and opens them. It is about how products are reached, not about which products exist.

Simple Ops is the grouping

A decision about which operational products belong together under one name. It has its own page, and nothing has been built under it.

Neither is on sale

The shell is deployed internally and closed. The suite does not exist as software. There is nothing to buy on either page.

The products are the real part

Everything a customer can actually use today is one of the individual products, each on its own terms and its own page.

If a future version of this page describes SimpleOS as a suite you can buy, it has drifted from what was decided.

Composing products is not merging them.

The word composition does a lot of work in software marketing, so here is exactly what it is planned to mean and what it is planned not to mean.

Your data stays in the product

The shell holds no product records. Time entries, projects, deals, and tickets stay in the product that owns them, under that product's stated storage posture.

Approvals stay in the product

Arriving through the shell does not change what an agent may do or who has to approve it. The seam is the product's, and it is the same seam whether you arrived through a tile or directly.

Entitlement decides what you see

A tile you are not entitled to is locked rather than hidden, so the shell tells you a product exists and that you do not have it, which is a more useful answer than an empty screen.

Failure locks rather than opens

When the entitlement service cannot be reached, every tile locks. The failure is visible and it is on the safe side of the decision, which is the behaviour the built shell already has.

Where each of these claims comes from.

A person signs in with the Microsoft work account they already have.
In the build Sign-in is built against Microsoft work-account identity rather than a separate username and password, and it is the only way into the shell. There is no local account to create. Checked 2026-08-24
The shell opens a product rather than embedding or proxying it.
In the build Every module in the registry carries the address of the product's own application, and the shell navigates to it. The repository states in its own words that it is not a monorepo and not a reverse proxy. Checked 2026-08-24
Entitlement is read per tile and fails closed.
In the build The entitlement read is made per module, and the failure path locks rather than grants: when the entitlement service cannot be reached, the dashboard renders every tile locked. Checked 2026-08-24
It is not open to customers.
In the build There is no sign-up path, no billing, and no tenant provisioning anywhere in the shell. The deployment is internal, its own ship record notes the root address does not serve it, and tiles for three already-available products have not been added. Checked 2026-08-24
Storage posture
None of its own. Each product reached through it keeps its own storage posture.
Certification target
Microsoft 365 certification, not held today
Distribution
Azure Marketplace (planned) · AppSource (planned)
Status
Coming Soon

The questions this page exists to answer.

Can I use SimpleOS today?

No. The shell is deployed internally and is not open to customers. There is no sign-up, nothing is billed through it, and no customer tenant is provisioned by it.

Is SimpleOS another name for Simple Ops?

No. SimpleOS is the shell products would be reached through. Simple Ops is the planned grouping of the operational products themselves. Both are planned, they are separate, and neither is purchasable.

Does it give me one tenant and one bill across products?

Not today, and no work on that has started. Each product is bought, signed into, and billed on its own. If that changes it will be stated here as something built rather than as something intended.

What happens when I open a product from the shell?

You go to that product's own application. The shell does not embed it in a frame or proxy it, so the product applies its own permissions and its own approval rules to you exactly as it would if you had gone there directly.

What happens to my data?

The shell stores no product records. It knows who you are, which products your organization is entitled to, and where each product lives. Everything else stays in the product that owns it.

What does it do if the entitlement service is down?

Every tile locks. It fails closed rather than open, so an outage cannot hand somebody a product their organization does not have. That behaviour is built, not planned.

There is nothing to sign into yet.

SimpleOS is not open to customers. If you are running more than one Simple Intelligence product and want to know how they will fit together, that is a conversation we can have now, and it will be about the products you actually have.

Availability Get product updates