返回列表
🧠 阿头学 · 💬 讨论题 · 💰投资

Vibe Coding 2.0——MVP 极速交付的 SaaS 乐高拼装法

作者用 50+ 个 MVP 交付经验总结出一套"不造轮子"的工程决策框架：把时间从基础设施转移到核心价值，用成熟 SaaS 替换自研，是顶尖构建者的核心能力——但这套方法论本质上是为了快速交差，而非长期运营。
打开原文 ↗

2026-02-27 原文链接 ↗
阅读简报
双语对照
完整翻译
原文
讨论归档

核心观点

  • "不造轮子"是真正的竞争力 最强开发者不是代码写得最快的人，而是最清楚什么不该自己造的人。Auth、支付、部署、搜索这些领域，用户看不见也不在意你是否自己实现，却能吃掉项目 30-50% 的时间。用 Clerk、Stripe、Vercel、Algolia 替换自研，直接释放时间去做用户真正能感知的功能。
  • "可感知价值"是唯一的时间分配标准 用户会为核心功能、UX、分发付费，不会为你漂亮的认证系统或优雅的 CSS 架构付费。这意味着每个工程决策都应该问：用户能感知吗？如果答案是否，就应该用现成方案。
  • SaaS 组合的隐性成本被严重低估 文章推荐的技术栈（Vercel + Clerk + Supabase + Stripe + PostHog + UploadThing + Sentry……）看似"45 分钟集成"，但实际上是把你锁进了多重供应商依赖。一旦超过 MVP 阶段，这些服务的账单会陡增，迁移成本极高，而且你对关键基础设施失去了掌控权。
  • 经验样本的同质性决定了建议的适用范围 作者的 50+ 个 MVP 几乎都是 React/Next.js + Web SaaS 形态，这套方法论对移动原生、硬件、数据密集型、强隐私需求的产品可能完全不适用。用"顶尖 1% 构建者"这样的绝对标签来包装一套特定技术栈的推荐，存在明显的概念偷换。
  • "Day 1 就接入监控、分析、性能工具"是真正的高价值建议 这部分建议与技术栈无关，是工程习惯层面的共识：Sentry、PostHog、Lighthouse 这类工具能极大减少后期调试成本和用户流失。这是文章中最站得住脚的部分。

跟我们的关联

  • 对 ATou（独立开发者/创业者）意味着什么 时间是你唯一的真正投放预算。把基础设施外包给 Stripe、Vercel、Supabase，等于用很少的钱买"额外的技术合伙人团队"，你的时间才有机会砸在找第一个付费用户、做拉新闭环、针对真实用户行为迭代上。下一步：用这个框架做一份"禁止自造清单"，在启动新项目前强制过一遍。
  • 对 Neta（技术决策者/工程主管）意味着什么 这套框架可以直接当作团队工程文化的 Guardrails 文档，用来评估工程师是否有"勇气删掉不该造的轮子"。但要警惕：过度依赖 SaaS 会导致团队失去对关键基础设施的理解和掌控，长期来看可能削弱团队的技术深度。下一步：建立"Buy vs. Build 决策矩阵"，明确哪些领域禁止自研、哪些领域必须掌握。
  • 对 Uota（产品/增长）意味着什么 这直接改写了你评估工程进度的标准：不再问"技术实现有多复杂"，而是问"团队有多少时间花在了用户看不见的基础设施上"。如果工程师的时间没花在可见体验和关键路径上，那就是方向错了。下一步：和技术团队一起过一遍"用户真正能感知的价值清单"，用它来做优先级排序。
  • 对投资决策意味着什么 这套方法论的本质是"用 SaaS 购买速度"，对需要快速验证商业假设的早期创业公司极其有利。但投资人应该警惕：创始人如果过度依赖这套"快速交付"模式，可能会忽视长期的技术债、供应商锁定风险和成本控制。下一步：在尽调时问创始人"你的关键基础设施有多少是自研的、有多少是外包的"，以及"如果主要 SaaS 供应商涨价 10 倍，你的商业模式还能活吗"。

讨论引子

  • 在什么情况下，"自己造轮子"反而是正确的决策？是否存在某些领域（如支付、认证、搜索），即使有成熟 SaaS 方案，自研仍然值得投入？
  • 这套"SaaS 乐高拼装"模式在产品超过 MVP 阶段后会面临什么样的成本爆炸和迁移困境？如何在早期快速交付和长期可演进性之间找到平衡？
  • 作者强调"顶尖 1% 构建者"的核心能力是"知道什么不该自己造"，但这是否忽视了另一种顶尖能力——深度掌握某个领域的技术细节（如数据库优化、实时系统、支付合规）？两种能力的权衡标准是什么？

大多数人把本该用几周做完的东西，耗成了几个月。

不是因为他们是差劲的开发者。也不是因为他们选错了点子。

而是因为他们在当下做了看似正确的决定，却在产品上线之前就把自己埋进了技术债。

我为美国、印度、迪拜和澳大利亚的客户交付过 50+ 个 MVP。我见过这个模式一次又一次地重复出现。

很多聪明、有动力、也有能力的创始人……在一件本该 3 周就上线的事情上死磕 3 个月。

这篇文章，就是我真希望早些年有人递给我的那份清单。

不是理论。不是那些“应该”如何的说法。而是当你要快速构建、独自构建、并且以交付上线为目标时，真正行之有效的做法。

为什么 Vibe Coder 会失败（原因并不是你以为的那样）

错的不是代码。

错的是写代码之前做出的决定。

你每花 1 小时从零造 auth（认证），就少花 1 小时去做那个真正让产品值得使用的核心功能。每当你为一个 shadcn/ui 5 分钟就能解决的东西去写原生 CSS，你不是在构建，你是在原地耗着。

Vibe 编程只有在你愿意信任现成工具时才奏效。

我认识最厉害的 Vibe Coder，并不是懂得最多的人，而是最清楚什么不该自己造的人。

下面把两面都完整拆开讲清楚。

第一部分：要做的事（真正帮你省时间的）

  1. 使用现成的 Auth

别再从零开始造认证系统了。到此为止。

Clerk 和 Supabase Auth 正是为此而生：它们在你写一个基础登录表单的时间里，就能把会话、token、OAuth 提供方、安全边界情况，以及移动端兼容性统统处理好。

我见过一些创始人，在一个还没验证过的 MVP 上花两周做 auth。这两周都在造一件用户既看不见、也不会在意的东西。

用 Clerk。用 Supabase Auth。然后继续往前走。

  1. 用 Tailwind 和 shadcn/ui 做 UI

这一条最稳定、也最能帮你省时间。

Tailwind 给你一套约束系统。shadcn/ui 给你可直接用于生产的组件。两者结合，你几乎不需要从零设计，就能做出看起来像回事的界面。

这里的 ROI 高得离谱。我用这套组合，能在 2–3 小时内从 Figma 走到可用的 UI；没有它，至少得整整一天。

额外收益：界面风格会更一致。不再有随手写的尺寸、不一致的颜色，也不用凌晨 1 点靠肉眼去对像素。

  1. 用 Zustand 和 Server Components 管状态

