Software firms
The expensive part is rarely the software. It is the eleven people working around it.
For established product companies with real customers, real systems, and internal processes that take longer than anyone in the room would admit out loud.
Work delivered for
- Singapore Government project
The problem
Somewhere in your company there is a spreadsheet that three people maintain by hand, and it is load-bearing. It exists because the official system does not quite do the thing, and it has existed long enough that nobody remembers it as a workaround any more. It is simply how that work gets done.
You have almost certainly already tried to fix this with tooling. A licence was bought, a pilot ran, somebody built a proof of concept that impressed the leadership team. Months later the licence renews automatically, the pilot has no owner, and the spreadsheet is still there.
The harder problem is that your engineering team is not wrong about any of this. They know where the friction is. What they do not have is a fortnight to sit with the operations team and read how work actually flows, because they are shipping the roadmap that customers are waiting on. So the internal problems stay internal problems, and the cost of them never appears in a single line anyone reviews.
This is for you if
- You have systems that already hold the data, and processes where people move information between them by hand.
- You can name a team whose hours are visibly going somewhere unproductive, even if you cannot yet quantify it.
- You have an engineering function that will own what gets built, and a review process it has to pass.
- Somebody senior is willing to be told that the AI project already announced internally is not the one worth doing.
This is not for you if
- You want a per-seat AI product to buy. We build into your stack rather than selling you a licence.
- The work is regulated to the point where compliance is the majority of the build, for example clinical or core banking systems.
- Nobody can give an outsider access to a staging environment or a data sample under NDA. There is no version of this that works blind.
- The real objective is a headcount reduction you would rather not say out loud. We will measure hours saved honestly, and the honest measurement is often smaller than the business case assumed.
The method
The method, in your situation
- IdentifyTwo to five days with the people doing the work, not with the people describing it. We read the actual flow, find the spreadsheets, and price the friction in hours and money. The recurring finding is not the one everyone expected: on the DHL programme the largest single win was deduplicating traffic between two systems, with no model involved at all.
- BuildInto the systems you already run, under your review process, in your repository, with the integration points documented. Where a model is involved it comes with evaluation. Where the honest answer is deterministic code rather than a model, we build deterministic code and say so, because a company paying for AI and receiving a well-built integration has been served better than one paying for AI and receiving AI it did not need.
- ProveThe baseline is taken before anything ships, against a metric your operations lead already tracks. Handling time, queue depth, error rate, escalations per week. We read the same measure afterwards and the note says whether it moved. Where the change is partly attributable to something else that happened that quarter, the note says that too.
What you get
What you end up holding
Artefacts rather than activities. Each of these is a thing that exists after we leave.
A process map with numbers on it
Where the hours go, per team and per step, with the assumptions written down so your operations lead can dispute them. Several clients have found this more useful than the build that followed.
The build, in your repository
Running in your environment, through your pipeline, reviewed by your engineers. Integration points and failure behaviour documented in the same place your team documents everything else.
A runbook
What to do when it breaks, what the failure modes look like, and who to call. Written for the engineer who inherits it rather than for the one who built it.
The before-and-after note
Two to four pages, the same metric measured twice, with the attribution stated honestly. Suitable for a board pack without a rewrite.
Getting started
How engagements start
- A 30-minute call to describe the process that is costing you and hear whether it sounds like something Identify would find anything in.
- A fixed-fee Identify engagement scoped by how many teams we need to sit with. Two to three weeks, fixed end date, written output, nothing owed afterwards.
- If a build follows, it is scoped against one named opportunity with a firm price. Your engineering leadership sees the plan before it starts.
If one of these is you
You shipped the AI feature. Nobody can say what it changed.
For product teams whose AI launch went out months ago and has not appeared in a board deck since, because there was never a before to compare it to.
You rolled out AI to the whole company. Check who opened it last week.
For companies twelve months into a licence renewal they cannot justify, where the pilot went well and the adoption did not.
One limit worth stating
Identify frequently finds that the biggest saving available to you is not an AI project. It is a data quality problem, a permissions problem, or two systems that should be talking to each other and are not. We will tell you that, and it means the engagement you were expecting to buy is smaller than the one you were expecting to buy. Some companies find that unsatisfying, particularly when a budget has already been allocated under an AI heading.
FAQ
Questions from people in your position
Next step
If there is a process in your company that costs more hours than anyone wants to say out loud, describe it on a call and we will tell you whether it is worth a fortnight of looking.