Aselectionofrecentengagements,anonymised

The platform had accreted services and patterns over years of good intentions. Teams shipped features, but shared concerns — identity, data ownership, release safety — were inconsistent. Leadership needed a defensible plan for where to invest next, not another slide deck of options.

We interviewed engineers and stakeholders, read the existing systems in depth, and wrote down the real constraints: what must not break, what could flex, and what was reversible. Options were compared with explicit trade-offs and cost-of-delay, then folded into a sequenced roadmap with a small set of architectural boundaries everyone could repeat.

A prioritised roadmap tied to business risk, a short set of written boundaries between domains, and enough shared language that roadmap debates reference the same map. The client engaged us for a follow-on slice to help ship the first roadmap quarter with the same standards.

Close-week reporting joined CRM, finance, and operations fields in a brittle chain of scripts and spreadsheets. A harmless schema tweak in any upstream system surfaced days later as wrong totals, and nobody trusted which version of a customer record was authoritative.

We introduced a canonical model for the few entities that actually cross boundaries, versioned contracts between services, and automated contract tests that run on every change. Structured logs and clear ownership per integration made it obvious where a failure started.

A compact integration service sits between the three worlds; breaking changes are caught in CI or staging, not in finance’s inbox. Operations has a runbook for common failure modes so recovery does not depend on one person’s memory.

Customers submitted everything by email and ad hoc PDFs. Staff had no shared queue, no consistent audit trail, and no straightforward way to prove who saw what and when. The business had outgrown inbox triage but could not afford a heavyweight off-the-shelf suite.

We designed explicit request types, statuses, and retention rules with compliance in mind, then built a typed Next.js portal with server-side auth, structured logging, and exportable activity history. UI was built from a small internal component library so future screens stay consistent and testable.

A single channel for routine customer requests with role-based access, searchable history, and exports the auditors can follow. The internal team owns the library and deployment pipeline, so new flows are a product decision, not a one-off project.

Scheduling, job status, and billing lived across three spreadsheets and two ageing line-of-business tools. Field and office staff had to reconcile the same facts by hand every day, and every peak season added another layer of manual workarounds. Leadership could not see one reliable picture of capacity or backlog across sites.

We ran a short discovery with people who actually run the workflow, mapped the real objects and states (not the org chart), and agreed a thin domain model everyone could name in a sentence. We replaced the worst spreadsheet paths first with a single internal web app, then wired finance and scheduling through well-defined APIs so those systems stayed the system of record where that still made sense.

One operational surface for day-to-day work, with role-based access by site and function, and integrations that fail visibly when upstream data drifts. The team can extend the product without reopening the same integration debates every quarter.