过度工程化的状态管理，是项目最容易“死”掉的地方。

Zustand 能干净利落地处理客户端状态；剩下的交给 Server Components。你不需要 Redux，也不需要套六层的 Context wrapper。一个只有 12 个用户的产品，不需要你拿出状态架构博士论文。

简单一点。先上线。

  1. 用 tRPC 和 Server Actions 做 API

如果你在 MVP 阶段就从零写自定义的 REST API，你做的工作远远超过了必要的程度。

tRPC 提供端到端的类型安全，几乎没有配置开销。Server Actions 则能干净地处理表单 mutation 与数据更新。两者组合，可以直接干掉过去要耗上好几天的那一整层样板代码。

  1. 用 Vercel 一键部署

手动部署是个效率陷阱。

你花在配置服务器、管理 SSH key、调试部署脚本上的时间，都不是在做你的产品。Vercel 把这些全都带走：推送到 main，一切搞定。

你的精力，比服务器配置更值钱。

  1. 用 Prisma 和托管 Postgres

在做 MVP 时到处写原生 SQL，就是一个红旗信号。

Prisma 给你一个带类型的 ORM：建 schema 方便、做迁移方便、阅读也舒服。托管的 Postgres（Supabase、Neon、Railway）则意味着你不必自己运维服务器。

这套组合能干净、顺滑地覆盖任何 MVP 95% 的需求。

  1. 用 Zod 和 React Hook Form 做校验

表单校验看起来简单，但如果工具没选对，很快就会变成噩梦。

Zod 负责 schema 校验。React Hook Form 负责表单状态。它们一起让表单变得可预测、可信赖。没有校验的输入，会把脏数据写进数据库，然后让你在凌晨 2 点面对愤怒的用户。

  1. 用 Stripe 做支付

永远不要自己造支付系统。一次都不要。

Stripe 能处理支付、订阅、退款、争议处理、合规以及 webhooks。自己去造其中任何一块，不仅耗时，更是危险：一个合规问题就能把你直接按死。

用 Stripe。集成 45 分钟就能跑起来，而且真的能用。

  1. 尽早接入 Sentry 或错误追踪

这是多数人会跳过、也最容易后悔的一件事。

当你的应用在生产环境崩了（它一定会崩），你需要第一时间知道；而不是等用户在推特上艾特你，也不是等你自己偶然踩到那个 bug。

Sentry 会告诉你：到底哪里坏了、坏在什么位置、发生了多少次。第一天就把它配好。起步成本为零。

  1. 从一开始就把数据分析装上

PostHog 或 Plausible。二选一；在上线前就把它配好。

如果你不知道用户如何在产品里流转，你就是在猜。早期靠猜来做产品决策，最容易让你连续三个月都在做错的东西。

你需要数据。早点埋点，这样等你需要时，它才真的已经有数据了。

  1. 把密钥放进环境变量文件

把 API key 写死在代码里，是那种事后看起来很蠢、当下却足以致命的错误。

用 .env 文件，把它们加入 .gitignore。生产环境用 Doppler 之类的服务，或 Vercel 自带的环境变量管理器。绝不要把任何 secret 提交到版本控制里——一次都不要。

  1. 用 UploadThing 或 Cloudinary 处理文件

文件上传看似简单，直到你要自己管理存储、CDN 分发、文件大小限制，以及权限安全。

UploadThing 能一口气处理这些。需要 transformation 的话，Cloudinary 也能搞定。一个下午集成完，继续往下做。

  1. 配好预览部署

每个 PR 都应该有一个预览 URL。

Vercel 会自动做到这一点，让你（以及客户）在变更进入生产之前先测试。它能防止你把坏掉的 UI 发到真实用户手上，并在半夜不得不紧急回滚。

  1. 用 Radix、shadcn 这类组件库

从零写 UI 组件又慢又不一致。

Radix 提供不带样式、但可访问性完备、可用于生产的基础组件原语。shadcn 在其之上做了现成的样式封装。两者结合，你几乎可以做出任何 UI 模式，而不用重复造轮子。

  1. 第一天就写 README

你以为你会记得一切是怎么运作的。你不会。

一份简单的 README：怎么跑项目、有哪些环境变量、做过哪些关键决策——三周后能为你省下好几个小时的迷茫。它也会让交付给客户的交接变得顺滑得多。

花 20 分钟。省 4 小时。

  1. 保持目录干净、模块化

混乱的目录结构不是小问题，它会不断叠加恶化。

每往一坨乱代码里加一个功能，你会有 30% 的时间花在“找东西”上。清爽、模块化的结构，能让你给别人做 onboarding，或者三周后回来的自己重新上手时，都几乎没有摩擦。

Components、hooks、utils、types。保持可预期。

  1. 加上引导流程和空状态

这是你能做的、最被低估的一项 UX 投资。

空状态（empty states）告诉用户在没有内容时该做什么；onboarding 告诉他们第一天如何获得价值。没有这些，用户进入你的应用后根本不知道下一步该干什么。

困惑的用户不会转化，只会离开。

  1. 用 Lighthouse 和性能工具

性能不是“有更好”的加分项。

慢应用会失去用户。Lighthouse（Chrome DevTools 内置）能在 30 秒内给你一份免费的性能审计。低于 70 分就是红旗；在上线前修，而不是等用户因为卡顿离开后再修。

第二部分：别做的事（最消耗你时间和精力的）

不要从零开始造 Auth

上面已经讲过了，但值得再说一遍。

这是我在几乎所有第一次做 vibe coding 的人身上看到的 #1 时间杀手。安全复杂性、边界情况和维护开销叠加，让它成为早期最不该投入项目工时的地方。

不要为所有东西都写原生 CSS

原生 CSS 不是美德，而是一种负债。

除非你有非常明确的设计系统需求，否则在 2026 年你就不该到处写原生 CSS。Tailwind 能更快、更一致地覆盖你 99% 的需求。

别人都给你造好了“画画机器”，别还伸手去拿画笔。

不要过度工程化状态管理

如果你在做 MVP 时就想上 Redux 或复杂的 Context 模式，先问问自己：为什么？

大多数早期应用只需要简单状态。Zustand 能搞定。服务端状态呢？React Query 或 Server Components。就这些。

在你拥有 10 个用户之前，别先给 1000 万用户设计架构。

不要过早自建 API

从零写 REST API，会在你验证任何东西之前就额外多出好几周的工作量。

先用 tRPC 或 Server Actions。真到了长大到不够用的时候，再在真实数据告诉你“为什么要迁移”的前提下去迁移。别为一个 0 用户的产品，先把整套 API 基建搭起来。

不要手动部署

手动部署会引入人为错误、耗时，而且无法扩展。

每次手动部署，你都离“把生产环境弄挂”只差一个失误。第一天就把它自动化。Vercel、Railway、Render……它们都有 push-to-deploy。用起来。

不要到处写原生 SQL

除非你有非常明确的性能需求（你的 MVP 没有），否则没有理由跳过 ORM。

