How we work
Most AI budgets are spent before anyone has worked out which project deserves the money.
One practice, three steps, in this order. Below: what you can engage us for, then what actually happens inside each step, then the work we turn down.
Work delivered for
- Singapore Government project
Identify
We spend two to three weeks with the people doing the work and find where the hours actually go. You get back a ranked list of what is worth building, a longer list of what is not, and a baseline number for each survivor. Most ideas do not survive that second list. You spend the budget on two things that pay rather than nine that demo.
What actually happens
- Two to five days sitting with the people doing the work, watching how a task actually moves rather than how the process document says it moves.
- A read of the systems already in place, including the spreadsheet somebody maintains privately because the official tool does not do the thing.
- A cost model on the two or three candidates that survive, in hours and in money, with the assumptions written down so you can argue with them.
- A written no on everything else, with the reason.
What you end up holding
A document, usually 12 to 20 pages, naming the opportunities worth building, the ones that are not, the baseline number for each survivor, and what it would take to build them. It is written to be read by your CFO as well as your engineers.
Build
We build it and put it in your systems. Your engineers review the code, your pipeline ships it, and we write down how it works and what to do when it breaks. If it is not in production, we are not finished.
What actually happens
- A scoped build against one of the opportunities, into the stack you already run.
- Evaluation where a model is involved, meaning a held-out set and a measured accuracy rather than a demo that went well.
- The failure cases handled, because the interesting part of an AI feature in production is what it does when it is wrong.
- Handover written for the engineer who inherits it, and a working session with them before we leave.
What you end up holding
Software running in your environment, in your repository, under your review process, with a runbook. Not a prototype in our account.
Prove
We agree the number before writing any code, record it, then read it again once the work has been live long enough to count. If it did not move, the report says so. A number with no before is a claim, not a result.
What actually happens
- The baseline, taken before the build starts, against a metric you agreed and your board already recognises.
- The same measurement after the build has been live long enough to mean something, which is rarely the first week.
- A short report saying what moved, what did not, and which part of the change is attributable to the build rather than to something else that happened that quarter.
What you end up holding
A two to four page result note you can put in front of your board without editing it first. Where the number did not move, it says so and explains what we got wrong.
The same method, applied to your situation
Startups
Pre-launch to Series B. You want AI inside the product without hiring an AI team first, and you need the build to survive contact with real users.
Software firms
Established product companies with real customers, real systems, and internal processes that take longer than anyone in the room would admit.
VCs and accelerators
Funds and programmes that need a technical read on what they are about to back, and hands-on help for the portfolio afterwards.
FAQ
Questions about how the work runs
Next step
The first call is 30 minutes and its only job is working out whether Identify would tell you anything you do not already know.