Don't build AI products the way everyone else is doing it
LLM APIs have made it easy to ship “AI products,” but many commenters argue that thin wrappers around ChatGPT with no unique data, workflow, or domain insight are a dead end. They advocate starting from real user problems and traditional software design, then inserting narrow, specialized models only where AI is truly needed, while remaining wary of platform risk, latency, cost, and the temptation to over‑engineer custom toolchains too early. Others counter that quick, even derivative prototypes are still valuable for learning limits, attracting users, and iterating toward genuinely useful AI‑augmented features.
AI as Tool vs. AI as the Business
- Many argue the “real secret” is having a viable business first, then using AI to improve it (e.g., adding summarization to an existing email product).
- Others think some models are only viable because of AI-driven cost reductions, so AI-centric businesses can make sense but are riskier.
- Several comments mock generic “AI startups” as similar to saying “we’re a Python startup” or “web3 startup” with no clear problem.
Platform Risk & Wrapping OpenAI
- Strong concern that thin wrappers around OpenAI have no moat and can be undercut or cloned by OpenAI itself or by competitors.
- Some see early “API wrappers” as an acceptable learning phase and way to get experience and users, even if the first product is later disrupted.
- Emphasis that if you don’t own both the API and the customer, you’re effectively renting and can be “evicted.”
Toolchains, Fine‑tuning, and Model Choices
- Article’s advice to build specialized models plus “normal code” is broadly liked, but some think building compilers/toolchains is overkill for many teams.
- Disagreement on fine‑tuning: some see it as essential differentiation; others find it impractical due to messy data and prefer few-shot prompting, function calling, and RAG.
- Skepticism that small teams can maintain custom models as frontier models rapidly improve and potentially obsolete in-house work.
Product Strategy: Problem‑First vs Tech‑First
- Strong support for starting from user needs, workflows, and UX rather than “AI product” as a category.
- Repeated warning against building “solutions in search of a problem,” likened to previous blockchain/web3 waves.
- Some argue that building lots of quick MVPs (even tech‑driven) can still be a valid way for technologists to discover real problems.
Chatbots and User Experience
- Many dislike support chatbots, seeing them as filters that block access to empowered humans.
- Others report good experiences with certain bots (e.g., e‑commerce refunds, internal triage) and expect LLMs to significantly improve chat UX.
- Broad agreement that bots are only valuable when they can actually do things (change plans, issue refunds), not just recite FAQs—yet this collides with security and prompt‑injection concerns.
Latency, Performance, and MVP Trade‑offs
- Debate over whether multi‑minute LLM runs are acceptable: fine for background or handoff workflows, too slow for tight interactive loops.
- Some see heavy upfront engineering (custom compilers, toolchains) as premature optimization that delays learning from users; others view it as necessary to avoid commodity “boring ChatGPT wrappers.”
Data, Privacy, and Self‑Hosting
- Some enterprises reportedly refuse OpenAI-based products but will work with startups promising stronger control or on‑prem deployment.
- Others argue privacy worries are overstated given widespread enterprise use of major cloud SaaS, and that custom hosting rarely beats OpenAI on cost unless at very high scale.
Hype Cycles and Differentiation
- AI is frequently compared to past hypes like Kubernetes or blockchain; posters disagree on how transformative it will ultimately be.
- Consensus that differentiation must come from something hard to copy—deep workflow insight, data, UX, or integration—not just “we use LLMs.”