Custom business applications
Purpose-built software where the constraint is your operating model—roles, approvals, regulatory evidence, and integrations—not the UI framework. Work centres on a governed domain model and explicit ownership of state transitions.
Context
- Operations run on exception paths that productised workflows treat as rare; configuration alone cannot express the rules.
- Teams need a single source of truth for a process, not another spreadsheet bridge between three SaaS modules.
- Compliance and audit require immutable decision history, not exports assembled the week before a review.
Problems addressed
- Permissions copied from generic templates that do not match how shifts, sites, or legal entities actually split responsibility.
- Integrations implemented as hidden shared databases or brittle point-to-point scripts.
- Reporting built on extracts that diverge from the transactional system within days.
- Field or branch capture that loses data when connectivity drops because sync semantics were never designed.
What this work involves
- Domain modelling workshops: actors, entities, states, and invariants before screen design.
- API-first or service boundaries between modules with versioning and monitoring for integration contracts.
- Authorisation models aligned to real job functions and segregation-of-duties requirements.
- Vertical release slices into production with rollback and data-quality checks—not big-bang cutovers unless unavoidable.
- Operational runbooks: who owns schema changes, deployments, and third-line support after handover.
Relationship to services
Capability pages describe what kind of technical work sits behind advisory, security, and delivery engagements. Commercial framing, pricing, and engagement shape live under Services.