The early logic of Orbit

Where the friction repeats

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

Repeated friction is not a bug report. It is a structural signal. It tells you where teams consistently lose momentum, where standards get quietly abandoned under pressure, and where a better system would change the outcome rather than merely describe it.

That question, asked honestly, applied to commercial teams doing real work, produces a fairly consistent answer. The friction is not in any single tool. It is in the seams between tools. It is in the handoff from commercial context to delivery context. It is in the moment when a promising conversation with a prospect disappears into a CRM field and never resurfaces in the room where the actual work is being planned.

That observation is the founding logic of Orbit.

What a CRM does not do

Commercial software has spent decades perfecting a specific surface: the pipeline. A ranked list of opportunities. Probability estimates. Revenue forecasts. The CRM is extraordinarily good at answering "what might close?" It is almost entirely silent on what happens after something closes.

That silence is not an accident. It reflects an assumption: that commercial and delivery are separate functions, served by separate systems, managed by separate people. The CRM hands off to the project management tool. The project management tool does not know what was sold, to whom, or why. The customer who spent three months in careful conversation with your commercial team arrives in your delivery system as a project title and a deadline.

This is not a workflow inefficiency. It is a structural loss of context. The knowledge built through the commercial process, what the client is actually trying to achieve, what they are afraid of, what they have tried before, where the real constraint lives, does not transfer. It dissolves at the boundary between systems.

Orbit begins from the premise that this loss of context is the problem worth solving. Not by improving the handoff. Not by building a better integration. But by removing the boundary.

One surface, not a stitched set

The architecture principle at the core of Orbit is not complicated, but it is decisive: one system, not many tools stitched together.

This is a claim that cuts against the dominant logic of the software market. The dominant logic is that teams should choose the best tool for each function and connect them. Best CRM for commercial. Best tool for project management. Best tool for documentation. Best tool for communication. Connect them with integrations. Automate the handoffs.

The problem with that logic is that context does not transfer cleanly through integrations. Integrations pass data. They do not pass meaning. The sales note that explains why this client is particularly sensitive to delivery timelines does not make it into the delivery system. The project post-mortem that reveals the assumptions that were wrong at the point of sale does not make it back to the commercial team. Each tool is locally optimal. The system as a whole is porous.

What Orbit is designed to be is a connected operating surface where commercial context flows through to delivery, and delivery learning flows back into commercial. The prospect becomes a client. The client becomes a case. The case generates patterns. The patterns inform the next commercial conversation. That loop has to be a single system to work as a loop.

The journey this covers

Orbit's scope is the full commercial journey: from the first contact with a prospect through to the launched product or completed engagement. That scope is deliberate. It is not about covering every imaginable workflow. It is about covering the complete arc of a commercial relationship without requiring a context switch.

This is meaningfully different from what both CRMs and project management tools claim to do. A CRM covers the front of that journey and stops. A project management tool covers the back of that journey and ignores the front. Orbit's thesis is that the journey is one thing, and software that treats it as two separate things creates problems that software alone cannot fix.

The word "operating system" in the description of Orbit is not decorative. An operating system manages resources, allocates attention, maintains state, and coordinates activity across functions. That is what a business needs when it is executing commercially at any meaningful scale. Not a feature. Not a module. Not an add-on that talks to three other tools. A surface where the whole thing is visible and manageable.

What this asks of the people building it

The scope is honest about the difficulty. Building a product that covers that full journey without becoming an unwieldy monolith is a real architectural challenge. The temptation, when the scope is broad, is to add features until the product is comprehensive and slow. The discipline is to add capability only where it genuinely advances the core loop: prospect to client to pattern.

That discipline requires a clear idea of what Orbit is not. It is not a reporting dashboard. It is not a communication platform. It is not trying to replace every tool a commercial team uses. It is trying to provide the operating surface that holds the context those tools generate and makes that context usable across the full commercial arc.

The question we ask at each capability decision is: does this serve the loop? Does it help a commercial conversation produce better delivery? Does it help a delivery outcome inform a better commercial conversation? If it does not touch the loop, it probably does not belong in Orbit.

TUXX as the proving ground

TUXX, the services and custom systems division, sits alongside Orbit in the portfolio for a reason that goes beyond commercial diversification.

Services work is structurally useful as a proving ground. When TUXX takes on a client engagement, it operates in the same environment that Orbit is designed to serve: real commercial constraints, real delivery pressure, real consequences for losing context at the handoff. The patterns that TUXX encounters in live client environments are precisely the patterns that Orbit needs to be designed around.

This is not a research exercise. It is closer to building the tools you need because the tools available are insufficient. The friction TUXX encounters in practice tests the assumptions built into Orbit's architecture. Where the architecture holds, we have confirmation. Where the friction persists, we have a problem to solve.

That relationship, services revealing patterns, products making those patterns repeatable, is one of the structural principles of how Mustard Seed Group is being built. Research explains what is happening. Services test it under real conditions. Products encode the lessons. None of those functions is optional.

The model question

November 2021 is a particular moment to be building a B2B operating system, because the capability of underlying models has shifted enough that it changes what the product can do, but not yet enough that the surrounding product becomes less important.

The mistake would be to conclude that better models reduce the importance of product. The opposite is closer to true. What models can do well, increasingly, is answer. What they cannot do is direct, remember across a long commercial relationship, measure what matters, recover when things go wrong, or help people finish. That is what a product has to do. The product is the thing that uses the model's capability in a way that serves the loop rather than simply demonstrating the capability.

Orbit's use of intelligence is, at this stage, oriented toward that same principle: make the operating surface more capable of holding context, not more capable of generating output for its own sake. The output that matters is a commercial team that closes better, a delivery team that executes with fuller context, and a loop between them that compounds over time.

Working note

There is a particular kind of clarity that only becomes available once you stop trying to serve every possible use case and commit to a specific thesis. Orbit's thesis is a business operating system for the full lead-to-launched-product journey, built as one connected surface, not as a collection of integrated tools.

That thesis excludes things. It will frustrate people who want it to do something different. That is not a weakness of the thesis. That is evidence that it is actually a thesis.

The useful discipline, in November 2021, at this stage of the build, is to hold the thesis steady whilst figuring out what it requires. Not to defend it against all critique, but to understand it clearly enough that critique is useful rather than disorienting.

Build the surface where commercial context lives. Make delivery continuous with it. Let the loop run. That is what Orbit is for.