The early Orbit thesis

Where the question starts

The useful product question in February 2023 is not "what can we build?" It is "where is the friction repeating?"

Repeated friction is a signal. It tells you where teams lose momentum, where standards quietly collapse, and where a better system would change the outcome at scale. It is not glamorous intelligence: it is diagnostic. But it is honest, and honest diagnoses make better products than optimistic ones.

The friction that led to Orbit is not exotic. It sits at the intersection of two very ordinary failures: commercial teams who cannot see what is actually happening across their pipeline, and product teams who inherit requirements shaped more by selling pressure than by real understanding of the customer. Between those two failures is a gap. Orbit is built in that gap.

What Orbit is: stated plainly

Orbit is a B2B SaaS operating system for the full commercial workflow: from first prospect contact through to a launched, delivered product.

That framing is intentional and it matters to get it right. Orbit is not a CRM. It is not a project management tool. It is not a content hub or a task board or a team wiki. These comparisons will come, and they are all partially wrong.

A CRM manages contact records and sales activity. Orbit does some of that, but its centre of gravity is not the contact: it is the commercial workflow as a whole system. The workflow has structure: discovery leads to proposal, proposal leads to engagement, engagement leads to delivery, delivery leads to a launched product or outcome. Each phase has its own operating requirements: different information, different decision types, different handover conditions. Orbit is designed to hold all of it without switching surfaces.

The need it addresses is almost boring in its universality: businesses that are operationally capable lose enormous amounts of value simply because their commercial execution happens across too many disconnected tools. The salesperson who cannot access the brief the delivery lead wrote. The account manager who has to reconstruct six months of context from email threads when a relationship moves to renewal. The principal who cannot see which proposals converted and why, because the information lives in three different places and was never structured for that question. These are not edge cases. They are the default operating conditions for most B2B businesses that have grown beyond a handful of people.

Not Salesforce, not Notion, not Monday

The comparison to existing software is worth making directly, because it shapes how Orbit's design choices are understood.

Salesforce is the comparison people reach for first. It is worth addressing seriously. Salesforce is a platform: sprawling, configurable to within an inch of its life, and almost infinitely extensible via its ecosystem. What it is not is opinionated. Its flexibility is also its primary cost. Deploying Salesforce well requires significant customisation work, ongoing administration, and the kind of institutional knowledge that typically lives inside a dedicated RevOps function. For large enterprises with that infrastructure in place, the tradeoff is reasonable. For the kind of business Orbit is built for, capable, ambitious, operationally serious but not enterprise-scaled, Salesforce is a building site when you need a workshop.

Notion is a genuinely excellent tool for structured documentation and collaborative thinking. It is not opinionated about commercial execution. It will hold whatever you build inside it, which is its strength and its limitation: you still have to build the operating conventions yourself, and those conventions tend to drift as teams grow.

Monday and its peers are task and project trackers with good visualisation layers. They are useful for managing work that is already defined. They are not designed to hold the commercial arc from which that work emerges.

HubSpot has evolved a very large surface area, including strong CRM and marketing automation capabilities. It remains built around the contact record and the inbound marketing funnel. The funnel is a useful model for one part of the commercial workflow. It is not a sufficient model for the whole.

Orbit's design philosophy is the opposite of maximum flexibility. The thesis is that most commercial workflows share more structure than organisations tend to admit, and that the right product holds that structure explicitly rather than leaving each team to build its own conventions inside a blank canvas. Opinionated where structure matters. Open where context must live. That is the design position.

What 'operating system' means here

The phrase "operating system" is carrying some weight, and it is worth being precise about what it means in this context.

We do not mean that Orbit is a platform other applications run on top of, not in the technical sense of the phrase. We mean it in the working sense: the system through which commercial work actually gets done. In the way that the operating system of a computer manages memory, runs processes, and maintains state across everything the user is doing, a business operating system should manage the living memory of commercial activity, run the processes that convert prospects to clients to delivered outcomes, and maintain enough context across that full arc that no one has to reconstruct the history from scratch every time they need to make a decision.

Most businesses do not have this. They have stitched-together partial systems. CRM for contacts. Email for negotiation. Shared drives for documents. Spreadsheets for tracking. Messaging tools for decisions that never get written down anywhere meaningful. The result is that genuine institutional knowledge, the kind that would help a salesperson close better, or a delivery lead onboard faster, or a principal understand why a proposal landed or did not, lives in people's heads and email inboxes. When people leave, it largely disappears.

That is not a technology failure. It is a design failure. The tools being used were not designed to hold the full operating picture. Orbit is.

The phrase also implies something about scope. An operating system is not a feature. It is not a dashboard bolted onto an existing workflow. It is the substrate through which a particular kind of work is conducted. If Orbit is working correctly, it should feel less like software a commercial team uses and more like the system inside which their commercial work simply happens. That is an ambitious target. It is also the right target.

The intelligence layer and why Orion is not optional

Orbit without intelligence is a well-designed workflow tool. With it, it becomes something different.