原生 SQL 更难维护、更难重构，也更容易在安全敏感的地方写错。Prisma 就在那儿。用它。

不要自己造支付系统

这一点怎么强调都不为过：自己造支付系统不是炫技，而是负担。

光 PCI 合规就要折腾几个月。Stripe 能处理。花 45 分钟集成，然后继续往下做。

不要自己造搜索引擎

Algolia、Typesense、Meilisearch。它们做搜索都比你在有限时间里能做出来的更好。

全文检索难得很隐蔽。边界情况、排序、拼写容错、负载下的性能——没有一项是“顺手一写”就能做好的。能把这些做好的人背后是一整个团队，已经做了很多年。

交给它们。

不要跳过日志与监控

没有监控就发版，就像闭着眼开车。

你只会在用户告诉你时才知道哪里坏了。到那时，你很可能已经失去了一批连反馈都懒得提的用户。

Sentry、LogRocket，甚至 Axiom。挑一个。上线前就配好。

不要把 API Key 写死在代码里

一旦 key 进了版本控制，你就暴露了。到此为止。

GitHub 会自动扫描公开仓库里暴露的 secrets，并通知像 AWS 这样的服务商，然后它们会把 key 直接吊销。确实发生过：有开发者因此失去了好几个月的基础设施访问权限。

永远用环境变量。

不要 DIY 文件上传

看起来很简单。其实不是。

存储管理、CDN 配置、文件类型校验、大小限制、安全权限……UploadThing 和 Cloudinary 一次集成就能解决。DIY 版本会以你想不到的方式在生产环境出问题。

不要直接推到 Main

一次糟糕的 push 到 main，就可能让真实用户的生产环境直接出故障。

用 feature branch。配好预览部署。即使你是一个人，养成合并到 main 前先审一遍自己代码的习惯，也能帮你捕捉到比你想象中更多的 bug。

不要一个人硬造实时系统

Realtime 很难。Websockets、在线状态（presence）、冲突解决……它们的复杂度远远超过表面看起来的样子。

Supabase Realtime、Pusher、Partykit。这些服务之所以存在，就是因为从零搭实时基础设施本质上是一份全职工作。别把它塞进你的 MVP 里。

不要忽视性能

一个慢应用，就是一个正在走向死亡的应用。2026 年的用户对加载时间没有耐心。

Lighthouse 30 秒就能告诉你分数。分数差就别拖：上线前先把最大的问题修掉。没优化的图片、过大的 JS bundle、阻塞渲染路径通常是罪魁祸首，而且都能修。

不要假设用户会自己摸索明白

你的产品对你来说很直观；对别人来说，没引导就不会直观。

加 onboarding。第一次使用时加 tooltips。写清楚空状态，让用户知道下一步该做什么。能留住用户的产品，往往是在最开始的 5 分钟里牵着用户走的产品。

不要无限期推迟重构

早期有技术债没问题；但放任不管，它会不断复利，最后变成你再也快不起来的代码库。

定个固定节奏。每做完 2–3 个功能，就抽一段时间把你制造的混乱清一清。未来的你会感谢现在的你。

不要靠记忆做决策

把你的决策写下来。

为什么选这个库？为什么数据库这样设计？你做了什么取舍？写下来。未来的你、你的客户，以及未来加入项目的开发者都会感谢你。

不要在上线前追求完美

这一条会让你浪费的时间，比其他所有条加起来还多。

MVP 的目标不是完美；目标是学习。每一次，带着瑕疵但上线的产品，都胜过精致却永远不发布的产品。

专注。上线。迭代。

这一切背后的真正规律

这份清单里的每一点，归根结底都指向一件事。

知道把精力花在哪里。

最好的 Vibe Coder 并不是写代码更强，而是更擅长识别哪些东西不该自己造。他们对哪些决策可逆、哪些会让自己付出数周代价，有很强的直觉。

用工具。信任生态。快速上线。从真实用户那里学习。

别再从零开始造别人已经做得更好的东西。

你省下来的时间，应该投到真正重要的部分：功能、UX、分发，以及那个让人脱口而出“我需要这个”的东西。

真正的工作在那里。

我花了 3 年，用最痛的方式学会这些。你不必如此。

如果你在做第一个或第五个 MVP，想看看我们如何把这些原则应用到客户项目里，我的 cal.com 在个人简介里。第一次通话永远只是为了理解你的问题，不做别的。

链接：http://x.com/i/article/2025145098120691716

Most people waste months building things that should have taken weeks.

Not because they're bad developers. Not because they picked the wrong idea.

Because they made decisions that felt right in the moment but buried them in technical debt before they even shipped.

I've shipped 50+ MVPs for clients across the US, India, Dubai, and Australia. I've seen this pattern repeat itself over and over again.

Founders who are smart, motivated, and capable... grinding for 3 months on something that should have been live in 3 weeks.

This article is everything I wish someone had handed me early on.

Not theory. Not what "should" work. What actually works when you're building fast, building alone, and building to ship.

大多数人把本该用几周做完的东西，耗成了几个月。

不是因为他们是差劲的开发者。也不是因为他们选错了点子。

而是因为他们在当下做了看似正确的决定，却在产品上线之前就把自己埋进了技术债。

我为美国、印度、迪拜和澳大利亚的客户交付过 50+ 个 MVP。我见过这个模式一次又一次地重复出现。

很多聪明、有动力、也有能力的创始人……在一件本该 3 周就上线的事情上死磕 3 个月。

这篇文章，就是我真希望早些年有人递给我的那份清单。

不是理论。不是那些“应该”如何的说法。而是当你要快速构建、独自构建、并且以交付上线为目标时，真正行之有效的做法。

