How I built this site
This site is a small example of how I work. The interesting part is not the code, it is the decisions, so here they are in plain terms.
The front door is a search box
Instead of a wall of services and case studies, the site leads with one question: what are you trying to solve? You describe your problem and it finds the work of mine that genuinely relates, and says why, in plain terms. If nothing really fits, it tells you that rather than pretending.
The decision that matters: not over-building it
The fashionable way to build this is with a vector database and a retrieval pipeline. I deliberately did not. There are fewer than twenty written-up pieces of work here. At that size a vector database solves a problem I do not have, while adding moving parts I would then have to maintain.
So instead, each piece of work is turned into a numeric fingerprint once, and a few lines of plain code rank them against your question. That ranking alone decides what you see, and in what order. A language model is then handed each result on its own and asked to do one narrow thing: write the short, factual line explaining how that piece of work relates to what you asked. It does not choose what shows or change the order, it only explains, and each line is written independently so it speaks only to that one piece of work. The result is cheap to run, and there is almost nothing to maintain.
The same technique, the opposite decision, elsewhere
I also build and run Community Bookshelf, an app that lets a school community share books. It uses the very same search idea, but there it sits on a proper vector database, because it deals with thousands of books rather than a couple of dozen. Same technique, opposite engineering decision, because the scale is different. Knowing which call to make in which situation is most of the job.
Experience is the guard rail
A fair question is how this stays correct while moving quickly. The speed comes from knowing the best way to build something and getting AI to do it, in a fraction of the time it would take to write by hand. The quality comes from the same knowledge. Experience is the guard rail: it is what catches the AI when it heads down the wrong path, and what keeps the result architecturally sound, scalable and robust. The AI is fast. The judgement is what makes it right.
What “minimal” actually means
Minimal is not less capable, and it is not about being quick. It is about not over-engineering: spending the effort on the things that matter and leaving out what you do not need, so there is less to maintain and less to go wrong. Used by someone who knows what the right thing is, modern AI tools make that kind of focus achievable without a large team or a large bill. That is the whole idea, and this site is it in practice.
If that is the kind of thinking you want on your side, tell me what you are working on.
Try the search Email me