Products
Software built around the operational problems the practice sees repeatedly. Infrastructure first, interface later. Released when the underlying work is durable enough that publishing it stops feeling optional.
Products as operational abstractions.
The products that come out of this practice are infrastructure first. They are not standalone bets on a category. They are the slow externalization of tools the practice has needed enough times across enough engagements that publishing them stopped feeling optional. A product released before the underlying problem has been seen and solved many times tends to be a guess. A product released after it tends to be obvious in the best sense.
What gets built, and what does not.
Most operational problems do not deserve to be products. They are best solved inside the engagement, by the team that owns the system, with documentation that lets the next team do the same. Products are reserved for problems that recur with the same shape, in enough environments, that an external tool will be more durable than a repeated solution.
A working filter:
- The problem appears in multiple unrelated engagements.
- The shape of the right answer is similar each time.
- The cost of building the right answer from scratch is high enough that the wrong answer is being shipped instead.
- The tool, if it existed, would change how the engagement is staffed, not only how it is executed.
Most candidates fail one of those filters. The ones that pass are what we build.
Internal tools, external products.
Internal tools and external products are different categories of artifact. An internal tool can be specific, opinionated, and reliant on the team that built it. An external product cannot. It has to operate without the institutional knowledge that produced it, in environments the original team will never see.
That is the long path between an internal tool that works and a product worth releasing. The tool has to lose its dependencies, gain its documentation, and learn to be operated by people who do not yet exist.
Most internal tools never make that crossing. The ones that do tend to be the ones we never set out to publish.
Infrastructure before interface.
We build the underlying engine before the user surface. A product that ships an interface around a fragile core eventually ships its limits to its users. A product that ships a quiet but well-built core can expose progressively richer surfaces as the work earns them.
This is one reason the products move slowly in their early phases. The visible parts are the last parts, not the first.
What we are building.
Three directions are in active development. Each emerged from a class of problem the practice has encountered enough times to warrant infrastructure. None is broadly available yet. We do not maintain a public roadmap. The descriptions are what we are working on now.
- 01
AI Operations
PlatformIn developmentTooling for the gap between an AI prototype and a system an organization can depend on. Evaluation harnesses, drift and cost monitoring, change records for prompts and models, and the operational hooks an accountable owner needs to pause, audit, or roll back a system in production.
- 02
Operations Software
WorkflowIn developmentOperating software for product and engineering teams, designed around how the work actually happens. Less project tracking, more the durable surfaces and habits that let a senior team carry a system from research to handover without losing the context that made the early decisions defensible.
- 03
Decision Intelligence
ResearchIn developmentA research and intelligence layer for organizations making major technology decisions. Patterns from across engagements organized into reference material a leadership team can bring into a working session.
Restraint is a product decision.
A product released before it is ready is harder to retract than to delay. The cost of a premature launch is paid not by the team that ships it but by the team that adopts it, and by the engagements that take its existence as a given before its existence is real.
We would rather publish nothing for a year than publish a product that creates more support burden than it removes.
When the products are ready, the page that describes them will say what they are, who they are for, what they do, and what they do not do. Until then, the descriptions above are directional.
Selected ventures and platforms.
Some of our work becomes long-term infrastructure, licensed platforms, or companies we continue to shape. These engagements often grow out of the operating partner work described on the venture page.
- Platform
RecipeRM
A recipe relationship management platform built for culinary brands to organize, publish, and distribute recipes across markets, products, and campaigns.
View platform - Company
Yumitos
A social culinary platform connecting food discovery, creators, kitchens, places, and commerce through a new food-centered social experience.
View company
Talk to us about the work first.
Most product directions started as something a client engagement needed and was not able to find. If you are working on a problem in that space, the conversation is more useful than a waitlist.