Why Vibe Coders Fail (And It's Not What You Think)

The mistake isn't the code.

The mistake is the decision made before the code.

Every hour you spend building auth from scratch is an hour you didn't spend on the one feature that actually makes your product worth using. Every time you write raw CSS for something shadcn/ui could solve in 5 minutes, you're not building. You're stalling.

Vibe coding only works when you trust the tools that already exist.

The best vibe coders I know aren't the ones who know the most. They're the ones who know what NOT to build.

Here's the complete breakdown of both sides.

为什么 Vibe Coder 会失败（原因并不是你以为的那样）

错的不是代码。

错的是写代码之前做出的决定。

你每花 1 小时从零造 auth（认证），就少花 1 小时去做那个真正让产品值得使用的核心功能。每当你为一个 shadcn/ui 5 分钟就能解决的东西去写原生 CSS，你不是在构建，你是在原地耗着。

Vibe 编程只有在你愿意信任现成工具时才奏效。

我认识最厉害的 Vibe Coder，并不是懂得最多的人，而是最清楚什么不该自己造的人。

下面把两面都完整拆开讲清楚。

Part 1 : The DO's (What Actually Saves You Time)

  1. Use Ready-Made Auth

Stop building authentication from scratch. Full stop.

Clerk and Supabase Auth exist for exactly this reason. They handle sessions, tokens, OAuth providers, security edge cases, and mobile compatibility, all of it, in the time it would take you to write a basic login form.

I've seen founders spend 2 weeks on auth for an MVP nobody has validated yet. That's 2 weeks of building the one thing users will never see or care about.

Use Clerk. Use Supabase Auth. Move on.

  1. Use Tailwind and shadcn/ui for UI

This one saves you the most time, consistently.

Tailwind gives you a constraint system. shadcn/ui gives you production-ready components. Together, they let you build UIs that look legitimate without designing anything from scratch.

The ROI here is insane. I've gone from Figma to working UI in 2-3 hours using this combo. Without it, that's a full day minimum.

Bonus: your UI stays consistent. No random sizing, no colour inconsistencies, no eyeballing pixel values at 1am.

  1. Use Zustand and Server Components for State

Over-engineered state management is where projects go to die.

Zustand handles client-side state cleanly. Server Components handle the rest. You don't need Redux. You don't need Context wrappers 6 layers deep. You don't need a PhD in state architecture for a product that has 12 users.

Keep it simple. Ship.

  1. Use tRPC and Server Actions for APIs

If you're building custom REST APIs from scratch for your MVP, you're doing way more work than you need to.

tRPC gives you end-to-end type safety without configuration overhead. Server Actions handle form mutations and data updates cleanly. Together, they eliminate an entire layer of boilerplate that used to eat up days.

  1. Deploy with Vercel One-Click

Manual deployments are a productivity trap.

The time you spend configuring servers, managing SSH keys, and debugging deployment scripts is time not spent on your actual product. Vercel takes all of that away. One push to main, done.

Your energy is worth more than your server config.

  1. Use Prisma and Managed Postgres

Writing raw SQL for an MVP is a red flag.

Prisma gives you a typed ORM that's easy to schema with, easy to migrate with, and easy to read. Managed Postgres (Supabase, Neon, Railway) means no server management.

This combo handles 95% of what any MVP needs, cleanly, without friction.

  1. Validate with Zod and React Hook Form

Form validation is one of those things that looks simple and turns into a nightmare if you don't have the right tools.

Zod handles schema validation. React Hook Form handles form state. Together, they make forms predictable and trustworthy. Unvalidated inputs is how you get broken data in your database and angry users at 2am.

  1. Use Stripe for Payments

Never build your own payment system. Not once, not ever.

Stripe handles payments, subscriptions, refunds, disputes, compliance, and webhooks. Building any of this yourself is not just time-consuming, it's dangerous. One compliance issue and you're done.

Use Stripe. It takes 45 minutes to integrate and it works.

  1. Add Sentry or Error Tracking Early

This is the one most people skip and regret the most.

When your app breaks in production (and it will), you need to know immediately. Not when a user tweets at you. Not when you accidentally stumble on the bug yourself.

Sentry tells you exactly what broke, exactly where, and exactly how often. Set it up on day one. It costs nothing to start.

  1. Set Up Analytics From the Beginning

PostHog or Plausible. Pick one. Set it up before launch.

If you don't know how users are moving through your product, you're guessing. And guessing about product decisions at an early stage is how you build the wrong thing for 3 months.

You need data. Set it up early so it actually has data when you need it.

  1. Store Secrets in Environment Files

Hardcoding API keys is one of those mistakes that's obvious in hindsight and catastrophic in the moment.

Use .env files. Add them to .gitignore. Use a service like Doppler or Vercel's built-in environment manager for production. Never commit a secret to version control. Not once.

  1. Use UploadThing or Cloudinary for Files

File uploads seem simple until you're managing storage, CDN delivery, file size limits, and security permissions yourself.

UploadThing handles all of it. Cloudinary handles transformations too if you need them. Integrate in an afternoon, move on.

  1. Set Up Preview Deployments

Every PR should have a preview URL.

Vercel does this automatically. It lets you (and clients) test changes before they hit production. This saves you from shipping broken UI to real users and having to do emergency rollbacks at midnight.

  1. Use Component Libraries Like Radix and shadcn

Building UI components from scratch is slow and inconsistent.

Radix gives you unstyled, accessible, production-grade primitives. shadcn builds on top of them with styling already applied. Between the two, you can build almost any UI pattern without reinventing the wheel.

  1. Write a README From Day 1

You think you'll remember how everything works. You won't.

A simple README with how to run the project, what the environment variables are, and what the core decisions were saves you hours of confusion 3 weeks later. It also makes handoffs to clients infinitely smoother.

Takes 20 minutes. Saves 4 hours.

  1. Keep Folders Clean and Modular

Messy folder structure isn't a small problem. It compounds.

Every time you add a feature to a messy codebase, you spend 30% of your time just navigating. Clean, modular structure means you can onboard someone else, or your future self after 3 weeks away, without friction.

Components, hooks, utils, types. Keep it predictable.

  1. Add Onboarding and Empty States

This is the most underrated UX investment you can make.

Empty states tell users what to do when there's no content. Onboarding tells them how to get value on day one. Without these, users land in your app and have no idea what to do next.

Confused users don't convert. They leave.

  1. Use Lighthouse and Performance Tools

Performance isn't a nice-to-have.

Slow apps lose users. Lighthouse (built into Chrome DevTools) gives you a free performance audit in 30 seconds. A score below 70 is a red flag. Fix it before launch, not after you've lost users to it.

第一部分：要做的事（真正帮你省时间的）

  1. 使用现成的 Auth

别再从零开始造认证系统了。到此为止。

Clerk 和 Supabase Auth 正是为此而生：它们在你写一个基础登录表单的时间里，就能把会话、token、OAuth 提供方、安全边界情况，以及移动端兼容性统统处理好。

我见过一些创始人，在一个还没验证过的 MVP 上花两周做 auth。这两周都在造一件用户既看不见、也不会在意的东西。

用 Clerk。用 Supabase Auth。然后继续往前走。

  1. 用 Tailwind 和 shadcn/ui 做 UI

这一条最稳定、也最能帮你省时间。

Tailwind 给你一套约束系统。shadcn/ui 给你可直接用于生产的组件。两者结合，你几乎不需要从零设计，就能做出看起来像回事的界面。

这里的 ROI 高得离谱。我用这套组合，能在 2–3 小时内从 Figma 走到可用的 UI；没有它，至少得整整一天。

额外收益：界面风格会更一致。不再有随手写的尺寸、不一致的颜色，也不用凌晨 1 点靠肉眼去对像素。

  1. 用 Zustand 和 Server Components 管状态

过度工程化的状态管理，是项目最容易“死”掉的地方。

Zustand 能干净利落地处理客户端状态；剩下的交给 Server Components。你不需要 Redux，也不需要套六层的 Context wrapper。一个只有 12 个用户的产品，不需要你拿出状态架构博士论文。

简单一点。先上线。

  1. 用 tRPC 和 Server Actions 做 API

如果你在 MVP 阶段就从零写自定义的 REST API，你做的工作远远超过了必要的程度。

tRPC 提供端到端的类型安全，几乎没有配置开销。Server Actions 则能干净地处理表单 mutation 与数据更新。两者组合，可以直接干掉过去要耗上好几天的那一整层样板代码。

  1. 用 Vercel 一键部署

手动部署是个效率陷阱。

你花在配置服务器、管理 SSH key、调试部署脚本上的时间，都不是在做你的产品。Vercel 把这些全都带走：推送到 main，一切搞定。

你的精力，比服务器配置更值钱。

  1. 用 Prisma 和托管 Postgres

在做 MVP 时到处写原生 SQL，就是一个红旗信号。

Prisma 给你一个带类型的 ORM：建 schema 方便、做迁移方便、阅读也舒服。托管的 Postgres（Supabase、Neon、Railway）则意味着你不必自己运维服务器。

这套组合能干净、顺滑地覆盖任何 MVP 95% 的需求。

  1. 用 Zod 和 React Hook Form 做校验

表单校验看起来简单，但如果工具没选对，很快就会变成噩梦。

Zod 负责 schema 校验。React Hook Form 负责表单状态。它们一起让表单变得可预测、可信赖。没有校验的输入，会把脏数据写进数据库，然后让你在凌晨 2 点面对愤怒的用户。

  1. 用 Stripe 做支付

永远不要自己造支付系统。一次都不要。

Stripe 能处理支付、订阅、退款、争议处理、合规以及 webhooks。自己去造其中任何一块，不仅耗时，更是危险：一个合规问题就能把你直接按死。

用 Stripe。集成 45 分钟就能跑起来，而且真的能用。

  1. 尽早接入 Sentry 或错误追踪

这是多数人会跳过、也最容易后悔的一件事。

当你的应用在生产环境崩了（它一定会崩），你需要第一时间知道；而不是等用户在推特上艾特你，也不是等你自己偶然踩到那个 bug。

Sentry 会告诉你：到底哪里坏了、坏在什么位置、发生了多少次。第一天就把它配好。起步成本为零。

  1. 从一开始就把数据分析装上

PostHog 或 Plausible。二选一；在上线前就把它配好。

如果你不知道用户如何在产品里流转，你就是在猜。早期靠猜来做产品决策，最容易让你连续三个月都在做错的东西。

你需要数据。早点埋点，这样等你需要时，它才真的已经有数据了。

  1. 把密钥放进环境变量文件

把 API key 写死在代码里，是那种事后看起来很蠢、当下却足以致命的错误。

用 .env 文件，把它们加入 .gitignore。生产环境用 Doppler 之类的服务，或 Vercel 自带的环境变量管理器。绝不要把任何 secret 提交到版本控制里——一次都不要。

  1. 用 UploadThing 或 Cloudinary 处理文件

文件上传看似简单，直到你要自己管理存储、CDN 分发、文件大小限制，以及权限安全。

UploadThing 能一口气处理这些。需要 transformation 的话，Cloudinary 也能搞定。一个下午集成完，继续往下做。

  1. 配好预览部署

每个 PR 都应该有一个预览 URL。

Vercel 会自动做到这一点，让你（以及客户）在变更进入生产之前先测试。它能防止你把坏掉的 UI 发到真实用户手上，并在半夜不得不紧急回滚。

  1. 用 Radix、shadcn 这类组件库

从零写 UI 组件又慢又不一致。

Radix 提供不带样式、但可访问性完备、可用于生产的基础组件原语。shadcn 在其之上做了现成的样式封装。两者结合，你几乎可以做出任何 UI 模式，而不用重复造轮子。

  1. 第一天就写 README

你以为你会记得一切是怎么运作的。你不会。

一份简单的 README：怎么跑项目、有哪些环境变量、做过哪些关键决策——三周后能为你省下好几个小时的迷茫。它也会让交付给客户的交接变得顺滑得多。

花 20 分钟。省 4 小时。

  1. 保持目录干净、模块化

混乱的目录结构不是小问题，它会不断叠加恶化。

每往一坨乱代码里加一个功能，你会有 30% 的时间花在“找东西”上。清爽、模块化的结构，能让你给别人做 onboarding，或者三周后回来的自己重新上手时，都几乎没有摩擦。

Components、hooks、utils、types。保持可预期。

  1. 加上引导流程和空状态

这是你能做的、最被低估的一项 UX 投资。

空状态（empty states）告诉用户在没有内容时该做什么；onboarding 告诉他们第一天如何获得价值。没有这些，用户进入你的应用后根本不知道下一步该干什么。

困惑的用户不会转化，只会离开。

  1. 用 Lighthouse 和性能工具

性能不是“有更好”的加分项。

慢应用会失去用户。Lighthouse（Chrome DevTools 内置）能在 30 秒内给你一份免费的性能审计。低于 70 分就是红旗；在上线前修，而不是等用户因为卡顿离开后再修。

Part 2 : The DON'Ts (What Burns Your Time and Energy)

Don't Build Auth From Scratch

Already covered above, but it deserves repeating.

This is the #1 time killer I see across almost every first-time vibe coder. The combination of security complexity, edge cases, and maintenance overhead makes it the worst possible place to spend early project hours.

Don't Write Raw CSS for Everything

Raw CSS is not a virtue. It's a liability.

Unless you have a very specific design system requirement, you should not be writing raw CSS in 2026. Tailwind covers 99% of what you need, faster and with more consistency.

Stop reaching for a paintbrush when someone already built you a painting machine.

Don't Over-Engineer State Management

If you're reaching for Redux or complex Context patterns for an MVP, ask yourself why.

Most early-stage apps need simple state. Zustand handles it. Server state? React Query or Server Components. That's it.

Don't build an architecture for 10 million users before you have 10.

Don't Build Custom APIs Too Early

REST APIs from scratch add weeks of work before you've validated anything.

Start with tRPC or Server Actions. If you outgrow them, migrate later with actual data telling you why. Don't build a full API infrastructure for a product with 0 users.

Don't Deploy Manually

Manual deployments introduce human error, take time, and don't scale.

Every time you manually deploy, you're one mistake away from breaking production. Automate it from day one. Vercel, Railway, Render, all of them have push-to-deploy. Use it.

Don't Write Raw SQL Everywhere

Unless you have very specific performance requirements (which your MVP doesn't), there's no reason to skip an ORM.

Raw SQL is harder to maintain, harder to refactor, and easier to get wrong in security-sensitive ways. Prisma exists. Use it.

Don't Build Your Own Payment System

This cannot be overstated. Building your own payment system is not a flex. Its a liability.

PCI compliance alone is months of work. Stripe handles it. Spend the 45 minutes to integrate and move on.

Don't Roll Your Own Search Engine

Algolia, Typesense, Meilisearch. All of them solve search better than you'll build it in the time you have.

Full-text search is deceptively hard. Edge cases, ranking, typo tolerance, performance under load. None of this is trivial to build. The services that do it have teams of people who've worked on it for years.

Let them.

Don't Skip Logging and Monitoring

Shipping without monitoring is like driving with your eyes closed.

You'll only find out something broke when a user tells you. By then, you've probably already lost users who didn't bother to report it.

Sentry, LogRocket, or even Axiom. Pick one. Set it up before launch.

Don't Hardcode API Keys

If your keys end up in version control, you're exposed. Full stop.

GitHub automatically scans public repos for exposed secrets and notifies services like AWS, who then revoke the keys. This has happened to developers who lost access to months of infrastructure.

Use environment variables. Always.

Don't DIY File Uploads

It seems simple. It's not.

Storage management, CDN configuration, file type validation, size limits, security. UploadThing and Cloudinary solve all of this in one integration. The DIY version breaks in production in ways you won't predict.

Don't Push Straight to Main

A single bad push to main can break production for real users.

Use feature branches. Set up preview deployments. Even if you're solo, the habit of reviewing your own code before merging it to main catches more bugs than you'd expect.

Don't Build Realtime Systems Alone

Realtime is hard. Websockets, presence indicators, conflict resolution, they're all significantly more complex than they look.

Supabase Realtime, Pusher, Partykit. These services exist specifically because building realtime infrastructure from scratch is a full-time project. Don't do it for an MVP.

Don't Ignore Performance

A slow app is a dying app. Users have no patience for load times in 2026.

Lighthouse tells you your score in 30 seconds. If it's bad, fix the biggest issues before launch. Unoptimized images, large JS bundles, and blocking render paths are usually the culprits and they're all fixable.

Don't Assume Users Will Figure It Out

Your product makes sense to you. It won't make sense to anyone else without guidance.

Add onboarding. Add tooltips on first use. Write empty states that tell users what to do next. The products that retain users are the ones that hold their hand through the first 5 minutes.

Don't Postpone Refactoring Forever

Technical debt is fine early. Left unchecked, it compounds into a codebase you can't move fast in.

Set a regular schedule. After every 2-3 features, spend a session cleaning up the mess you made. Future you will be grateful.

Don't Rely on Memory for Decisions

Document your decisions.

Why did you pick this library? Why did you structure the database this way? What was the tradeoff you made? Write it down. Future you, your client, and any future developer on the project will thank you.

Don't Chase Perfect Before Shipping

This one will cost you more time than all the others combined.

The goal of an MVP is not to be perfect. The goal is to learn. Shipped and imperfect beats polished and never launched every single time.

Lock in. Ship. Iterate.

第二部分：别做的事（最消耗你时间和精力的）

不要从零开始造 Auth

上面已经讲过了，但值得再说一遍。

这是我在几乎所有第一次做 vibe coding 的人身上看到的 #1 时间杀手。安全复杂性、边界情况和维护开销叠加，让它成为早期最不该投入项目工时的地方。

不要为所有东西都写原生 CSS

原生 CSS 不是美德，而是一种负债。

除非你有非常明确的设计系统需求，否则在 2026 年你就不该到处写原生 CSS。Tailwind 能更快、更一致地覆盖你 99% 的需求。

别人都给你造好了“画画机器”，别还伸手去拿画笔。

不要过度工程化状态管理

如果你在做 MVP 时就想上 Redux 或复杂的 Context 模式，先问问自己：为什么？

大多数早期应用只需要简单状态。Zustand 能搞定。服务端状态呢？React Query 或 Server Components。就这些。

在你拥有 10 个用户之前，别先给 1000 万用户设计架构。

不要过早自建 API

从零写 REST API，会在你验证任何东西之前就额外多出好几周的工作量。

先用 tRPC 或 Server Actions。真到了长大到不够用的时候，再在真实数据告诉你“为什么要迁移”的前提下去迁移。别为一个 0 用户的产品，先把整套 API 基建搭起来。

不要手动部署

手动部署会引入人为错误、耗时，而且无法扩展。

每次手动部署，你都离“把生产环境弄挂”只差一个失误。第一天就把它自动化。Vercel、Railway、Render……它们都有 push-to-deploy。用起来。

不要到处写原生 SQL

除非你有非常明确的性能需求（你的 MVP 没有），否则没有理由跳过 ORM。

原生 SQL 更难维护、更难重构，也更容易在安全敏感的地方写错。Prisma 就在那儿。用它。

不要自己造支付系统

这一点怎么强调都不为过：自己造支付系统不是炫技，而是负担。

光 PCI 合规就要折腾几个月。Stripe 能处理。花 45 分钟集成，然后继续往下做。

不要自己造搜索引擎

Algolia、Typesense、Meilisearch。它们做搜索都比你在有限时间里能做出来的更好。

全文检索难得很隐蔽。边界情况、排序、拼写容错、负载下的性能——没有一项是“顺手一写”就能做好的。能把这些做好的人背后是一整个团队，已经做了很多年。

交给它们。

不要跳过日志与监控

没有监控就发版，就像闭着眼开车。

你只会在用户告诉你时才知道哪里坏了。到那时，你很可能已经失去了一批连反馈都懒得提的用户。

Sentry、LogRocket，甚至 Axiom。挑一个。上线前就配好。

不要把 API Key 写死在代码里

一旦 key 进了版本控制，你就暴露了。到此为止。

GitHub 会自动扫描公开仓库里暴露的 secrets，并通知像 AWS 这样的服务商，然后它们会把 key 直接吊销。确实发生过：有开发者因此失去了好几个月的基础设施访问权限。

永远用环境变量。

不要 DIY 文件上传

看起来很简单。其实不是。

存储管理、CDN 配置、文件类型校验、大小限制、安全权限……UploadThing 和 Cloudinary 一次集成就能解决。DIY 版本会以你想不到的方式在生产环境出问题。

不要直接推到 Main

一次糟糕的 push 到 main，就可能让真实用户的生产环境直接出故障。

用 feature branch。配好预览部署。即使你是一个人，养成合并到 main 前先审一遍自己代码的习惯，也能帮你捕捉到比你想象中更多的 bug。

不要一个人硬造实时系统

Realtime 很难。Websockets、在线状态（presence）、冲突解决……它们的复杂度远远超过表面看起来的样子。

Supabase Realtime、Pusher、Partykit。这些服务之所以存在，就是因为从零搭实时基础设施本质上是一份全职工作。别把它塞进你的 MVP 里。

不要忽视性能

一个慢应用，就是一个正在走向死亡的应用。2026 年的用户对加载时间没有耐心。

Lighthouse 30 秒就能告诉你分数。分数差就别拖：上线前先把最大的问题修掉。没优化的图片、过大的 JS bundle、阻塞渲染路径通常是罪魁祸首，而且都能修。

不要假设用户会自己摸索明白

你的产品对你来说很直观；对别人来说，没引导就不会直观。

加 onboarding。第一次使用时加 tooltips。写清楚空状态，让用户知道下一步该做什么。能留住用户的产品，往往是在最开始的 5 分钟里牵着用户走的产品。

不要无限期推迟重构

早期有技术债没问题；但放任不管，它会不断复利，最后变成你再也快不起来的代码库。

定个固定节奏。每做完 2–3 个功能，就抽一段时间把你制造的混乱清一清。未来的你会感谢现在的你。

不要靠记忆做决策

把你的决策写下来。

为什么选这个库？为什么数据库这样设计？你做了什么取舍？写下来。未来的你、你的客户，以及未来加入项目的开发者都会感谢你。

不要在上线前追求完美

这一条会让你浪费的时间，比其他所有条加起来还多。

MVP 的目标不是完美；目标是学习。每一次，带着瑕疵但上线的产品，都胜过精致却永远不发布的产品。

专注。上线。迭代。

The Real Pattern Behind All of This

Every single point on this list comes down to one thing.

Knowing where to spend your energy.

The best vibe coders aren't better at coding. They're better at identifying what NOT to build. They have a strong sense of which decisions are reversible and which ones will cost them weeks.

Use the tools. Trust the ecosystem. Ship fast. Learn from real users.

Stop building from scratch what someone already built better.

The time you save goes into the part of your product that actually matters: the features, the UX, the distribution, the thing that makes someone say "I need this".

That's where the real work is.

Spent 3 years learning all of this the hard way. You don't have to.

If you're building your first or fifth MVP and want to see how we apply this to client projects, my cal.com is in my bio. First call is always just to understand your problem, nothing else.

Link: http://x.com/i/article/2025145098120691716

这一切背后的真正规律

这份清单里的每一点，归根结底都指向一件事。

知道把精力花在哪里。

最好的 Vibe Coder 并不是写代码更强，而是更擅长识别哪些东西不该自己造。他们对哪些决策可逆、哪些会让自己付出数周代价，有很强的直觉。

用工具。信任生态。快速上线。从真实用户那里学习。

别再从零开始造别人已经做得更好的东西。

你省下来的时间，应该投到真正重要的部分：功能、UX、分发，以及那个让人脱口而出“我需要这个”的东西。

真正的工作在那里。

我花了 3 年，用最痛的方式学会这些。你不必如此。

如果你在做第一个或第五个 MVP，想看看我们如何把这些原则应用到客户项目里，我的 cal.com 在个人简介里。第一次通话永远只是为了理解你的问题，不做别的。

链接：http://x.com/i/article/2025145098120691716

相关笔记

Most people waste months building things that should have taken weeks.

Not because they're bad developers. Not because they picked the wrong idea.

Because they made decisions that felt right in the moment but buried them in technical debt before they even shipped.

I've shipped 50+ MVPs for clients across the US, India, Dubai, and Australia. I've seen this pattern repeat itself over and over again.

Founders who are smart, motivated, and capable... grinding for 3 months on something that should have been live in 3 weeks.

This article is everything I wish someone had handed me early on.

Not theory. Not what "should" work. What actually works when you're building fast, building alone, and building to ship.

Why Vibe Coders Fail (And It's Not What You Think)

The mistake isn't the code.

The mistake is the decision made before the code.

Every hour you spend building auth from scratch is an hour you didn't spend on the one feature that actually makes your product worth using. Every time you write raw CSS for something shadcn/ui could solve in 5 minutes, you're not building. You're stalling.

Vibe coding only works when you trust the tools that already exist.

The best vibe coders I know aren't the ones who know the most. They're the ones who know what NOT to build.

Here's the complete breakdown of both sides.

Part 1 : The DO's (What Actually Saves You Time)

  1. Use Ready-Made Auth

Stop building authentication from scratch. Full stop.

Clerk and Supabase Auth exist for exactly this reason. They handle sessions, tokens, OAuth providers, security edge cases, and mobile compatibility, all of it, in the time it would take you to write a basic login form.

I've seen founders spend 2 weeks on auth for an MVP nobody has validated yet. That's 2 weeks of building the one thing users will never see or care about.

Use Clerk. Use Supabase Auth. Move on.

  1. Use Tailwind and shadcn/ui for UI

This one saves you the most time, consistently.

Tailwind gives you a constraint system. shadcn/ui gives you production-ready components. Together, they let you build UIs that look legitimate without designing anything from scratch.

The ROI here is insane. I've gone from Figma to working UI in 2-3 hours using this combo. Without it, that's a full day minimum.

Bonus: your UI stays consistent. No random sizing, no colour inconsistencies, no eyeballing pixel values at 1am.

  1. Use Zustand and Server Components for State

Over-engineered state management is where projects go to die.

Zustand handles client-side state cleanly. Server Components handle the rest. You don't need Redux. You don't need Context wrappers 6 layers deep. You don't need a PhD in state architecture for a product that has 12 users.

Keep it simple. Ship.

  1. Use tRPC and Server Actions for APIs

If you're building custom REST APIs from scratch for your MVP, you're doing way more work than you need to.

tRPC gives you end-to-end type safety without configuration overhead. Server Actions handle form mutations and data updates cleanly. Together, they eliminate an entire layer of boilerplate that used to eat up days.

  1. Deploy with Vercel One-Click

Manual deployments are a productivity trap.

The time you spend configuring servers, managing SSH keys, and debugging deployment scripts is time not spent on your actual product. Vercel takes all of that away. One push to main, done.

Your energy is worth more than your server config.

  1. Use Prisma and Managed Postgres

Writing raw SQL for an MVP is a red flag.

Prisma gives you a typed ORM that's easy to schema with, easy to migrate with, and easy to read. Managed Postgres (Supabase, Neon, Railway) means no server management.

This combo handles 95% of what any MVP needs, cleanly, without friction.

  1. Validate with Zod and React Hook Form

Form validation is one of those things that looks simple and turns into a nightmare if you don't have the right tools.

Zod handles schema validation. React Hook Form handles form state. Together, they make forms predictable and trustworthy. Unvalidated inputs is how you get broken data in your database and angry users at 2am.

  1. Use Stripe for Payments

Never build your own payment system. Not once, not ever.

Stripe handles payments, subscriptions, refunds, disputes, compliance, and webhooks. Building any of this yourself is not just time-consuming, it's dangerous. One compliance issue and you're done.

Use Stripe. It takes 45 minutes to integrate and it works.

  1. Add Sentry or Error Tracking Early

This is the one most people skip and regret the most.

When your app breaks in production (and it will), you need to know immediately. Not when a user tweets at you. Not when you accidentally stumble on the bug yourself.

Sentry tells you exactly what broke, exactly where, and exactly how often. Set it up on day one. It costs nothing to start.

  1. Set Up Analytics From the Beginning

PostHog or Plausible. Pick one. Set it up before launch.

If you don't know how users are moving through your product, you're guessing. And guessing about product decisions at an early stage is how you build the wrong thing for 3 months.

You need data. Set it up early so it actually has data when you need it.

  1. Store Secrets in Environment Files

Hardcoding API keys is one of those mistakes that's obvious in hindsight and catastrophic in the moment.

Use .env files. Add them to .gitignore. Use a service like Doppler or Vercel's built-in environment manager for production. Never commit a secret to version control. Not once.

  1. Use UploadThing or Cloudinary for Files

File uploads seem simple until you're managing storage, CDN delivery, file size limits, and security permissions yourself.

UploadThing handles all of it. Cloudinary handles transformations too if you need them. Integrate in an afternoon, move on.

  1. Set Up Preview Deployments

Every PR should have a preview URL.

Vercel does this automatically. It lets you (and clients) test changes before they hit production. This saves you from shipping broken UI to real users and having to do emergency rollbacks at midnight.

  1. Use Component Libraries Like Radix and shadcn

Building UI components from scratch is slow and inconsistent.

Radix gives you unstyled, accessible, production-grade primitives. shadcn builds on top of them with styling already applied. Between the two, you can build almost any UI pattern without reinventing the wheel.

  1. Write a README From Day 1

You think you'll remember how everything works. You won't.

A simple README with how to run the project, what the environment variables are, and what the core decisions were saves you hours of confusion 3 weeks later. It also makes handoffs to clients infinitely smoother.

Takes 20 minutes. Saves 4 hours.

  1. Keep Folders Clean and Modular

Messy folder structure isn't a small problem. It compounds.

Every time you add a feature to a messy codebase, you spend 30% of your time just navigating. Clean, modular structure means you can onboard someone else, or your future self after 3 weeks away, without friction.

Components, hooks, utils, types. Keep it predictable.

  1. Add Onboarding and Empty States

This is the most underrated UX investment you can make.

Empty states tell users what to do when there's no content. Onboarding tells them how to get value on day one. Without these, users land in your app and have no idea what to do next.

Confused users don't convert. They leave.

  1. Use Lighthouse and Performance Tools

Performance isn't a nice-to-have.

Slow apps lose users. Lighthouse (built into Chrome DevTools) gives you a free performance audit in 30 seconds. A score below 70 is a red flag. Fix it before launch, not after you've lost users to it.

Part 2 : The DON'Ts (What Burns Your Time and Energy)

Don't Build Auth From Scratch

Already covered above, but it deserves repeating.

This is the #1 time killer I see across almost every first-time vibe coder. The combination of security complexity, edge cases, and maintenance overhead makes it the worst possible place to spend early project hours.

Don't Write Raw CSS for Everything

Raw CSS is not a virtue. It's a liability.

Unless you have a very specific design system requirement, you should not be writing raw CSS in 2026. Tailwind covers 99% of what you need, faster and with more consistency.

Stop reaching for a paintbrush when someone already built you a painting machine.

Don't Over-Engineer State Management

If you're reaching for Redux or complex Context patterns for an MVP, ask yourself why.

Most early-stage apps need simple state. Zustand handles it. Server state? React Query or Server Components. That's it.

Don't build an architecture for 10 million users before you have 10.

Don't Build Custom APIs Too Early

REST APIs from scratch add weeks of work before you've validated anything.

Start with tRPC or Server Actions. If you outgrow them, migrate later with actual data telling you why. Don't build a full API infrastructure for a product with 0 users.

Don't Deploy Manually

Manual deployments introduce human error, take time, and don't scale.

Every time you manually deploy, you're one mistake away from breaking production. Automate it from day one. Vercel, Railway, Render, all of them have push-to-deploy. Use it.

Don't Write Raw SQL Everywhere

Unless you have very specific performance requirements (which your MVP doesn't), there's no reason to skip an ORM.

Raw SQL is harder to maintain, harder to refactor, and easier to get wrong in security-sensitive ways. Prisma exists. Use it.

Don't Build Your Own Payment System

This cannot be overstated. Building your own payment system is not a flex. Its a liability.

PCI compliance alone is months of work. Stripe handles it. Spend the 45 minutes to integrate and move on.

Don't Roll Your Own Search Engine

Algolia, Typesense, Meilisearch. All of them solve search better than you'll build it in the time you have.

Full-text search is deceptively hard. Edge cases, ranking, typo tolerance, performance under load. None of this is trivial to build. The services that do it have teams of people who've worked on it for years.

Let them.

Don't Skip Logging and Monitoring

Shipping without monitoring is like driving with your eyes closed.

You'll only find out something broke when a user tells you. By then, you've probably already lost users who didn't bother to report it.

Sentry, LogRocket, or even Axiom. Pick one. Set it up before launch.

Don't Hardcode API Keys

If your keys end up in version control, you're exposed. Full stop.

GitHub automatically scans public repos for exposed secrets and notifies services like AWS, who then revoke the keys. This has happened to developers who lost access to months of infrastructure.

Use environment variables. Always.

Don't DIY File Uploads

It seems simple. It's not.

Storage management, CDN configuration, file type validation, size limits, security. UploadThing and Cloudinary solve all of this in one integration. The DIY version breaks in production in ways you won't predict.

Don't Push Straight to Main

A single bad push to main can break production for real users.

Use feature branches. Set up preview deployments. Even if you're solo, the habit of reviewing your own code before merging it to main catches more bugs than you'd expect.

Don't Build Realtime Systems Alone

Realtime is hard. Websockets, presence indicators, conflict resolution, they're all significantly more complex than they look.

Supabase Realtime, Pusher, Partykit. These services exist specifically because building realtime infrastructure from scratch is a full-time project. Don't do it for an MVP.

Don't Ignore Performance

A slow app is a dying app. Users have no patience for load times in 2026.

Lighthouse tells you your score in 30 seconds. If it's bad, fix the biggest issues before launch. Unoptimized images, large JS bundles, and blocking render paths are usually the culprits and they're all fixable.

Don't Assume Users Will Figure It Out

Your product makes sense to you. It won't make sense to anyone else without guidance.

Add onboarding. Add tooltips on first use. Write empty states that tell users what to do next. The products that retain users are the ones that hold their hand through the first 5 minutes.

Don't Postpone Refactoring Forever

Technical debt is fine early. Left unchecked, it compounds into a codebase you can't move fast in.

Set a regular schedule. After every 2-3 features, spend a session cleaning up the mess you made. Future you will be grateful.

Don't Rely on Memory for Decisions

Document your decisions.

Why did you pick this library? Why did you structure the database this way? What was the tradeoff you made? Write it down. Future you, your client, and any future developer on the project will thank you.

Don't Chase Perfect Before Shipping

This one will cost you more time than all the others combined.

The goal of an MVP is not to be perfect. The goal is to learn. Shipped and imperfect beats polished and never launched every single time.

Lock in. Ship. Iterate.

The Real Pattern Behind All of This

Every single point on this list comes down to one thing.

Knowing where to spend your energy.

The best vibe coders aren't better at coding. They're better at identifying what NOT to build. They have a strong sense of which decisions are reversible and which ones will cost them weeks.

Use the tools. Trust the ecosystem. Ship fast. Learn from real users.

Stop building from scratch what someone already built better.

The time you save goes into the part of your product that actually matters: the features, the UX, the distribution, the thing that makes someone say "I need this".

That's where the real work is.

Spent 3 years learning all of this the hard way. You don't have to.

If you're building your first or fifth MVP and want to see how we apply this to client projects, my cal.com is in my bio. First call is always just to understand your problem, nothing else.

Link: http://x.com/i/article/2025145098120691716

📋 讨论归档

讨论进行中…