Lesson 1: Scope One Workflow, Then Expand
The temptation with an AI product is breadth — a five-in-one pitch is exciting and the tech makes it possible. The discipline is narrowness: ship one workflow a user repeats, make the AI do it end-to-end, and define "good enough" before writing code.
- Start with the highest-frequency pain: for a calendar product, that's "add this event and remind me," not "analyze my whole month."
- One brilliant feature beats five mediocre ones — the market remembers the one thing you do better than anyone.
- Expand by user evidence: the second feature should be whatever the first 100 users actually ask for — not whatever was on the original roadmap.
Lesson 2: The Model Architecture Is a Product Decision
The "which model?" question is really three questions: local or cloud, which size, and what's the retrieval strategy? The answers shape the product's cost, latency, privacy, and pitch:
| Decision | When | Cost of getting it wrong |
|---|---|---|
| Local model | Sensitive user data, offline needs, privacy as the pitch | Per-request cloud costs that scale with success; privacy that can't be promised |
| Cloud frontier | Capability is the product; data isn't sensitive | Unit economics that make growth unprofitable; data-privacy blockers |
| Hybrid | Most products in 2026 — local default, cloud upgrade | Architecture complexity (manageable — see hybrid patterns) |
Smart Calendar's architecture — planner, reminders, and location logic running as integrated modules — is the shape of a good answer: the AI is a component, not the whole product. The pricing guide builds on this: architecture determines unit cost, which determines what you can charge.
Lesson 3: Validate Before You Polish
- Talk to 10–20 real users about their workflow — not your idea. Ask what they do today; find the friction.
- Build a 1-day prototype with existing tools: a local model + a script covers 80% of the validation. The 30-minute RAG and tool-calling guides are prototype-grade already.
- Watch them use it. Where they hesitate is the real spec.
- Measure return-rate: do they come back unprompted? That's the metric. Compliments are politeness; returning is evidence.
The MVP Launch Checklist
- ✅ One workflow, defined "good enough," shipped end-to-end
- ✅ Architecture matches the privacy/cost pitch (local/hybrid/cloud decided on purpose)
- ✅ Eval set exists and the model passes it
- ✅ 10+ real users have used the prototype; return-rate evidence, not just compliments
- ✅ Latency is acceptable on the worst device you support
- ✅ You know how to measure success post-launch (activation, retention, the one workflow's completion rate)
🚀 The pattern beyond one product
The same discipline applies at every scale: small businesses adopting AI, on-device apps, even translation pipelines — scope one workflow, choose the architecture on purpose, validate with real users, budget the hidden costs. Shipping Smart Calendar taught the playbook; every post on this site is a chapter of it.
Frequently Asked Questions (FAQ)
How do I scope an AI MVP?
Pick ONE workflow a user does repeatedly, make the AI do it end-to-end, and define "good enough" before writing code. Resist the feature list: an MVP that does one thing brilliantly beats one that does five things badly. Ship the one thing, watch users, then add the next.
Should my AI MVP use local or cloud models?
Depends on the data and the market: if users' data is sensitive, local (or hybrid) is the differentiator and often the only defensible choice; if capability at any cost is the pitch, cloud. The honest rule: local for privacy products, cloud for capability products, hybrid for both. Revisit after the first 100 users.
What is the biggest AI MVP mistake?
Building the model pipeline before finding the user problem — solving "how do I build RAG?" instead of "what does my user need answered?". The second-biggest: polishing features nobody has asked for. Validation before build, always.
How do I validate an AI product idea cheaply?
Talk to 10–20 potential users about their actual workflow, not your idea; build a 1-day prototype with existing tools (a local model + a script) and watch them use it; measure whether they return to it unprompted. Return-rate is the honest validation metric — compliments are not.
When should I add AI to a product vs build AI-first?
If the product works without AI, ship that first, then add AI where it compounds — the "AI as upgrade" path de-risks everything. If the product only exists because of AI (an assistant, a generator), build AI-first but wrap it in a narrow, concrete use case — "the app that does X" beats "an AI app".
What are the hidden costs of AI MVPs?
Evaluation (how do you know it's good?), data plumbing (real user data is messier than demos), latency budget (users forgive slow less than wrong), and model drift (upgrades change behavior). Budget for all four or the MVP is a demo, not a product.