I'm Sid. I build software on my own, end to end. A good deal of it has AI in it and some of it has none at all, and either way the job is the same: get it into production and then measure it until the numbers hold up.
Four things. Most projects want two or three of them, and the useful part is usually that one person is doing all of them rather than handing work across a boundary.
LLM applications, retrieval over your own material, and document pipelines that turn forms, contracts and reports into structured fields something downstream can act on. This is where a lot of the recent work has been, and it is the part people most often come to me for.
Held-out sets, scoring, confidence thresholds, and a defined path for when a system should not answer. It matters most on AI work, where a wrong answer looks exactly like a right one, but the habit is the same anywhere: know the failure rate before a customer finds it.
APIs, containers, cloud, queues, monitoring, and the deployment that keeps a thing running after launch. Encryption and access control when the work needs it. This is the half of most projects nobody photographs.
Sites and small products, built and shipped rather than mocked up. Sometimes that is the whole job and there is no model in it anywhere, which is a perfectly good outcome.
Seven projects across five sectors and three kinds of work. Some of it is AI, some of it is a constraint solver, one of it is an encrypted delivery system for photographers. The filter below covers the client work; what I have built for myself is in its own band underneath.
Filter by sector, by the kind of work, or by both at once. The range across the two axes is the point.
Sector
Kind of work
5 client projects5 sectors3 kinds of work
InsuranceAI systems
Decision support for income insurance, built so a regulated audience can see why it said what it said.
Models the trade-off between coverage and premium so employers and their advisors can compare sick-leave policies side by side. Deterministic rule-based logic does the parts that must be exact, and the model handles the parts that need reading and reasoning, which keeps every recommendation traceable back to a rule or a source.
EducationAI systems
Evaluation infrastructure for an edtech platform, so changes to the model could be measured instead of argued about.
Context-aware pipelines that generate adaptive follow-up questions, running across more than a million user interactions. The larger piece was the automated LLM-as-judge framework underneath it, plus benchmarking across latency, cost and retrieval accuracy, which turned prompt changes into something with a number attached.
Public sectorAI systems
Retrieval assistants for Dutch municipalities, in production, run by one person.
Conversational systems that answer from municipal documents, deployed on GCP as Dockerised microservices. Retrieval and prompt optimisation cut response latency by 40 percent. Sole engineer on it, which meant the APIs, the deployment and the production monitoring as well as the model work.
EventsCustom tooling
A solver that puts every attendee into the workshops they actually asked for.
All Energy Day runs parallel workshop sessions with limited places, and everyone attending submits the ones they want. That is an assignment problem, not a spreadsheet job: preferences compete, places run out, and a choice made for one person changes what is available to the next. I modelled it as a constraint problem and solved it with Google OR-Tools, so the whole allocation is computed in one pass and can be re-run the moment the numbers move.
Arts and photographyWebsites
A portfolio site for an artist, built to get out of the way of the pictures.
Charcoal portraits, ink drawings and acrylics, which means the build is mostly restraint: a full-bleed gallery, long-form process pieces for individual series, and a visualise section that shows the work hanging in a real room rather than floating on white. Astro with React for the interactive parts, so the pages ship as static HTML and only the pieces that need it hydrate.
Things nobody paid me to build. They are here because they show what I do when I pick the problem myself.
Arts and photographyCustom tooling
A distribution system for fashion photography that can tell you who leaked a file.
Every buyer gets an archive carrying an invisible watermark unique to them, so a leaked image points back to a single purchase. Archives are AES-encrypted, links are single-use and expiring through a Cloudflare Worker, and a dashboard tracks where they were opened.
ConsumerCustom tooling
A World Cup calendar builder with no signup, deliberately tiny in scope.
Pick your teams, get timezone-correct fixtures in Google, Apple or Outlook. There is no account and nothing to install. It found more than 250 users through nothing but organic sharing, which is most of what I wanted to learn from it.
Retrieval, which is how the municipal assistants work. One of the seven projects on this page. I have drawn it because it is the easiest way to show you I am not hand-waving, not because it is anything like most of what I do.
A flow diagram in two lanes. On the left, work done once when the system is built: your documents are split into passages, each passage is embedded as a vector, and the vectors are stored in an index. On the right, the path taken by every question: the question is embedded, matched against the index to retrieve the closest passages, those passages are reranked, the model generates an answer from them, and the answer is scored for confidence. A gate then compares that score against a threshold. Above the threshold the answer is returned with its citations. Below it, the case is sent to a person.
A four-week fixed-price pilot. One named thing, your real data or your real users, and a number at the end. It exists so you can find out what this costs and whether it works before committing to a build.
Pick the one thing worth proving and get access to what it needs. Agree what working means and how we will measure it. Most of the value of the pilot is decided in this week.
Build the first version end to end, running on your data rather than on a demo set. Rough, but real.
Measure it against what we agreed. Accuracy on a held-out set if there is a model in it, latency and running cost either way, and a written list of where it fails and how often.
Write it up and hand it over. You get the prototype, the numbers, the failure cases, and a recommendation.
If the numbers do not support building it, I say so and we stop there. The honest no is part of what you are paying for, and it is a great deal cheaper than finding out in month seven.
Usually a build phase: hardening the prototype, putting it in front of real users, and handing over something your team can run without me. We scope that at the end of the pilot, when we both know what it actually takes, rather than guessing at the start.
Two lists I would want to read on somebody else's site.
I'm Siddhartha Sen. Most people call me Sid. I have an MSc in Artificial Intelligence from TU Delft, I spent time at Oracle before going independent, and Insenai is me, working out of Rotterdam.
I work mostly with organisations that need something built and have nobody in-house to build it or to judge it. Depending on the job that is the model work, or the backend, or the whole site, and either way you get one person to talk to instead of an account manager and a delivery team you never meet.
I like the parts other people find tedious. Failure cases, held-out sets, what a thing actually costs to run once real traffic hits it. That is where you find out whether something is real.
Tell me what you need built, roughly how big it is, and what you have already tried. That is enough for me to say something useful back.