Sector 01
SaaS & Technology
Product companies past first traction, where the platform work now competes with the roadmap.
INDUSTRIES
Different sectors, mostly the same underlying problems: systems that grew faster than they were designed for.
SECTOR DIRECTORY
Jump directly to the sector-specific constraints, common bottlenecks, and architectural approaches below.
Sector 01
Product companies past first traction, where the platform work now competes with the roadmap.
Sector 02
Production environments where the system of record and the actual process stopped matching.
Sector 03
Student, learning, and administrative systems where records must stay accurate across a whole academic cycle.
Sector 04
Systems where a number has to be reproducible and every change has to be explainable.
Sector 05
Property, tenancy, and transaction processes still coordinated across inboxes and portals.
Sector 06
Movement and fulfilment operations where visibility gaps become customer service work.
Sector 07
Firms whose margin depends on utilisation, billing accuracy, and how long a document takes to find.
Software companies reach a point where the things that made the first version fast are the things slowing the next one down. Tenancy decided in a hurry, billing bolted on beside it, and a codebase where each new customer requirement threads through code that was not expecting it. The work is rarely a rewrite. It is separating the commercial platform from the product, so that onboarding, permissions, and plan changes stop consuming the engineering time that should be going into whatever the product is actually for. Done early, that separation is a few weeks of work; done after fifty accounts were onboarded by hand, it is a migration.
Onboarding a new customer requires engineering time rather than a form.
The tenancy decision made for the first customer now constrains every schema change.
Enterprise prospects ask for single sign-on and audit logs, and the answer is a project.
Billing exceptions are handled by hand, and the finance team keeps a separate spreadsheet.
Feature work and platform work compete for the same engineers, and platform work loses.
Separate the commercial platform — tenancy, identity, billing, roles — from the product itself.
Make onboarding self-service, so customer number fifty costs what customer number two did.
Build the audit and access controls that enterprise security reviews ask for, before the deal needs them.
Take platform work as a parallel track, so the internal team keeps shipping product.
Set performance budgets on the front end that hold as the application grows.
Manufacturing operations usually have a resource planning system that holds the official version of events, and a set of spreadsheets, whiteboards, and personal knowledge that holds the real one. The gap between them is where scheduling decisions, stock accuracy, and quality records actually live. Replacing the planning system is rarely the answer and rarely affordable. Building the operational layer that sits alongside it — capturing what is genuinely happening on the floor and reconciling it back — usually is. That layer has to work on a factory floor, which means it has to be fast on a shared device, usable with gloves on, and tolerant of a network that comes and goes.
The planning system says one thing about stock and the floor says another.
Production scheduling runs on a workbook that one person maintains.
Quality and compliance records are captured on paper and typed in later, or not.
Machine and line data exists but never reaches anyone who could act on it.
Reporting for a customer audit takes days of manual assembly.
Build the operational layer beside the planning system rather than replacing it.
Replace scheduling and tracking spreadsheets with applications that keep history and allow concurrent use.
Capture quality and compliance records at the point they happen, on devices that work on a factory floor.
Turn machine and process data into reporting people can act on within a shift.
Connect the operational layer back to the system of record, so the two stop diverging.
Education software has to hold a record that stays correct for years and is read by people with very different rights over it — students, staff, parents, and administrators. Most institutions run a student information system, a learning platform, a finance system, and several departmental spreadsheets, and the joins between them are maintained by hand. The constraints that matter are structural: who may see a record, how enrolment and progression change it over time, what has to be reportable at the end of a term, and how the safeguarding and data-protection rules apply to minors. We build those into the data model and the access layer rather than leaving them to process, and we are direct about the boundary — we engineer systems, and academic and safeguarding policy decisions belong with the people accountable for them.
Student records live in several systems with no reliable link between them.
Access control is coarse, so staff see more of a student record than their role requires.
Enrolment, admissions, and progression run through email, forms, and shared spreadsheets.
Statutory and internal reporting requires manual extraction at the end of every term.
Integrating with the student information system or learning platform is quoted as a project nobody wants to start.
Design the access model and audit trail into the data layer, where they cannot be bypassed.
Build admissions, enrolment, and progression workflows that keep a complete record of every decision.
Integrate with existing student information and learning systems through defined boundaries rather than direct database access.
Automate term and statutory reporting so the figures come from the system rather than a spreadsheet.
Set retention, minimisation, and residency rules explicitly, in code as well as in policy.
Financial systems are judged on whether a figure can be reproduced and a change can be explained. That makes append-only records, deterministic calculation, and complete lineage architectural requirements rather than nice properties. Much of the sector still runs core logic in long-lived .NET applications and stored procedures, which is workable — the problem is usually that the behaviour is undocumented and the reconciliation is manual. We do the modernization work that makes those systems changeable again, and we are clear about the boundary: regulatory interpretation stays with your compliance function, and we build to the position they set rather than forming our own.
Reconciliation between systems is a manual monthly exercise that somebody dreads.
Calculation logic lives in stored procedures with no test describing what it should do.
Producing an audit trail for a specific decision means asking several people.
A core .NET application cannot be changed without a change window and an evening.
Client reporting is assembled by hand from several sources each period.
Extract calculation logic into tested code, verified against the existing system's own outputs.
Build append-only records so a figure can be traced to the inputs and code version that produced it.
Automate reconciliation, with exceptions surfaced for review rather than found by inspection.
Migrate long-lived .NET applications in reversible slices, without a cutover weekend.
Build client-facing reporting and document access that removes the manual assembly step.
Property businesses coordinate long processes across many parties, and most of that coordination happens in email. A transaction or tenancy involves agents, tenants, owners, contractors, and finance, each holding part of the state, none holding all of it. The software that exists tends to cover one segment well and leave the joins to people. The work is usually connecting what is already there and giving each party a place to see their own position, rather than replacing a management platform that mostly does its job. Replacing that platform is the expensive answer to a problem that is nearly always about the joins between systems rather than the systems themselves.
The status of a transaction or tenancy exists only across several inboxes.
Owners, tenants, and contractors all ask the same questions by phone and email.
Documents are emailed as attachments, and nobody is sure which version is current.
The management platform, the accounting system, and the spreadsheets each hold part of the truth.
Compliance dates — inspections, certificates, renewals — are tracked in a calendar somebody maintains.
Give each party a portal showing their own position, drawn from the systems already in place.
Model the process explicitly, with states, owners, and deadlines that chase themselves.
Put documents in one place with versioning and controlled access instead of as attachments.
Connect the management platform and the accounting system so the figures stop diverging.
Track compliance dates as data with automatic escalation, not as calendar entries.
In logistics the operational cost of a visibility gap is immediate: if a customer cannot see where something is, they call, and somebody spends ten minutes finding out. Multiply that across a week and it is a support team. The data usually exists — in a transport system, a warehouse system, a carrier's tracking feed — but not in one place and not in a form a customer or a planner can read. Most of the useful work is integration and presentation rather than new operational software, which also makes it cheaper and faster to deliver than the size of the problem suggests.
Customers phone to ask where something is, and answering takes several systems.
Carrier tracking data arrives in several formats and is reconciled manually.
Exceptions — delays, damage, failed delivery — are handled by whoever notices first.
Planning runs on a spreadsheet that cannot be used by two people at once.
Proof of delivery and documentation are captured on paper and scanned later.
Consolidate tracking from carriers and internal systems into one status a customer can see.
Build exception handling as a defined process with owners and deadlines, not as an interruption.
Replace planning spreadsheets with applications that support concurrent use and keep history.
Capture proof of delivery and documentation at the point it happens, on devices that work offline.
Report on where time is actually lost across the movement, rather than where it is assumed to be.
Professional services firms run on time, documents, and client communication, and the margin is decided by how much friction sits in each. Time recorded three days late is recorded inaccurately. A document nobody can find is written twice. A client who cannot see progress asks for an update, which costs billable time to produce. None of these need a large system. They need the specific friction removed at the specific point it occurs, which usually means connecting a practice management platform to the places work actually happens. The return on that is unusually easy to calculate, because every hour recovered is an hour that can be billed.
Time is recorded days after the work, which means it is recorded approximately.
Billing preparation is a manual assembly exercise every month.
Documents live across a practice system, a file share, and individual mailboxes.
Clients ask for progress updates, and producing one costs billable time.
Utilisation and pipeline reporting arrive too late to change anything.
Make time capture fast enough to happen at the point of work rather than at the end of the week.
Automate billing preparation, with exceptions raised for review instead of assembled by hand.
Put documents in one searchable place with permissions that match the client boundary.
Give clients a portal showing progress and documents, so the update is not a task.
Report utilisation and pipeline on a cadence that allows a decision to still matter.
Tell us what you're working on. We'll tell you honestly whether we're the right team for it.