Your First AI Product: What to Build and What to Skip

TL;DR

• First-time AI teams over-invest in model infrastructure (custom training, complex RAG, fine-tuning) and under-invest in user understanding: the result is impressive technology that feels generic
• The minimum viable AI stack is simpler than you think: a foundation model API, a self-model layer, and a quality rubric, everything else can come later
• The number one thing to skip on your first AI product is custom model training, use an off-the-shelf model and invest the saved time in understanding your users

Building a first AI product requires a minimum viable stack of three components: a foundation model API, a self-model layer for user understanding, and a quality rubric. Most teams over-invest in custom model training and complex RAG pipelines while skipping the one layer that differentiates their product from every other app calling the same API. This post covers the minimum viable AI stack, the features to skip entirely, and the week-by-week build order that gets a personalized product to market in five weeks instead of six months.

The Minimum Viable AI Stack

Your first AI product needs exactly three things:

1. A foundation model API. Not a custom model. Not a fine-tuned model. An API call to GPT-4, Claude, Gemini, or whatever foundation model suits your use case. This is a solved problem. You can switch models later. Do not spend your first 3 months on something you can change in a day.

2. A self-model layer. This is what most teams skip and what matters most. A self-model is a persistent, evolving representation of each user, their goals, expertise, preferences, and patterns. It makes every AI response personal instead of generic. Even a basic self-model (role, expertise level, primary goal) dramatically improves quality.

3. A quality rubric. You need to know whether the AI is good. Define the four dimensions (relevance, coherence, depth, fit), score 20 interactions manually, and you have your first baseline. Without measurement, you are guessing.

That is it. Three things. A model API, a self-model, and a rubric. Everything else is iteration.

What to Build: The Self-Model Layer

The self-model is the single highest-ROI investment for your first AI product. Here is why.

A foundation model through an API gives you an AI that is as smart as everyone else’s AI. Every competitor using the same model gets the same base quality. You cannot differentiate on model intelligence when everyone has access to the same models.

A self-model gives you an AI that knows each user. No competitor can replicate your accumulated understanding of your users. The self-model is the differentiation layer.

For your first version, the self-model needs to capture five dimensions:

Primary goal: What is this user trying to accomplish? A financial advisor user wants to grow wealth. A student wants to learn calculus. A PM wants to ship faster. Knowing the goal changes every response.

Expertise level: Is this user a beginner, intermediate, or expert? This changes vocabulary, depth, and the amount of explanation needed.

Role/context: What is this user’s professional context? An engineer, a manager, a founder. Context shapes what is relevant.

Communication preference: Does the user prefer brief or detailed responses? Technical or plain language? This is learnable within 3-5 interactions.

Constraints: What limitations does the user operate under? Time pressure, team size, budget, regulatory requirements. Constraints shape recommendations.

1// The minimum viable AI product stack← 3 components, not 15
2
3// 1. Foundation model (use an API, do not train your own)
4const response = await openai.chat(prompt);
5
6// 2. Self-model (the differentiation layer)
7const selfModel = await clarity.getSelfModel(userId);
8// { goal: 'scale product', expertise: 'intermediate',
9//   role: 'founder', style: 'concise', constraints: ['time'] }
10
11// 3. Personalized response (model + self-model)
12const personalizedPrompt = buildPrompt(userQuery, selfModel);
13const response = await openai.chat(personalizedPrompt);
14
15// That is it. Your AI now knows who it is talking to.

What to Skip: The Over-Engineering List

Skip custom model training. Fine-tuning a model is expensive, time-consuming, and locks you into one architecture. Foundation models through APIs are good enough for most use cases. You can always fine-tune later once you understand what customization actually matters. Most first-time teams discover they never need it.

Skip complex RAG pipelines. Retrieval-augmented generation is powerful, but the engineering cost is high. For your first product, use simple prompt engineering with relevant context injection. If users need access to specific documents, start with basic search. You can add vector databases and advanced retrieval in version 2 after you learn what users actually need to retrieve.

Skip building your own embedding model. Use an off-the-shelf embedding model. The quality difference between a custom embedding and a pre-trained one is marginal compared to the difference between a generic AI and a personalized one.

