A lot of founders think adding AI to their product is a massive
undertaking. A new team, a new stack, months of work.
It doesn't have to be. Here's how I approach it.
START WITH THE PROBLEM, NOT THE MODEL
The worst AI features I've seen start with "let's add AI" and
then look for a use case.
The best ones start with a real problem — something the user
has to do manually, repeatedly, that a model could do better.
Report generation. Data summarization. Content personalization.
Document analysis. Automated responses.
Find the manual, repetitive, information-heavy task in your product.
That's where AI belongs.
THE SIMPLEST ARCHITECTURE THAT WORKS
For most AI features in a web app, you need four things:
A backend endpoint that accepts the user's data
A prompt that structures that data for the model
An API call to OpenAI or Claude
A response handler that validates and returns the output
That's it. No vector database, no agent framework, no embeddings —
unless you actually need them. Start simple. Add complexity only
when the simple version has a real limitation.
FRONTEND: KEEP IT ASYNC
AI calls take time. 2–10 seconds is normal. Your UI needs to
handle this gracefully.
Show a loading state immediately. Stream the response if the
model supports it — users tolerate waiting much better when
they can see text appearing than when they're staring at a spinner.
Never block the UI thread waiting for an API response.
PROMPT ENGINEERING IS PART OF THE FEATURE
The model is only as good as the prompt you write.
Spend real time on this. Define the output format explicitly.
Tell the model what to do when data is missing or ambiguous.
Test with edge cases — the weird inputs real users will definitely send.
A well-engineered prompt is as important as the code around it.
VALIDATION IS NON-NEGOTIABLE
Whatever the model returns, validate it before you use it.
If you asked for JSON, check it's valid JSON before parsing.
If you asked for a number between 1 and 10, check it's actually
a number between 1 and 10.
Models are good but not perfect. Your code needs to handle
the cases where the output isn't what you expected.
WHEN TO ADD MORE COMPLEXITY
RAG when you need the model to reference your own documents or data.
Agents when you need multi-step autonomous workflows.
Fine-tuning when you have a very specific output style that
prompting consistently can't achieve.
Not before. Complexity has a cost — in build time, in debugging
time, in maintenance. Earn it by hitting a real limitation first.
Most AI features in production are simpler than people expect.
The complexity is in the engineering discipline — error handling,
validation, good prompts — not in the architecture.
If you need an AI feature built properly and shipped fast —
that's exactly what I do. Get in touch.
