Platforms BuiltAround The Work,Not The Software.
The operating layer several teams share: workflows, data, permissions, integrations and the decisions that run between them, engineered as one system. The organisation should not have to change how it works in order to fit the software it bought.
Next Step / Technical Discovery
- Owned boundaries, not shared tables
- The roles the organisation already has
- Contracts, not point-to-point wiring
- Extended in place, not replaced
How operations come apart
Rarely in one decision. Four smaller ones, each defensible at the time, and the cost arrives years later as an inability to change anything safely.
- 01
The operating model lives in four systems and one spreadsheet
Each tool holds part of a process and none holds the whole. Answering an ordinary question means reconciling exports, and that becomes somebody's job.
- 02
Permissions mean something different in every tool
A role that is read-only in one system approves payments in another. Nobody can state, on one page, what a given person is actually able to do.
- 03
The exceptions are the process
The documented path handles the easy cases. The rest runs on email and a few people who know what to do — none of which survives their leaving.
- 04
Every change is a negotiation with the whole estate
Without domains, a change to one process can reach anything. Release becomes an event, and the platform stops absorbing the business.
What Ronexer engineers
Not one large custom application. It is the layer several teams operate on: domains that belong to someone, roles that mean one thing, and a contracted boundary with every other system the company runs.
- 01
Operational platforms
Where the day's work lives: what is outstanding, who holds it, what it is waiting on, and what happened to the last thousand like it.
- 02
Internal business systems
The tools that never reach a customer and cannot be bought off the shelf, because the process they support is the company's own.
- 03
Customer and partner portals
Where people outside the business act on its data, under the same permission model used internally rather than a second one bolted on.
- 04
Workflow and case management
Work that has a state, an owner, a history and an exception path — modelled explicitly instead of implied by which tab someone has open.
- 05
Multi-role administration
Roles, delegation, approval thresholds and the tooling an operations team needs to run the platform without an engineer present.
- 06
Data and integration layers
The domain model underneath, and the contracts through which everything else reaches it — so a change of vendor is an implementation detail.
How a platform is layered
Six layers, all present at once, each depending on the one beneath it. Nothing here is a sequence — that is what separates a platform from a pipeline.
- 01
What each role actually sees
Interfaces built per role rather than one screen with fields hidden from most of the people looking at it.
- 02
Work that has a state and an owner
Explicit state machines with approvals, delegation and exception paths, so the process is something the system knows, not a convention people follow.
- 03
Business rules in one place each
Services drawn around domains that belong to someone. A rule lives where its domain lives, and every surface asks the same service.
- 04
The boundary with everything else
Contracts rather than connections: APIs and events with agreed shapes, failure behaviour and versions, so a vendor change is contained here.
- 05
One model, and a record of what happened
A domain model the whole platform shares, with history kept as a first-class concern rather than reconstructed from logs on request.
- 06
Where it runs and how it fails
Environments, release boundaries, observability, and the failure isolation that decides whether a bad deployment stops one workflow or all of them.
The decisions that age well
Platforms rarely fail on technology. They fail because a boundary was never drawn, so years of reasonable changes accumulate into a system where nothing can be altered without understanding all of it.
Domain boundaries
Each domain has one owner and one place its rules live. Without that, every change is a negotiation with everyone.
Permission model
Access derives from the roles the organisation already has, resolved in one place, so the same question gets the same answer everywhere.
Workflow state
Where work is, who holds it and what may happen next are properties of the system, not of the person who has been doing it longest.
Integration contracts
Every exchange has an agreed shape, a failure behaviour and a version. Replacing a system on either side becomes local work.
Change isolation
Release boundaries follow domain boundaries, so the question before a deployment is what could break, not what might.
Nobody starts from nothing
Enterprise platform work almost never begins on a clean slate. The ERP stays, the CRM stays, identity comes from a directory that predates everyone in the room, and finance moves on nobody's roadmap. The platform is designed to sit among them: reading through contracts, writing back through interfaces they already expose, and reconciling where two systems legitimately hold the same fact.
That makes replacement a sequence rather than an event. Each step below is a place a programme can stop and still be worth what it cost — which is the property that gets a phase two approved.
- 01
Read the estate, change nothing
The platform reports on work that still happens elsewhere. No migration, and the operating model becomes visible.
- 02
Take the flows that keep breaking
The worst-served process moves first, with the systems around it untouched. Value arrives before the architecture is finished.
- 03
Carve out domains behind contracts
Ownership moves domain by domain. Each one is fronted by a contract, so what sits behind it can be replaced later without an audience.
- 04
The platform becomes the record
Remaining systems become integrations rather than sources of truth, and the estate shrinks by retirement rather than by switch-off.
How the work runs
Four phases, and the architecture is decided before anything is built on it.
- 01
Establish the operating model
Roles, processes, exceptions and the systems each touches — recorded as it is, not as the org chart says it should be.
- 02
Draw the domains and the contracts
Boundaries, ownership, integration shapes and the decisions behind them written down, because the reasoning is what future teams need.
- 03
Engineer and integrate the platform
Surfaces, workflow and domain services built against those contracts, with the surrounding estate connected as it is.
- 04
Migrate, run and extend
Cutover by business area, with the tooling and runbooks an operations team needs to change the platform without an engineer present.
What changes
- The business runs on a system that agrees with itself, not four that each hold part of the answer.
- What a person may do is stated once and enforced everywhere, so an access review is a query, not a project.
- Domain boundaries make the blast radius of a change knowable, which is what lets a platform keep taking them.
- Systems around the platform retire one at a time, because each sits behind a contract rather than inside the build.
Related pages
Custom Software Development
The bespoke build: one defined problem, one defined group, and a system scoped to the smallest thing that solves it.
Business Automation
Operational work automated across the systems a business already runs: settled where the rule holds, routed to a person where it does not.
API & Systems Integration
The boundary between systems that change independently, fail differently and sometimes disagree — engineered as a contract rather than a connection.
Bring an operating model that four systems disagree about, a platform that has stopped absorbing change, or a replacement programme that needs a phase one.