AI that ships, not AI that demos
AI development for founders who want a feature in production, not a proof of concept in a deck. I run my own AI product on Claude, GPT and Gemini at the same time — so when I add AI to your product, I'm reusing code that already survived real users, real costs and real failure modes.
What I build
AI features in an existing product
Search that understands a question, support that answers from your own docs, drafting that sounds like your team. Added to the product you already have, without a rebuild.
AI products, end to end
I built and run WebSeek.ai — one prompt to a deployed site, with a Claude / GPT / Gemini model picker. Three providers in production, not a demo. If you're building the product, I've shipped the shape of it.
Retrieval over your own content
RAG done honestly: your docs, policies or catalogue as the source, with citations back to the page. The useful version of a chatbot — one that can say 'I don't know' instead of inventing a refund policy.
Model choice, cost and fallbacks
Which model, at what price per call, and what happens when it's slow or down. The unglamorous engineering that decides whether an AI feature survives contact with real traffic.
Why me for this
One prompt to a deployed, custom-coded site, with a model picker for Claude, GPT and Gemini. Running all three in one product means the differences are ones I've had to handle for real — prompt shapes that work on one and not another, failure modes, and what each costs per call. Read the case study →
A local-business schema graph and an llms.txt file so assistants quote the routes accurately. The same discipline, pointed at being cited rather than generating. Read the case study →
A school portal where the right answer was ordinary software, not AI. Shipped in 7 days. I'd rather talk you out of a model than bill you for one. Read the case study →
How it ships
- FP101
Find the job worth automating
Most AI ideas fail because nobody named the task. We start from a job your users actually repeat — then decide whether a model is even the right tool. Sometimes the answer is a better form.
- FP202
Prototype against real inputs
Your actual content and your actual edge cases, not a curated demo. This is where most concepts either earn their place or quietly die, and it's much cheaper to find out here.
- QUALI03
Ship it with the guardrails on
Evaluation on cases you care about, a fallback when the model misbehaves, cost caps, and logging you can read. An AI feature without these is a prototype in production.
- RACE04
Hand over something maintainable
Clean repo, prompts in version control, and a written explanation of why each choice was made — so swapping a model later is an afternoon, not a rewrite.
Thinking on AI builds
Which AI features earn their keep on a business website, and which are demos that never ship. Which AI features actually work on websites →
What changed from shipping client sites with AI every day, and what didn't change at all. How AI is changing web development →
When a chatbot should actually read your docs — and when retrieval is the wrong tool entirely. When RAG is the right tool for a business website →
Every article on AI and web development in one place — building with it, shipping features, and where it stops being useful. AI in web development →
Questions I get.
One that removes a repeated task or answers a question your users keep asking. Search over your own content, support that cites your real documentation, drafting a first version of something a human then edits. If a feature only demos well and nobody would miss it, I'll tell you that before we build it.
Whichever fits the job, and I've shipped all three. I run WebSeek.ai on Claude, GPT and Gemini simultaneously, so the differences are ones I've handled in production rather than read about: prompt shapes that work on one and not another, latency and cost trade-offs, and how each fails. The choice is made per feature, and the code is written so it can be changed later.
Usually yes. Most AI features attach to an existing product through an API rather than requiring a rebuild — that's the normal case, not the exception. What matters more than your framework is whether your content is in a shape a model can retrieve from, which is the first thing I'd look at.
Any language model can. The engineering answer is retrieval plus citations plus a real 'I don't know' path — the system answers from your content and links to the source, instead of generating something plausible. That is a design decision, and it is the difference between a useful assistant and a liability.
Quoted individually after a scoping call, fixed and in writing before anything starts. The honest driver is not the model — it's how messy your content is and how much accuracy the feature needs. A search box over clean docs and a support agent that must never be wrong are very different jobs.
Got an AI idea you're not sure about?
Describe it in three sentences. I'll tell you whether a model is the right tool, what the smallest useful version looks like — and if the honest answer is "you don't need AI for this", you'll get that instead.