Build the operating middle.
Keep authoritative systems and exceptional specialist tools; build the business-specific layer between them so cross-system work stops living in spreadsheets, weak add-ons, and disconnected custom projects.
The tool gets wider. The stack does not get simpler.
Software often wins by doing one job unusually well. Then the product expands sideways: first into nearby tasks, then into adjacent departments, and finally into a broad suite. More modules, user types, data objects, and metered AI arrive even when the buyer's original need has not changed.
Imagine an email tool bought to send campaigns reliably. It adds templates and analytics, then audience records and automation, then forms, landing pages, websites, text messaging, advertising, commerce, and generated content. Each addition is plausible on its own. Together they redraw the feature map without necessarily replacing the deeper systems already responsible for customers, sales, transactions, data, or specialist execution.
That is the central distinction: surface area is cumulative; authority is not. A wider product can cover more moments in the workflow while the core record, specialist tools, and business-specific handoffs remain. The stack has not become simpler. It has gained another overlapping layer.
One clear reason to buy
The product is narrow enough that the buyer can name its job in one sentence.
The starting feature map- Audience lists
- Campaign builder
- Reliable delivery
- Basic reporting
Depth in one bounded task earns the product its place.
Three kinds of software deserve three different decisions.
The right response is not to build everything. It is to draw harder boundaries around what deserves to stay and to own the layer where the organization is actually different.
Core systems often persist for decades because they carry authority and regulation. Specialists earn their place through scarce depth. The middle is different: it changes with the operating model, crosses vendor boundaries, and contains the objects, logic, and handoffs that are particular to the business.
A few exceptional specialists
Highly vertical or technically advanced products that are genuinely best at one bounded job.
The operating middle
The business-specific model, cross-system work, commodity functions, and internal applications that need to fit the organization rather than a vendor category.
One authoritative core
The ERP, core banking platform, hospital system, or other regulated industry record.
The middle is defined by fit, not size.
The range is the point. The middle spans the small handoff nobody has productized and the complex internal system no vendor can model without turning your organization into its average customer — the same six kinds of work at either end of it.
The common condition is not size, cadence, or technology. It is fit. The work belongs in the middle when it must reflect your definitions, combine your systems, preserve your logic, or stay under your control.
- WorkflowsTwo-step handoff
A small path that should stop living in an email thread.
- AnalysesRepeatable analysis
A recurring question answered from stable definitions.
- ModelsScoring model
The logic that classifies, matches, ranks, or values.
- AgentsIn-app agent
Work asked for in your own words, carried out inside your permissions.
- Data productsGoverned data product
Durable facts authorized teams can query under shared definitions.
- ApplicationsInternal application
A role-specific place to run work no product models.
Poor fit creates a second system before it creates a replacement.
A vendor platform can remain the official system while the real operating model grows around it. The first extra field lands in a spreadsheet. The first unsupported action becomes an email. The first cross-system answer becomes a local macro or a replicated table.
Drift is the predictable result. The purchased system holds one version of the customer, case, property, member, or deal; the team's shadow system holds the fields and decisions required to do the work. Neither is complete, and every handoff must reconcile the two.
Build where you need to. Migrate when it makes sense.
Rip-and-replace begins with disruption and asks the replacement to justify it later. A better sequence begins with coexistence. Keep authority where it already works, connect the context the business needs, and build the missing operating surface over it.
Consolidation becomes the consequence of a successful build, not a target imposed in advance. A weak subscription disappears when the new layer fully performs its job. A spreadsheet retires when the model, workflow, and history have somewhere better to live. The systems still earning their footprint remain.
Protect
Keep the authoritative core and the specialists whose depth still earns a place.
Build
Add the shared model and operating surfaces the current estate cannot express.
Consolidate
Remove weak subscriptions and local workarounds only after the replacement has earned it.
The second build should begin with more than the first one had.
A conventional one-off project can deliver its answer and leave its scaffolding behind. An operating layer should do the opposite. The model established for the first application, the connections opened for the first analysis, and the permission rules defined for the first workflow should remain available to the next piece of work.
That is how the middle becomes an asset rather than a new collection of custom systems. Habitat is designed around that continuity: models, analyses, data products, workflows, applications, and agents accumulate on one foundation. Each can be small or large; none needs to recreate the business underneath it.
- Trust
Known source. Declared access.
Provenance, permissions and operating boundaries stay with the work.
Data and ProvenanceIdentity and AccessDeployment and Operations
- Intelligence
One business context.
Records, documents and connected systems become shared context for judgement.
AI and AnalyticsDocuments and ArtifactsIntegrations and APIs
- Delivery
Many ways to act.
People, automation and interfaces use that context to move the work.
Workflow and AutomationCommunication and CollaborationSurfaces and Applications
The same foundation runs as a tenant on our cloud, as a dedicated cell on our cloud, or inside your own cloud. What differs is where the tenant, cell and control plane sit, not what you build on them.
The destination is not fewer systems at any cost. It is fewer weak systems, clearer boundaries, and one place to build what is actually yours.
See the operating model in practice.
All insightsBring us the part of the stack no product quite fits.
We will map what should stay, what should connect, and what is worth building around the work itself.