From services to systems

The question underneath the work

There is a version of services work that is just execution. You take a brief, you build the thing, you deliver it, you move on. The engagement ends and the learning evaporates.

That version keeps studios small, keeps margins thin, and keeps the people doing the work perpetually at the start of a learning curve they never climb. It is not the version we are interested in.

There is another version where services work is research. Where every client engagement is a controlled environment, real constraints, real stakes, real users, and the question underneath the work is not "can we deliver this?" but "what does delivering this teach us?" That version compounds. The knowledge does not leave when the engagement closes. It gets folded back in.

This is the distinction that matters at the start of 2019. TUXX exists in that second version, or it is not worth building.

What service work reveals

Custom software work teaches things that product work alone cannot. When you are building for a single client under a deadline, with a specific team, against a concrete problem they have already tried to solve, you encounter the genuine friction: not the friction that shows up in user research, but the friction that emerges when a real person tries to get something real done and fails.

Patterns start to emerge after enough of these engagements. The same friction appears in different companies, different sectors, different team sizes. A problem you solved in one context resurfaces in a slightly different form somewhere else. The solution you reached through custom work starts to look less like a bespoke answer and more like a repeatable principle.

This is the point where the studio faces a choice. Keep delivering the same answer custom, one engagement at a time. Or extract the pattern, make the solution learnable, build something that can be applied without rebuilding it from scratch each time.

The first path is comfortable. The second is the point.

Structure of the learning

The problem is that most service businesses do not have the infrastructure to capture what they learn. The knowledge lives in the heads of whoever worked the project. When they move on, it goes with them. When the project ends, the client takes the deliverable and the studio is left with nothing but the invoice.

This is not a failure of intelligence. It is a failure of structure.

You have to build the learning infrastructure deliberately. What are we writing down? Where does it live? Who can access it? How does what we learned on this engagement change how we approach the next one? These questions sound like process overhead, and they are, but they are the difference between a studio that is essentially doing the same thing in 2029 as it is in 2019, and one that is measurably more capable by compounding what it discovers.

At TUXX, this is what the services model is supposed to produce. Not just delivered projects. Not just satisfied clients. Structured knowledge about what works, what breaks, and where the repeatable patterns live.

The relationship between services and product

There is a common assumption in the product world that services work is lesser: that the real ambition is to build products, and services are what you do whilst you are waiting to have enough capital or traction to stop taking client work. This framing misses something.

Service work done well is the R&D phase for product work. It is where you stress-test ideas against real environments. It is where you discover the problems that are worth solving at scale because you encounter them in the actual conditions where they occur, under time pressure, with real teams, with the messiness that surveys never fully capture.

Products built entirely in the abstract, optimised for hypothetical users and hypothetical pain points, tend to be fragile in ways that are not immediately obvious. They have clean interfaces for problems that are smaller than the real ones. They solve the describable version of the friction rather than the friction itself.

The studios and product teams that build the most durable things tend to have spent real time in contact with real problems. Not just in the research phase, but in the execution phase, when you are accountable for the outcome and you have to make it work.

Orbit as a case

The operating surface that Orbit is being built to be did not come from a whiteboard exercise. It came from watching commercial execution fail in identifiable ways: the handoffs that lose context, the workflows that people abandon mid-process, the decisions that get made without the information that would have made them better.

A CRM captures data but does not direct the work. A project management tool tracks tasks but is not built around commercial outcomes. The gap between those two things is the space Orbit is being built to fill: a full operating surface for the lead-to-launched-product workflow that reflects how commercial execution actually happens, not how it is supposed to happen in theory.

None of that clarity is achievable from first principles alone. It comes from contact: from enough time watching teams work, watching where they improvise around their tools, watching where the system breaks down and they stop using it.

Services work provided that contact. Product work is now where the patterns get encoded into something repeatable.

The system underneath the service

There is a temptation, when building a services business, to treat every client as unique: their problem is specific, their context is unusual, their constraints are unlike anything you have encountered before. Sometimes this is true. Usually it is not.

Most commercial and operational problems belong to families. The specifics differ. The underlying structure repeats. Once you can see the family, you can build the approach at a level above the individual case. You can create something that is not built from scratch each time but is instead adapted: faster, more reliable, accumulating capability with each application rather than starting from zero.

This is the move from services to systems. The service is the point of contact. The system is what you build from what the contact reveals.

It requires a different kind of discipline than pure service delivery. You have to be willing to do the harder work of abstraction: to look past the specific solution to the general principle, to resist the temptation to deliver something that works just well enough in this case and instead figure out what would work well across many cases.

It is slower in the short run. It compounds in the long run.

What compounds

January 2019 is an early point in building something with the scope this portfolio is intended to reach. Orbit is not finished. TUXX is still refining what it produces and how. The research function housed in Benediction Lab is in early stages.

But the architecture is deliberate. Each part of the portfolio is in relationship with the others. TUXX encounters a problem in a live client environment. That problem is the same family as something Orbit is being built to solve. The research into memory and context that Benediction Lab is pursuing will eventually inform how Orbit reasons about commercial history. None of these are isolated projects running in parallel: they are connected by the same underlying question about how human capability is organised and extended.

The goal is not to build a collection of products. It is to build a system, one that learns from each surface, compounds what it discovers, and becomes more capable in a direction that is coherent rather than accidental.

Service work is not a means to an end. In the right structure, it is part of the system itself.

The discipline required

There is one thing that separates the studios and product teams that compound from those that plateau: the willingness to do the work that does not immediately ship.

Capturing what you learned costs time. Abstracting the pattern rather than re-applying the specific solution costs effort. Building the infrastructure for knowledge to accumulate rather than evaporate at the end of each engagement costs attention that feels, in the moment, like it is coming at the expense of delivery.

It is not. It is what delivery is for.

The useful constraint for 2019 is this: every engagement should produce something other than a deliverable. A written-down insight. A refined principle. A piece of the system that did not exist before. If the only output is the thing the client paid for, the work has been underused.

Build the service. Build the system. They are not separate ambitions: the second one is just the long form of the first.