Software that fits the way your business works.
Replace spreadsheets, inboxes and disconnected tools with a system designed around your actual workflows, permissions and data.
Useful when off-the-shelf software forces your team to work around the tool.
Illustrative system example · fictional product and data · not client work
Operations workspaceHARBOUR · illustrative system, fictional data
You may need this when
Some of this probably sounds familiar.
- Important work lives in spreadsheets that only one person really understands.
- The same information gets re-entered into two or three different systems.
- Approvals happen in email, so nobody can say who agreed to what.
- The software you bought does most of the job, but not the part that matters.
- Finding out what happened to a job means asking someone rather than looking.
What we could build
A system your team runs the work in.
Scoped to the part of the business that actually needs it — not a platform rebuild.
- Operations platformJobs, records and status in one place, with the states your process really uses.
- Internal portalA place for staff or clients to submit, track and retrieve work themselves.
- Approval workflowRequests routed by rule, with a record of every decision.
- Job-management systemScheduling, assignment and completion tracking across teams.
- Integration layerYour existing tools kept in step instead of re-keyed by hand.
- Admin & audit toolingSearch, history and permissions for the people who run the system.
See an example
What an approval actually looks like in a system.
Take the three steps below. Watch the record change state and the audit trail build itself — that trail is the difference between software and a shared inbox.
Shown as a completed run. The step controls need JavaScript, so they are not offered here.
- Ops teamSupplier request submitted for review by the operations team.
- SystemDuplicate check, company lookup and document completeness verified automatically.
- FinanceApproved by Finance. Decision, approver and timestamp written to the record.
OutcomeA new supplier request starts as a draft that nobody else can see yet.
OutcomeThe supplier enters the operational system with a permanent record of who approved it and when.
Illustrative system and fictional data. Not client work.
The same pattern covers purchase requests, onboarding, site handovers, change requests and anything else that currently depends on someone remembering to chase it.
What you receive
A working system, and everything needed to keep it.
- A working application your team uses for real work
- Accounts, roles and permissions configured for your people
- Automated tests covering the behaviour that matters
- Documentation written for whoever maintains it next
- Agreed source code, data and infrastructure handed over according to the project scope and terms
- Handover documentation and any agreed support arrangements
Technical depth
Architecture
Services sized to the requirement rather than maximum complexity. Business logic kept out of the interface so the same rules apply however work arrives.
Data
A relational model designed around your real entities, with migrations under version control. An append-only history can be added where a record needs to be defensible.
Integrations
REST and event-driven interfaces, webhook receivers, and retry with idempotency where a repeated message must not create duplicate work.
Security
Authentication, role and record-level permissions, and audit trails on the state changes that matter to the agreed scope.
Testing
Automated tests for expected behaviour, permissions and failure paths — including what the system does when a dependency is unavailable.
Operations
Deployment, structured logging and error reporting, with monitoring depth matched to how consequential the system is.
Often combined with
What usually sits next to this.
- Automation & integrations →When the system needs to keep other tools in step without manual re-entry.
- Data & analytics →When the work the system captures should also answer questions about performance.
- Websites & digital products →When customers need their own view into the same system.
Tell us what your team is working around.
You do not need a specification. Describe the process and where it breaks down.