When it does not fit one category.
Cross-disciplinary work where the objective needs software, data, automation and analysis composed into one system.
Useful when every supplier you speak to wants to sell you only the part they do.
Illustrative system example · fictional product and data · not client work
Technical control surfaceCONDUIT · illustrative system, fictional data
You may need this when
Some of this probably sounds familiar.
- The thing you need does not exist as a product you can buy.
- Three suppliers each quoted for a third of the problem.
- The work spans software, data and analysis and nobody owns the join.
- An off-the-shelf tool gets you most of the way and then stops.
- You need someone to work out what it takes before quoting for it.
What we could build
The disciplines the objective actually needs.
Chosen after understanding the problem, rather than fixed before it.
- Cross-discipline systemSoftware, data and automation delivered as one build.
- Bespoke technical toolingThe internal tool that does not exist off the shelf.
- Research-backed buildEvidence gathered first, then built on what it showed.
- Modelling inside a productSimulation or forecasting embedded in a working system.
- Technical due diligenceAn independent read on whether something can be built as claimed.
- Prototype to productionA proof of concept taken to something dependable.
See an example
The architecture follows the objective.
Pick an objective. The components change with it — which is the point: the shape of the system is decided by the problem, not by a fixed package.
Every option is shown below. The selector needs JavaScript, so it is not offered here.
OutcomeA self-service objective needs a product, a join to existing systems, and somewhere staff handle exceptions.
OutcomeA planning objective leads with data and modelling, and only then a surface to act on it.
OutcomeAn assistance objective is mostly about boundaries: retrieval, evidence and where a person still decides.
Illustrative interfaces and fictional data. Not client work.
Composing the system around the objective is why cross-disciplinary work does not divide cleanly into service categories.
What you receive
One system, and one accountable route.
- A working system covering the disciplines the objective needed
- One point of technical accountability rather than three suppliers
- The reasoning behind the architecture written down
- An honest assessment where an existing product would serve you better
- Agreed source code, data and infrastructure handed over according to the project scope and terms
- Handover documentation and any agreed support arrangements
Technical depth
Composition
Components chosen for the objective and integrated deliberately, with the boundaries between them defined rather than emergent.
Sequencing
Work ordered so the riskiest unknown is tested first, before the expensive parts depend on it.
Interfaces
Contracts between components defined up front, so one part can be replaced without rebuilding the rest.
Proportionality
Complexity added only where the objective needs it — a scheduled job instead of a queue where that is genuinely enough.
Verification
Each discipline verified on its own terms, and then the joins between them tested explicitly.
Handover
Documented so a team that did not build it can operate and extend it.
Often combined with
What usually sits next to this.
- Software & systems →When the core of it is an application people work in.
- Data & analytics →When the objective depends on records being reliable first.
- Simulation & modelling →When part of the answer is testing a decision before acting.
Tell us the objective, not the components.
Describe what needs to be true when the work is done. We will work out what it takes.