I do the precision work. And I build the systems that make it faster.
I’m Anupam Singh. Most of the work that eats a week is the same problem wearing different clothes: information arrives in a mess, and someone has to turn it into something usable. A recording into a record. A shelf of old files into an answer. A rough draft into a piece worth publishing.
I do that work by hand — twenty years of medical and legal transcription, still current — and I build the systems that do it at scale. The second half is credible because of the first: I know where automated language systems quietly fail because I still catch them failing.
Twenty years in, still practising
Medical and legal transcription, editing and quality control — currently with Transcription For Everyone. Not a former career I reference; work I did this week.
I build the tools I use
The pipeline I run on my own work handles the mechanical layer to a standard I'd sign my name to. Systems I haven't relied on myself, I don't sell.
Yours to keep
You own the code, the data and the accounts. The engagement ends when you can run it without me.
Four problems, one shape.
Every one of these is information arriving in a form you can't use. The first two I solve by hand and deliver as finished work. The second two I solve by building you the system and handing it over — which I'm only willing to do for work I've done manually first.
Turn recordings into records you can rely on
You have twelve hours of interviews, consultations or testimony, and an automatic transcript that isn't close enough to use. I produce the finished document: correct speaker turns, real punctuation, consistent formatting, the domain vocabulary right.
Medical transcription · Legal and court transcripts · Editing and quality control
Make the writing say what you actually mean
You have something worth saying and a draft that doesn't yet say it — or no draft and no time to make one. I write and edit for a living, and I run two publications of my own, so this isn't a service invented for a website.
Content writing · Editing and refinement · Documentation
Stop doing by hand what a system should do
You waste three hours a day on work too varied to script and too dull to keep repeating. I built exactly this for my own transcription first — which is the only reason I can tell you honestly where it stops working.
Workflow automation · Internal tools · Custom web applications
Get answers out of your own files
Your team can't find what it already knows. It's in old matters, past projects, email threads and three people's memory. The work isn't acquiring the knowledge — it's giving it a shape you can ask questions of.
Knowledge management · Documentation systems · Search and retrieval
If you want to know how someone thinks, read them before you hire them.
This is the part of the site I'd point you to first. Essays on AI, attention, systems and the parts of thinking that don't automate — written to work something out rather than to fill a schedule. If the reasoning here is useful to you, the consulting is the same reasoning applied to your problem.
Built for a specific problem.
Kisan Sathi
Agricultural advice exists in abundance and almost none of it is local. A farmer needs to know about their soil, their district's schemes and the disease on their plant — not the national average.
Next.js · TypeScript · Tailwind CSS · Vercel · AI vision
Conscious Chronicles
Writing that sits with a question instead of answering it needs somewhere to live — and the effort should go into the essays, not into building a publishing platform nobody asked for.
Wix · Wix Blog
Saroj Vidyalaya
Most educational material explains a difficult idea by restating it in more technical language. That helps people who already understand it and abandons everyone else.
Next.js · TypeScript · Tailwind CSS · Vercel
Three steps, and you always know which one you're in.
Diagnose
About a week
A fixed-fee look at how the work actually flows today — not how the process document says it does. You get a written assessment: what's worth automating, what isn't, what it would cost, and what it would save. It's useful even if you stop there, and some people should.
Build
Two to six weeks, typically
Scope agreed in writing before I start. You use the thing while I'm building it, not after — that's how we find out what it actually needs to do. Nothing is called finished on my say-so.
Hand over
Then I'm out of the way
Documentation written for the person who'll use it, a walkthrough with whoever needs one, and every account in your name. If you need me later it should be because something changed — not because I made myself necessary.
Three things I’d rather say up front.
I'll tell you when you don't need AI
A clear rule and a well-built spreadsheet beat a model more often than anyone selling AI will admit. Finding that out early is worth what the diagnostic costs.
Fixed scope, agreed before I start
If the work changes, we talk about it before the invoice does. You should never be surprised by a number at the end of a project.
You own everything
Code, data, accounts, documentation. No lock-in, no proprietary layer only I can maintain, no retainer you can't leave.
Start with the one process that costs you a day a week.
You don’t need to know whether AI is the answer. Working that out is the job.