Skip multi-model orchestration. Running different models for different tasks (one for summarization, one for code generation, one for classification) adds complexity without proportional user value. Start with one model for everything. Optimize later.

Skip building analytics dashboards. You do not need a custom analytics platform on day one. Use your quality rubric, manual scoring, and a simple spreadsheet. Build the dashboard once you know what metrics actually matter.

The Build Order That Works

Here is the order I recommend based on watching fifteen teams succeed and fail:

Week 1-2: Model API + basic prompt engineering. Get the AI responding to users. Use a foundation model API. Write 5-10 prompts that cover your core use cases. Ship this immediately, even if quality is mediocre, you are now collecting data.

Week 2-4: Self-model layer. Implement persistent user understanding. Start with the onboarding flow, 3 questions that capture role, expertise, and primary goal. Store the answers and inject them into every prompt. Quality will improve noticeably.

Week 4-5: Quality baseline. Score 20 random interactions using the four-dimension rubric. You now know exactly how good (or bad) your AI is and which dimension needs the most work.

Week 5-7: Implicit learning. Add behavioral inference, learning about users from how they interact, not just what they explicitly tell you. If a user consistently asks for detailed explanations, update their depth preference. If they use technical vocabulary, infer expert-level expertise.

Week 8+: Iterate based on data. Now you have users, a self-model, and quality data. Every subsequent decision is data-informed. Should you add RAG? Your quality data will tell you if depth is the bottleneck. Should you fine-tune? Your quality data will tell you if relevance is the issue.

The Counter-Argument: But We Need Custom Infrastructure

Some teams genuinely need custom model infrastructure. If you are in one of these situations, the skip list does not fully apply:

Regulated industries with data residency requirements. If your data cannot touch third-party APIs, you may need self-hosted models from day one.

Extreme latency requirements. If you need sub-100ms responses for real-time applications, API calls may not work. But most first products do not have this requirement.

Truly novel AI capabilities. If your product requires capabilities that no foundation model provides, custom training may be necessary. But this is rarer than teams think, most novel-seeming requirements are achievable with good prompt engineering.

Even in these cases, the self-model layer should still be your priority. Custom infrastructure without user understanding produces a fast, private, unique AI that is still generic.

Trade-offs

Starting with an API means vendor dependency. You depend on the model provider’s pricing, availability, and roadmap. Mitigate by abstracting the model layer so you can switch providers with minimal code changes.

Basic self-models are imperfect. Five dimensions do not capture the full complexity of a user. But five dimensions with 70% accuracy beat zero dimensions. Start simple and add depth as you learn what matters.

Skipping RAG means limited knowledge. Your AI cannot answer questions about specific documents or proprietary data without retrieval. If your core use case requires document knowledge, build basic retrieval early, but still prioritize the self-model over the RAG pipeline.

Quality baselines require ongoing effort. Monthly scoring of 20 interactions takes time. Budget for it. The alternative, flying blind on quality, is more expensive.

What to Do Next

1. Audit your current plan. If you are building your first AI product, look at your roadmap. How much time is allocated to model infrastructure versus user understanding? If the ratio is 80/5, flip it.

2. Ship the minimum stack in 5 weeks. Foundation model API (week 1-2), self-model with 3 onboarding questions (week 2-4), quality baseline (week 4-5). You will have a personal AI product in 5 weeks, not 6 months.

3. Instrument the self-model from day one. Every interaction should contribute to user understanding. Use the self-model to shape every response. Measure fit score weekly. See how Clarity provides the self-model layer out of the box.

Skip the custom model. Ship the self-model. Your first AI product should know its users, not just process their queries. Build the minimum viable AI.

References

1. 2016 survey of 2,000 Americans by Reelgood and Learndipity Data Insights
2. Product vs. Feature Teams
3. only 1 in 26 unhappy customers actually complains
4. cold start problem
5. Qualtrics notes in their churn prediction framework

Related

• The AI Product Debug Loop
• When to Add Personalization to Your AI Product
• Three Layers of AI Personalization Architecture