Independent AI practice · one-north, Singapore
I am a one-person AI practice in Singapore. I take a single workflow, prove whether a model actually helps, build it properly, and hand it over with the tests that keep it honest.
Singaporebuildsai is one pair of hands. When you write, you speak with the person who will read the documents, write the evaluation set, and ship the code. There is no account layer between the brief and the repository.
That shape changes how I schedule work. I take one engagement at a time, so dates mean something and the person who quoted the work is the person who is accountable for it. If a week slips, you hear it from me the same day I see it.
Most of the work that arrives here sits in logistics, professional services, light manufacturing, and public-adjacent teams. The common thread is a desk that already has a workflow, a pile of documents or records, and a question about whether a model would earn its keep.
A workflow is in scope when we can name the input, the decision, and a way to tell whether the output is good enough for the desk.
Retrieval
Policy packs, manuals, and shared drives that people already search by hand. I index what you actually use and put a citation on every answer. The desk can open the page and check the wording before a reply leaves the building.
Documents
Extraction, routing, and checks across invoices, shipping packs, and KYC files. The useful part is usually the exception path. We decide together what happens when a field is missing, a stamp is unreadable, or two systems disagree.
Forecasting
Demand windows, queue pressure, and roster load where a spreadsheet has already reached its limit. I keep the model small and publish the error in language the operations lead already uses. A dashboard the desk cannot challenge does not ship.
Evaluation
A test set drawn from your real examples, run on a schedule. A cost line sits next to the quality line, so scale is a decision you can see. This is often the first thing I build, and sometimes it is the only thing you need.
Copilots
A briefing tool for one role, wired to the systems that role already opens every morning. Scope stays narrow on purpose. A copilot aimed at the whole company usually helps nobody well.
Review
You already have something in production, or a vendor left you a repository. I read the prompts, the retrieval path, the tests that exist, and the ones that should. You get a written note and a recommended next step, including walking away.
Each stage ends with a decision you make, in writing, before I start the next one.
Scoping
We pick one workflow and write down the input, the output, and who is allowed to be wrong. I look at a sample of the data and tell you whether a model is even the right tool. This usually takes a week, sometimes two. You decide whether to fund a prototype.
Prototype
I build the smallest path that can fail in public. You see answers or forecasts on your own examples, with the mistakes still visible. Two to four weeks is typical. You decide whether the error rate is something the desk can live with.
Harness
I freeze a test set from cases you care about and run it every time the prompt, the index, or the model changes. You get a pass/fail view and a cost-per-run line. This is the stage where we either harden the build or stop.
Handover
You receive the repository, the environment notes, the runbook, and a session with two people on your side who can operate it. I stay available for thirty days after transfer. After that, changes are a new, scoped piece of work.
These are composite patterns drawn from the kinds of work I do. They are illustrations of shape and method, not client reports.
Retrieval & search
A desk that used to search shared drives by filename now asks a question and receives an answer with a page reference. The useful change is the citation: someone can open the source before the reply is sent.
Evaluation & guardrails
A nightly job that fails a build when an answer cannot be traced to a retrieved passage. The desk keeps the assistant only while the check stays green.
Document automation
Fields pulled from supplier PDFs, checked against a vendor list, and parked for a human when the totals disagree. The pipeline is slow on purpose at the exception step.
Forecasting & ops
A weekly window for parts that used to be ordered by habit. The model is allowed to be wrong; the operations lead is shown the error in units they already count.
Plenty of “AI” requests collapse into a lookup table, a validation script, or a change to who is allowed to approve a document. I will say so in the first week. You still get a written note and a bill for the time it took to find that out.
Some records cannot leave the country. That constraint decides the hosting, the model choice, and whether a hosted API is even on the table. I design around the restriction you actually have, rather than promising a stack and discovering the restriction later.
A prototype that looks cheap on twenty examples can become a line item once it runs all day. I keep a cost log beside the quality log from the first harness run, so you can see both numbers before you agree to scale.
If two teams disagree on the meaning of a field, a model will amplify the disagreement. If nobody owns the exception queue, automation will fill a folder that nobody opens. I write that down in the scoping note so it does not hide inside a demo.
Practice · January 2026
If we cannot agree on twenty examples of a good answer, we are not ready to pick a model. The test set is the brief, written in data.
Evaluation · February 2026
Most broken assistants fail at chunking, permissions, and stale files. The generator is the last place I look, once those three are boringly correct.
Data · February 2026
A residency requirement is an architecture decision. It changes which APIs I may call and how the evaluation runner is hosted.
A short note is enough: which desk, which documents or systems, and whether the data may leave Singapore. I reply within one working day and suggest a format, or I tell you I am the wrong person.
Start a brief
Singaporebuildsai