For mid-size companies · 50–1,000 people
You've outgrown off-the-shelf software. You haven't outgrown your budget.
Too many tools billed per seat, spreadsheets carrying the work between them, and an IT team with no spare capacity. We assess selective software and integration improvements. Operating support is conditional on agreed scope and staffing.
Sound familiar
Three signs you're ready for custom.
Spreadsheets hold it together
The real process lives in exports, side sheets and one person who knows how it all connects.
Seat costs keep climbing
Every hire adds licences to tools that each do part of the job — and none talk to each other properly.
IT is at capacity
Your team keeps the lights on. There's no one free to design, build and own a new system.
How it works
One team from audit to a running system.
01
Audit
Agree a diagnostic scope using redacted samples; system access needs separate approval.
02
Redesign
Compare buy, configure, integrate, selective build or stop; decide what stays human.
03
Build
A bespoke system and agents around your real workflow and data.
04
Run
Agree staffing, support and acceptance before any operating phase.
05
Measure results
Measure against the baseline agreed in the audit. Compare observed results and costs; no ROI is guaranteed.
What procurement gets
A supplier, not a freelancer.
A named team
An engagement lead, an architect and engineers named during scoping, before you sign.
Cover and continuity
Backup and documentation arrangements are agreed in the proposal for your scope.
Clear contracts
Scope, ownership, confidentiality and handover terms require agreement before sensitive material is shared.
Security answers
Access control, audit trails and data handling explained up front — see our security page.
Who we serve here · Proposed hypothesis
Who is involved, and what each person receives at the end.
A 50–1,000 person company running a core department on spreadsheets, glue scripts and several per-seat tools that each do half the job.
User
Department head / COO
Needs: A system that matches how the team actually works, not how the vendor imagined it.
Doubt: Custom software sounds slow, risky and hard to maintain.
Proposed deliverables · agreed in scope
- • A mapped real-vs-documented process
- • A running system for one department
- • Runbooks the team can follow
Buyer
CFO / finance lead
Needs: A cost case that holds against current seat spend and manual hours.
Doubt: The return will be asserted, not measured.
Proposed deliverables · agreed in scope
- • A baseline agreed before work starts
- • A 3-year rent-vs-own comparison
- • A measured result against that baseline
Approver
IT / security lead
Needs: Something supportable that does not add shadow IT.
Doubt: Another system the IT team will be left holding.
Proposed deliverables · agreed in scope
- • Architecture and data model documentation
- • Access control and audit design
- • A named handover plan
Affected
The team doing the work
Needs: Less re-keying and fewer workarounds.
Doubt: Automation will be imposed without asking them.
Proposed deliverables · agreed in scope
- • Shadowing time where their workarounds are recorded
- • Clear lines on what stays human
Responsibilities, not a promised roster: economic buyer, process owner, user, technical approver and operator may overlap. Explore the Finance illustrative example →·MSP illustrative example →.
Our promise
We will map how one department really works and tell you, with numbers, whether to buy, configure, integrate or selectively build.
Holds when
- • You give us access to the people and systems
- • One accountable owner is named on your side
- • The scope is one department first
Limits — what we don't promise
- • We do not promise a return figure before the audit
- • If off-the-shelf fits, we will say so and stop
- • We do not replace your ERP or core ledger in phase one
Evidence, labelled honestly
- Owned product directions; stage and evidence limits on each noteContext
- Seat-vs-owned calculatorProposed
- Sample audit reportProposed
- Measured ROI for a mid-size clientUnknown
Context = portfolio direction, not operational acceptance · Proposed = our method, not yet proven for this audience · Unknown = we won't claim it yet.
Access we ask for — and how you take it back
- • Read access to the department's tools and exports
- • Shadowing time with named team members
- • No production write access during the audit
Access is limited to the department in scope and logged.
Initial inquiry: non-sensitive summary only. Later assessment: authorised redacted samples or read-only access. Sandbox and production write access require separate approval, minimisation, access expiry and retention agreement.
Agree revocation, working-copy handling, retention exceptions and confirmation responsibilities before access.
Something useful to pass along
A one-page audit summary the COO can hand to the CFO and board.
Useful to: Finance and leadership deciding whether to fund a build.. Shared only if you choose to.
Why you'd come back: Assess whether later departments can reuse suitable components, subject to scope and staffing.
What we watch for harm: Support load and manual workarounds after handover — if they rise, we report it.
Proposed workflow journeys
Explore the five decisions behind a pilot.
Illustrative custom engagements, not verified demand, installed integrations or customer results.
Meet the people
See who you'd be working with.
Architecture leadership and any specialist roles are named during scoping, subject to availability.