Orion is the intelligence layer built to power Orbit. It is not a chatbot bolted onto the surface of a product after the fact. It is built into the operating logic: handling memory, context management, reasoning over the information already living in the system, and tool orchestration that helps users do work rather than simply query data.

The distinction matters because most AI applied to business software in early 2023 is surface-level. A model that summarises a document or auto-fills a field is useful. What Orion is being built to do is operate closer to the actual work: understanding where a deal stands across its full history, not just the most recent note; identifying patterns in how commercial conversations develop across similar engagements; maintaining context across sessions so that users do not have to re-explain the situation every time they engage with the system.

This is harder to build than a chat interface. It requires thinking carefully about what information the system should remember and in what form, how it should be structured for retrieval and reasoning rather than just storage, when context should surface without being asked, and what it means for an intelligence layer to be genuinely useful rather than merely present. Benediction Lab, the research function within Mustard Seed Group, is doing the underlying work on memory architecture and agent behaviour that Orion depends on.

The reason this matters commercially is straightforward. The value of a business operating system is not only in its structure, in the clarity of the workflow it holds. It is in the accumulated intelligence the system develops over time about how a particular business operates. A system that has processed twenty proposals, twenty engagements, twenty delivery cycles, knows something about how that business wins and loses, where deals stall, what characterises successful client relationships. Orion is how that knowledge becomes usable, rather than simply stored. The data exists in most organisations already. What is almost universally missing is the layer that makes it actionable.

TUXX as the contact with reality

Orbit does not exist in a closed research environment. It is being developed alongside TUXX, the custom AI systems and software studio that operates as the commercial services arm of Mustard Seed Group.

TUXX operates differently from Orbit. Where Orbit is a product, a system that will be available to external businesses as a repeatable SaaS offering, TUXX is services-driven. It builds custom systems for clients, develops internal tooling, and works in live commercial environments where the constraints are real and the feedback is immediate.

That relationship is deliberate. Services work exposes the reality of how commercial operations actually function under pressure. The patterns that emerge from TUXX engagements inform how Orbit's operating surface is designed, not because TUXX is a testing environment for Orbit features specifically, but because building in live environments teaches things about friction that pure product thinking cannot surface on its own. The distinction between what looks logical in a design document and what survives contact with an actual commercial team is significant. Services work closes that gap continuously.

This is how the portfolio is intended to function: the services work keeps the product work honest. Lessons from live environments are tested before they become design decisions, not after.

The problem with how commercial software has been built

There is a broader observation underneath all of this.

Most commercial software is organised around records and interactions. A contact is a record. A meeting is an interaction. A deal has a stage. A task has an assignee and a due date. These are not wrong categories: they are genuinely useful. But they describe commercial activity at the level of individual events rather than at the level of a workflow that has continuity and direction over time.

The consequence is that the work of holding the full commercial picture together, understanding where a relationship is heading, not just where it has been; knowing what a deal needs to progress, not just logging that a call occurred, falls entirely to the human. The software tracks. The human thinks. The cognitive overhead of maintaining that context, across multiple active relationships, across a team where information is distributed unevenly, is where commercial performance actually degrades. It is not that people are not skilled enough. It is that the system they are operating inside is not designed to share the cognitive load.

Orbit's thesis is that the operating surface and the intelligence layer together can do more of that work, not replacing human judgement, which is irreplaceable and the last thing a tool like this should try to automate away, but reducing the overhead of maintaining context, tracking progress, and surfacing the right information at the right moment. That overhead is where attention goes to die in most commercial teams, and it is an entirely solvable problem if the software is designed with the right intent from the beginning.

What this looks like to build

In February 2023, Orbit is a thesis being turned into a system.

The earliest design decisions are about operating logic: what the fundamental workflow structure looks like, how phases are defined and connected, what information lives at each stage, and how handovers between commercial and delivery functions work without losing the context that was built during the sales process. Getting that structure right is foundational. Intelligence features built on top of a poorly-structured operating surface will not fix the structural problem; they will decorate it.

The design philosophy through this phase: build the structure the system actually needs, not the structure that is easiest to ship. That is a harder constraint than it sounds. The pull towards building what users already recognise, another contact record, another task board, is strong because familiarity reduces adoption friction. Resisting that pull requires being very clear about what Orbit is actually for, and holding that clarity against the constant pressure to add familiar surface area in place of coherent depth.

The thesis in its plainest form: commercial work has a shape. It runs from first contact to launched outcome, through defined phases with defined information needs and decision points. A business operating system should hold that shape explicitly, maintain context across the entire arc, and use intelligence to make the accumulated knowledge of that arc genuinely useful to the people doing the work. That is what Orbit is being built to do.

Working note

Build the product where the pain repeats. Use intelligence where it genuinely improves the operating loop. Keep the system understandable enough for people to trust it.

And do not mistake a well-designed record system for an operating surface. They are different things, and conflating them is how you end up building the eleventh CRM.