Question 1

Should my startup add AI features, and which ones actually matter to users?

Accepted Answer

Users do not care that a feature uses AI; they care whether it removes a slow, painful, judgment-heavy step from their day. Start from a specific friction point in your existing workflow, not from the technology, and be honest about whether AI is a checkbox for investors or a real 10x on time saved. The strongest AI features sell the finished work (a resolved ticket, a drafted document), not a fancier tool.

Question 2

How do founders ship their first AI feature (APIs, wrappers, RAG in plain terms)?

Accepted Answer

Your first AI feature is usually one API call: send the model your instructions plus the user's input, get text or structured JSON back, and wrap it in your existing UI. RAG simply means fetching your own data (docs, tickets, listings) and pasting the relevant bits into the prompt so the model answers from your facts instead of its memory. Ship a thin version in days with the OpenAI or Claude API and a toolkit like Vercel's AI SDK, then iterate on prompts before touching anything fancier.

Question 3

How much does it cost to run AI features, and how do I keep costs sane?

Accepted Answer

You pay per token (roughly per word) in and out, so cost scales with usage; a small feature can run on tens of dollars a month while a chat-heavy product can quietly eat 30-60% of revenue. The good news is prices for the same capability keep falling about 10x a year, and three habits (prompt caching, routing easy requests to cheap models, and batching non-urgent work) routinely cut bills 50-80%. Instrument cost per user per feature from day one so pricing decisions are based on data, not fear.

Question 4

Which AI model should I build on (GPT, Claude, Gemini, open-source), and how do I avoid locking myself in?

Accepted Answer

There is no best model, only a best model for your task at your price: test the top two or three on your own real examples rather than trusting benchmark headlines. Design your code so the model is a swappable config value (a thin gateway or SDK abstraction does this), because prices and leaders change every few months. Open-source models make sense once you have scale, strict data constraints, or a narrow task; for most first features a hosted API wins on speed to ship.

Question 5

How do I test whether my AI feature actually works before launch (evals, in plain terms)?

Accepted Answer

An eval is just a repeatable test suite for your AI feature: 30-100 real example inputs, the output you expect, and a way to score each run. Start by reading your model's actual outputs and labelling errors by hand (error analysis); patterns you find become automated checks, either simple code assertions or an LLM grading another LLM. Teams that skip this iterate blind; teams that build even a scrappy eval loop ship better AI faster than competitors.

Question 6

How do I stop my AI feature from making things up in front of customers?

Accepted Answer

Models hallucinate because they are trained to always answer; your job is to constrain them, not to hope. The biggest wins in order: ground answers in your own retrieved data with citations (RAG), force structured outputs so responses are validated before display, let the model say "I don't know", and add guardrails plus human review on high-stakes actions. Air Canada and Cursor both learned publicly that you own whatever your bot says, so treat reliability as a launch requirement, not a polish item.

Question 7

Prompt engineering, RAG, or fine-tuning: which one does my product actually need?

Accepted Answer

Work up the ladder: better prompts cost hours, RAG costs days and adds your own live data, fine-tuning costs weeks and only changes behaviour and style, not knowledge. Most teams that fine-tune could have gotten the same result from a cleaner prompt and better retrieval, so treat fine-tuning as a last resort for narrow, repeatable patterns at volume. The emerging umbrella skill is context engineering: deciding exactly what information lands in the model's window for each request.

Question 8

How do I design AI features people trust (chat vs buttons, streaming, showing the work)?

Accepted Answer

A chat box is rarely the right interface: embedded AI (suggestions inside the existing workflow, one click to accept or reject) builds trust faster because users can see the AI's scope and undo its work. Stream responses so something appears within a second, show sources and reasoning where accuracy matters, and use fixed buttons with confirmation for anything risky. Design for the failure case first; how your product behaves when the AI is wrong is what users remember.

Question 9

What is my moat if I'm building on someone else's model?

Accepted Answer

The model is not your moat and never will be; the moat is everything you wrap around it: proprietary data and feedback loops, deep vertical workflow ownership, integrations, distribution, and craft. Most great SaaS companies also started with zero defensibility and built it through usage, so "just a wrapper" is a starting point, not a verdict. The pattern that works is going narrow: own one industry's whole workflow so deeply that a general model in a chat window cannot compete.

Question 10

Should I put an AI agent in my product, or is a simple workflow enough?

Accepted Answer

A workflow follows steps you defined with the model filling in the reasoning slots; an agent decides its own path with tools in a loop. Workflows are cheaper, faster, and debuggable, and they cover most real product needs (tagging, drafting, summarising, extracting); agents earn their complexity only when the path genuinely cannot be known in advance. Both OpenAI and Anthropic say the same thing in their own guides: start with the simplest thing, add autonomy only when a measured need appears.

Question 11

Is it safe to send customer data to AI APIs, and what about privacy laws like India's DPDP Act?

Accepted Answer

The major API providers (OpenAI, Anthropic) do not train on your API data by default and offer short or zero retention, so the common fear is mostly solved by reading the actual policies and signing the right agreement. Your real risks are elsewhere: prompt injection and data leakage in your own app (see the OWASP LLM Top 10), and your legal duties as a data fiduciary under India's DPDP Act or GDPR, including consent, purpose limitation, and deletion. Minimise what you send, redact PII where you can, and put your provider's terms in your own privacy policy.

Question 12

How should I price AI features: per seat, per use, or per outcome?

Accepted Answer

AI broke flat per-seat pricing because every request has a real compute cost; most AI-native companies now run hybrid pricing: a base subscription plus usage credits, with outcome-based pricing (like Intercom's $0.99 per resolved ticket) emerging where results are measurable. Anchor your price to the value of the work replaced, not to your token costs, and protect margins with usage caps or credits. Expect to revise pricing often; the leading AI companies changed theirs multiple times a year.

Question 13

My AI feature is live. How do I monitor it and make it better with real usage?

Accepted Answer

Log every AI call with its prompt, response, cost, latency, and user feedback; observability tools like Langfuse or LangSmith give you this in an afternoon and turn debugging from guesswork into search. Watch AI-specific metrics, not just usage: task completion rate, retention of AI-feature users versus everyone else, and thumbs-down clusters that reveal failure patterns. Feed real production failures back into your eval set so every incident permanently raises your quality bar.

How founders use AI for AI in Your Product

Also in Starting Up