Most teams do not have a software shortage. They have a coherence shortage.

Important work is scattered across documents, inboxes, spreadsheets, ticket queues, specialist applications, and the heads of experienced people. Every tool may be reasonable on its own. The system they form usually is not.

People compensate by becoming the integration layer. They copy context from one place to another, chase approvals, rebuild the same evidence, and remember the unwritten rules that keep a process moving. The real cost is not one bad interface. It is the accumulated drag between all of them.

The work behind work is still manual

Look closely at almost any organisation and you find the same category of work: reviewing access, cleaning a document before it leaves the company, collecting audit evidence, qualifying an intake, mapping a relationship, comparing clauses, resolving an incident, or turning an agreed decision into action.

These workflows are essential, but they are rarely the organisation’s main product. That makes them easy to neglect and expensive to replace. Teams end up choosing between broad platforms that require months of configuration and narrow tools that create another island of data.

The opportunity is not to put a chatbot on every screen. It is to make the whole system more capable.

AI changed the economics of software

For most of software history, serving a narrow workflow was difficult to justify. Discovery, design, engineering, integration, maintenance, and support imposed a cost floor. A product needed a large market before it could become a good business.

That floor is moving. AI makes it possible to understand messy inputs, draft structured outputs, adapt interfaces, connect systems, and help small teams build at a speed that was recently implausible. It does not remove the need for product judgment, security, or operational discipline. It makes those qualities more valuable because much more software can now exist.

We believe this creates room for focused products that fit the work precisely—and for a shared foundation that lets those products behave like one system.

Build for the specific workflow.
Connect for the whole organisation.

Why System32 is a system, not a suite

A suite is often a collection assembled over time. A system begins with shared assumptions. System32 products are designed around a common layer for identity, permissions, data, automation, audit history, and AI agents.

That shared layer matters more than a matching logo. It means a vendor approved in one workflow can be recognised in another. A document can keep its permissions when an agent works with it. An approval can become durable evidence. An incident can reveal the identities, devices, code, and infrastructure connected to it.

Each product should be useful alone. Together, they should remove the seams that force people to carry context manually.

The principles we are building by

01

Start narrow

A product begins with one painful workflow, one clear user, and one outcome we can observe.

02

Share the foundation

Identity, permissions, data, agents, and evidence should become stronger with every product we add.

03

Keep people in control

Agents can prepare, recommend, and act within policy. Consequential decisions need visible ownership and a way back.

04

Make security structural

Least privilege, clear data boundaries, auditability, and safe defaults belong in the architecture, not the final checklist.

05

Earn every product

We publish the bet, test the workflow, and let evidence decide whether to deepen, combine, open, or stop.

What comes next

System32 is an applied AI lab, which means the work has to leave the lab. We will build in public where we can, put working products in front of real users, and be explicit about what is available, what is early, and what is still only a direction.

The catalog will change. Some ideas will become durable companies or open-source projects. Some will merge into a stronger product. Some will teach us enough to stop. The shared system should compound through all of it.

We are building System32 because the next generation of software should be more specific without becoming more fragmented, more autonomous without becoming less accountable, and faster without becoming reckless.

Build with us

If one of these workflows feels familiar, tell us where it breaks. The best product conversations start with a real piece of work.

Next build logBuilding 100 products in 100 days