Independent AI practice · one-north, Singapore
Four ways to work with me
Fees are quoted after the scoping call, against a fixed scope. I do not quote before I know the data.
Discovery sprint
This is for a team that has a workflow in mind and has not yet seen whether a model would earn its keep. You may already have a vendor demo. You may only have a folder and a frustrated desk.
I sit with a sample of the data, write a first evaluation set, and try the smallest path that can fail in front of you. I will also say when a rules change would do the job. The sprint is about two weeks of my time, with a working session in each week.
You leave with a written note, the draft test set, and a recommended next format — a build, a review, or a stop. You decide in writing before anything else is booked.
Build engagement
This is for a desk that already passed a discovery, or that arrives with a clear workflow, a sample of data, and two people who will own the result. I will still start with the evaluation set. I will not skip that because the demo looked convincing.
I design the path, put the harness in place, and harden what survives it. You see failing cases early. Scope stays on one workflow. If a second desk appears, we park it until this one is handed over.
At the end you have the repository in your account, the runbook, the test set, a cost log, and a session with two of your people. I remain available for thirty days for defects in what I shipped.
Evaluation and guardrails review
This is for a team that already has a build — from a vendor, from an internal spike, or from a prototype that somehow reached users. You want to know whether it holds, and what would make it safer to leave in place.
I read the prompts, the retrieval path, the logs, and whatever tests exist. I write the tests that should have existed. I try the awkward questions the desk already knows about. Residency and cost sit in the same note as quality.
After two to three weeks you receive a written review: what holds, what fails, and whether I would patch it, rebuild it, or leave it. That recommendation is yours to take to whoever owns the budget.
Advisory on retainer
This is for a team that has already taken a handover and wants a regular, bounded conversation while they operate the system. It is not a second build hiding inside a monthly invoice.
Each month we agree the hours in advance. Typical work is reading a proposed prompt change, extending the harness, and sitting with a failing nightly run. I will not start a new workflow on retainer hours.
You receive notes after each session. Either of us can end the retainer with a month’s notice. If a new build is needed, we quote it as a build.
Who this suits
This tends to fit
- A named owner who can judge whether an output is acceptable in the actual job.
- A workflow you can describe in a paragraph, with documents or records I can see.
- A constraint you will state honestly: residency, budget for inference, who will operate this in six months.
- Patience for a week of evaluation before anyone talks about a model card.
- Teams in logistics, professional services, light manufacturing, or public-adjacent work in Singapore.
This tends not to fit
- A request for an organisation-wide “AI programme” with no single desk in mind.
- A need for several parallel builds, or for a vendor to staff a bench.
- A deliverable that is primarily a slide deck or a market scan.
- A requirement to quote accuracy, or a fee, before I have seen the data.
- A system that must ship personal data to a region you cannot name.
Questions I am asked
Do I need clean data before starting?
A messy sample is more useful than a polished extract, because the mess is what the desk actually sees. In scoping I look at the files as they are. We may spend the first days labelling examples and writing down which fields cannot be trusted. Cleaning can be part of the work; it is rarely a prerequisite.
Can the system run without sending data outside Singapore?
Often yes, if we choose models and hosts that already run here, or that you operate in your own environment. This is an architecture decision. In scoping I ask what may leave the country and design around that answer. I am not your data protection officer; I treat the restriction you state as a hard constraint on the stack.
What happens if the evaluation says the model does not help?
We stop, or we switch to a rules path if one exists. You still receive the test set, the notes, and a written recommendation. I would rather bill you for a short, honest sprint than continue a build the harness has already failed. That outcome is a successful use of the practice, even when no model ships.
Who owns the code?
You do. The repository lives in your account. I do not retain a licence to reuse your documents, prompts that embed your data, or the test set drawn from your examples. Generic tooling patterns I already had may reappear in other work; your workflow does not.
Do you work with teams that have no engineers?
For discovery and for an evaluation review, yes. For a build that you will operate after handover, I need two named people who can be trained, even if they are not professional software engineers. If nobody will own the runbook, we should not start a build. I will say that in the first note.
How do you price changes after handover?
Defects in what I shipped, found within thirty days, are fixed under the original fee. New behaviour, a new corpus, or a new desk is a new scope. I quote that the same way I quote a build: after I know the data. I do not keep an open ticket book.
Can you review a build another vendor delivered?
Yes. That is a two to three week evaluation and guardrails review. I need the repository, the prompts, whatever tests exist, and a sample of production questions. You receive a written note: what holds, what fails, and whether I would patch it, rebuild it, or leave it.
What do you need from us during a build?
A named owner, access to a sample of real documents or records, and a few hours each week to judge outputs. Someone who can say whether an answer is acceptable in the actual job. If that person is on leave for a month, we should pick a later start.
Tell me which format you think you need
If you are unsure, say so. A brief that names the desk and the data constraint is enough for me to suggest a starting point.
Start a brief