09
AI Development
Different from adding AI to an existing product — here the model is the product. That raises the bar, because your users will find the inputs your demo never had.
When this is the right fit
- The core value of what you’re building is what the model produces.
- You have a working prompt and no idea how to make it a product.
- You need retrieval over your own documents, evaluated rather than assumed.
- Someone needs to tell you honestly whether an LLM is the right tool at all.
- You’ve seen the demo work and want to know what it costs at scale.
How I build it
- 01
Decide whether it should be a model at all
Some features are better served by a query, a rule or a search index — cheaper, faster and correct every time. I’ll tell you when that’s the case, even though building the interesting version would pay better.
- 02
Evaluation before scale
A set of real examples with known-good answers, so a change can be shown to be an improvement rather than argued about. Without this you are tuning prompts by vibes, and it doesn’t converge.
- 03
Structured output, validated
Schema-enforced responses checked before they reach your application. Parsing free text and hoping is the single biggest source of AI-feature bugs in production.
- 04
Cost and failure, designed in
Token budgets, caching, timeouts, retries and fallbacks — so a provider incident degrades one feature instead of taking down your product, and your bill stays something you can forecast.
How long it takes
Four to seven weeks for a first product, depending on the requirements. The split surprises people: building it is fast, evaluating it honestly is not. Retrieval sits at the longer end, because the difference between something that seems to work and something that does is entirely in the measurement.
Questions about this
Can you build something from scratch?
Yes — mobile, web and AI-powered products. It's a different engagement from a rescue: we start with what the thing actually needs to do, and I'll usually push to get a small version in front of real users before building the rest. If your idea is better served by something simpler than what you're picturing, I'll say so.
Can you work with FastAPI?
Yes. FastAPI is my usual choice for Python services, particularly anything with an AI or data component. I’m comfortable across the surrounding ecosystem too — async workers, migrations and typed request models.
Can you help with deployment?
Yes, and it’s one of the most common reasons people get in touch. "It works locally" is almost always an environment, configuration or build problem rather than a code problem, and those are findable.
Your AI-built app doesn’t need another prompt.
Sometimes it needs an engineer.
Send the messy version. That’s usually the useful version.