独立开发者实战：从0到1构建工作日计算SaaS工具

1. 项目缘起：一个独立开发者的“小产品”执念

做独立开发者（Indie Hacker）或者说“一人公司”（Solopreneur），大概是很多程序员心里都埋着的一颗种子。我们习惯了在大厂里拧螺丝，在敏捷流程里当齿轮，但内心深处总有个声音在问：如果抛开所有流程、会议和KPI，只凭自己的双手，能不能从零到一做出一个真正有人用、甚至能赚钱的产品？这个念头在我心里盘踞了好几年，直到去年，我终于决定不再“想”，而是动手“做”。于是，就有了LastWorkingDay这个项目。

LastWorkingDay，直译过来是“最后工作日”。它的核心功能非常简单：帮你计算两个日期之间的实际工作日天数，自动排除周末和自定义的节假日。听起来是不是有点“小题大做”？市面上不是有无数在线计算器吗？没错，但正是这种“简单”背后隐藏的、未被很好满足的特定场景需求，让我看到了机会。我自己的触发点，是处理一份劳动合同的终止日期计算。HR发来邮件，需要根据通知期和最后工作日倒推起始日期，我手动在日历上数了半天，还差点把某个调休日算进去。那一刻我意识到，对于经常处理合同、项目排期、薪资结算（尤其是涉及通知期、年假折算）的人来说，一个精准、可定制且体验流畅的工作日计算工具，是有其独特价值的。

这个产品的定位很清晰：一个轻量级、即开即用的SaaS工具。它不需要用户注册就能使用核心功能，而高级的节假日定制、历史记录保存等，则留给愿意付费的客户。我的目标不是做一个功能大而全的“瑞士军刀”，而是做一把极其锋利、用起来顺手的“小刀”。这就是我作为独立开发者的第一个公开上线的SaaS产品，整个过程——从构思、设计、开发、部署到第一次在公开社区展示——是一次完整且充满挑战的“一人创业”实验。接下来，我会把这几个月踩过的坑、获得的经验，毫无保留地拆解给你听。

2. 产品定义与市场切入点的深度思考

2.1 解决什么“真问题”？

在决定做任何产品之前，最忌讳的就是“我觉得用户需要”。我们必须找到那个“用户自己可能都没清晰表达，但确实存在”的痛点。对于工作日计算，表面痛点是“手动数日子麻烦且易错”。但深挖下去，其实是“在不同规则和上下文下的快速、可靠计算”需求。

1. 规则的复杂性：不同国家、地区甚至公司的节假日完全不同。中国的春节、国庆长假调休规则能让任何计算器崩溃。欧美用户的感恩节、圣诞节假期也各有不同。一个通用的“排除周末”远远不够。
2. 上下文的多样性：计算“30个工作日后的日期”和计算“从今天到年底还有多少个工作日”是两种不同的思维模式。前者是日期推算，后者是天数统计。用户需要在不同模式间无缝切换。
3. 结果的权威性与记录需求：当这个计算用于合同、法律文件或项目承诺时，用户需要一份清晰、可追溯的计算依据（比如，排除了哪些特定节假日）。他们可能还需要保存或分享这次计算。

因此，LastWorkingDay 要解决的“真问题”是：为用户提供一个适应其特定节假日规则，支持多种计算模式，并能生成可信记录的专业级工作日计算服务。它不是一个计算器，而是一个“工作日计算引擎”的友好界面。

2.2 为什么选择SaaS和Solopreneur路径？

为什么不做成桌面软件或移动App？为什么选择一个人干？

1. SaaS的天然优势：

   • 零门槛使用：一个URL，任何设备、任何浏览器即开即用。这对于工具类产品至关重要，用户要的是快速解决问题，而不是下载安装。
   • 即时更新与迭代：修复Bug、添加新的节假日规则、优化UI，所有用户都能立刻享受到。这对于需要紧跟政策（如节假日安排）的产品是生命线。
   • 清晰的商业模式：Freemium（免费增值）模式非常适合。基础功能免费，吸引流量和用户；高级功能（如自定义节假日库、团队协作、API访问）收费，实现变现。SaaS的订阅制也能带来可持续的现金流预期。

2. Solopreneur的可行性：

   • 技术栈成熟：现代Web开发框架（如Next.js, Vue）、云服务（Vercel, AWS, Supabase）、支付集成（Stripe, Paddle）已经非常完善，一个人可以高效地搭建起一个功能完整、稳固可靠的全栈应用。
   • 成本极低：在初始阶段，云服务的免费额度（如Vercel的Hobby计划、Supabase的免费层）足以支撑早期用户。主要成本是域名和自己的时间。
   • 专注与速度：没有内部沟通损耗，想法可以最快速度落地验证。产品方向和用户体验可以保持高度一致。

注意：选择Solopreneur路径，意味着你必须是“全栈”的——从前端、后端、数据库、DevOps到设计、营销、客服。这既是挑战，也是巨大的学习与成长机会。关键在于，要善于利用现有工具和服务来弥补个人能力的短板，而不是所有东西都自己造。

3. 技术架构与核心实现解析

作为一个展示项目，技术选型的核心原则是：高效、稳定、低成本、易维护。下面是我的技术栈和关键实现思路。

3.1 技术栈选型：为什么是它们？

• 前端框架：Next.js (App Router) + TypeScript + Tailwind CSS

  • Next.js：选择它而非纯React，是因为它提供了开箱即用的解决方案：服务端渲染（SSR）、静态生成（SSG）、简单的API路由、以及最新的App Router带来的更好的布局、加载和错误处理体验。这对于需要良好SEO（虽然工具类SEO权重不高）和快速首屏加载的工具网站很重要。
  • TypeScript：对于日期计算这种逻辑复杂、容易出错的领域，类型安全是救命稻草。它能极大减少因类型错误导致的Bug。
  • Tailwind CSS：一人开发，设计资源为零。Tailwind的实用优先（Utility-First）理念让我可以快速构建出美观、一致的UI，而无需在CSS文件和组件间来回切换。效率提升巨大。

• 后端/数据库：Supabase

  • 一站式解决方案：Supabase提供了PostgreSQL数据库、实时订阅、身份验证、存储和边缘函数。对于LastWorkingDay，我主要用到了它的数据库和Auth。
  • 数据库：存储用户的自定义节假日配置、计算历史记录。
  • Auth：处理用户注册、登录。Supabase Auth支持多种方式（邮箱/密码、社交登录等），集成非常简单，节省了大量开发时间。
  • 为什么不用独立服务器+数据库？因为运维成本。Supabase帮我处理了数据库备份、扩容、安全这些琐事，让我能专注于业务逻辑。

• 部署与托管：Vercel

  • 与Next.js天生一对：部署Next.js应用到Vercel是最顺畅的体验，支持自动预览部署、全球CDN、服务器less函数。
  • 免费层足够强大：Hobby计划完全满足早期需求，带宽和函数调用额度都很慷慨。
  • 工作流集成：连接GitHub仓库后，每次git push自动触发部署，实现了高效的CI/CD。

• 核心计算库：date-fns + 自定义逻辑

  • date-fns：一个轻量级、模块化的日期库。用它来处理基础的日期加减、比较、格式化。
  • 自定义工作日计算引擎：这是产品的核心。我实现了一个纯函数，其逻辑大致如下：
    1. 输入：起始日期、结束日期、节假日数组、工作周模式（如是否包含周六）。
    2. 迭代：从起始日期循环到结束日期。
    3. 判断：对每一天，检查是否为周末（使用date-fns的isWeekend，并可配置）、是否在节假日列表中。
    4. 计数：如果既不是周末也不是节假日，则工作日计数加1。
    5. 优化：对于大时间跨度的计算，简单的循环可能稍慢。我加入了“跳过整周”的优化：如果遇到连续的、无节假日的工作周，可以直接增加5天，而无需逐天判断。
  • 节假日的存储与查询：节假日数据存储在Supabase的holidays表中，结构包含日期、名称、国家/地区代码、是否每年重复等。用户自定义的节假日则关联到其用户ID。

3.2 核心功能模块实现要点

3.2.1 日期选择与交互

使用原生<input type="date">还是第三方组件库？我选择了原生输入。原因：1) 零依赖，包体积小；2) 现代浏览器原生日期选择器的体验已经很好；3) 移动端适配完美。为了提升体验，我增加了快捷按钮，如“今天”、“月底”、“+30天”等，并确保日期格式本地化。

3.2.2 节假日管理系统

这是产品的护城河之一。我设计了三层节假日体系：

1. 内置节假日库：预置了主要国家（美、英、中、德等）的常见固定和浮动节假日（如复活节）。这部分数据需要自己维护一个JSON文件，并定期更新。
2. 用户自定义节假日：允许用户添加、删除、命名自己的特殊假期（如公司团建、个人休假）。
3. 节假日规则模板：未来计划允许用户创建可复用的规则模板（如“中国的调休规则”），一键应用到计算中。

在数据库设计中，user_holidays表通过user_id外键关联到auth.users，确保数据隔离。

3.2.3 计算历史与状态持久化

即使用户不登录，我也利用浏览器的localStorage临时保存最近几次的计算记录，提升回头客体验。用户登录后，计算历史会同步保存到云端数据库。这里要注意数据清洗和格式统一，确保从localStorage迁移到云端时不会出错。

3.2.4 结果展示与导出

计算结果的展示要清晰、无歧义。我采用卡片式设计，明确标出起始日期、结束日期、总日历天数、排除的周末天数、排除的节假日天数及列表，最终的工作日天数。并提供“复制结果”和“生成摘要”功能。摘要是一段文本描述，如“从2023年10月1日到2023年10月31日，共有23个工作日，其中排除了8个周末和0个节假日”，方便用户直接粘贴到邮件或文档中。

4. 开发历程：从原型到上线的关键节点

4.1 第零步：极简MVP验证

在写第一行代码之前，我先用了一个周末，在纸上画了UI草图，并用一个简单的HTML文件加上JavaScript实现了最核心的计算逻辑。然后，我把这个静态页面发给了几个做HR、法务和项目经理的朋友，让他们试用。反馈非常直接：“如果能把中国的调休加进去就更好了”、“能不能算一下从现在到项目截止日还有多少天？”。这验证了核心需求是存在的，也明确了首批需要迭代的功能点。不要一开始就追求完美，用一个最粗糙的原型去验证想法，是最高效的方式。

4.2 第一步：搭建基础框架与核心计算

接下来的一周，我搭建了Next.js项目，配置好TypeScript和Tailwind。首先实现的就是那个纯函数的“工作日计算引擎”，并为它编写了详尽的单元测试（使用Jest）。测试用例覆盖了各种边界情况：跨年计算、包含大量节假日的月份、开始/结束日期本身就是节假日或周末等。在逻辑复杂处，测试不是可选项，而是必选项。这为后续所有功能开发奠定了可靠的基础。

4.3 第二步：实现用户系统与数据持久化

集成Supabase。这一步的关键是处理好认证状态的同步。Next.js的客户端组件和服务端组件对用户状态的获取方式不同。我采用的方式是：在布局（Layout）中使用Supabase的客户端库来获取并向下传递用户Session，对于需要用户数据的服务端组件，则通过Supabase的cookies()辅助方法来安全地获取。确保登录、注册、登出流程顺畅，且页面刷新后状态不丢失。

4.4 第三步：打磨UI/UX与性能优化

功能可用后，我开始疯狂地“用”自己的产品。在这个过程中，记录下所有不顺畅的地方：比如日期输入不够方便、结果区域不够醒目、移动端某个按钮很难点。然后集中进行UI调整。性能方面，利用Next.js的useMemo和useCallback来避免计算函数和回调函数的重复渲染。对于节假日的加载，采用了服务端获取并缓存的策略，减少客户端请求。

4.5 第四步：部署与发布前“大扫除”

在部署到Vercel之前，在本地进行了全面的检查：

1. 安全检查：检查环境变量是否已设置（Supabase URL & Anon Key），确保没有敏感信息被硬编码。验证API路由是否有适当的权限控制（例如，修改节假日数据的接口必须校验用户身份）。
2. SEO与元标签：为首页和主要功能页面设置了有意义的<title>和<meta description>，虽然工具类搜索意图强，但基础的SEO要做好。
3. 错误边界与监控：用Next.js的error.js和global-error.js捕获运行时错误，并集成了一个简单的错误日志服务（如Sentry的免费计划），以便上线后能及时发现和修复问题。
4. 购买域名与配置SSL：选择一个简短、易记且与产品功能相关的域名，并在Vercel上配置好自定义域名和自动SSL证书。

5. 发布、推广与初期反馈循环

5.1 选择发布阵地：公开构建（Build in Public）

我没有选择“憋大招”然后突然发布，而是采用了“公开构建”的方式。在开发中期，我就在几个独立开发者社区（如Indie Hackers论坛、相关Subreddit）创建了帖子，定期分享进展、遇到的挑战和做出的决策。这样做的好处是：

• 早期反馈：在开发过程中就能获得潜在用户的意见，及时调整方向。
• 建立受众：让对产品感兴趣的人提前关注，上线时能获得首批用户。
• 自我激励：公开承诺是一种强大的驱动力，能督促自己持续更新。

5.2 上线日与冷启动

当产品达到“可用且可靠”的状态后，我正式发布了1.0版本。发布动作包括：

1. 产品着陆页（Landing Page）优化：用简洁的文案说明产品价值（“精准计算工作日，告别手动翻日历”），配上清晰的产品截图和功能列表，并有一个醒目的“免费试用”按钮。
2. 发布公告：在之前更新的“公开构建”帖子里发布正式上线公告，感谢社区成员的帮助，并邀请大家试用。
3. 定向邀请：给最初提供反馈的朋友们发送个性化邮件，请他们成为第一批正式用户。
4. 基础内容营销：写了一篇博客文章，分享“如何准确计算合同中的通知期”，在文章中自然地引入LastWorkingDay作为解决方案。这篇文章发布在个人博客和Medium等平台，带来了一些自然搜索流量。

5.3 收集与处理初期反馈

上线后的前两周是反馈的黄金期。我密切关注几个渠道：

• 产品内反馈：设置了一个简单的“发送反馈”表单。
• 社区帖子评论。
• 错误监控工具。

收到的反馈主要分为几类：

1. Bug报告：例如，某个国家的某个节假日规则有误。处理方式：立即核实并修复，快速部署更新。并向反馈者致谢，让他们感受到被重视。
2. 功能建议：例如，“能否支持反向计算（给定工作日天数，算出结束日期）？”、“希望可以导出为ICS日历文件”。处理方式：记录到公共路线图（如Trello看板）中，并评估优先级。对于普遍需求且实现成本不高的（如反向计算），尽快排期开发。
3. 体验问题：例如，“移动端的结果复制按钮太小”。处理方式：立即进行UI微调。

这个阶段，响应速度比功能完美更重要。快速迭代能让早期用户感到他们参与了产品的塑造，从而更有可能成为忠实用户和传播者。

6. 避坑指南：我踩过的那些“坑”与心得

6.1 技术上的“坑”

• 时区处理：日期计算最大的噩梦之一。服务器可能在UTC时区，用户在全球各地。我的原则是：在存储和计算时，全部使用UTC时间或ISO 8601字符串。仅在向用户展示时，根据其浏览器或设置转换为本地时间。使用date-fns-tz库来处理时区转换，确保“2023-12-25”这个日期对全球用户都指向同一天。
• 节假日数据的维护：内置节假日库不是一次性的。每年各国的放假安排都可能调整。我建立了一个简单的提醒系统，每年第四季度检查并更新下一年度的节假日数据。考虑将这部分数据开源或允许社区贡献，可以减轻维护负担。
• Supabase RLS（行级安全）策略复杂：为了数据安全，必须仔细配置RLS。初期我因为策略太宽松导致数据泄露风险，后来又因为太严格导致前端查询失败。心得：为每张表编写RLS策略时，先从“拒绝所有”开始，然后为每种操作（SELECT, INSERT, UPDATE）逐一添加允许策略，并在开发环境充分测试。

6.2 产品与业务上的“坑”

• 过早优化：我曾花了两天时间纠结于是否要引入Redis来缓存节假日数据，以应对“高并发”。实际上，产品上线一个月，日活不过百，数据库查询完全无压力。独立开发者的黄金法则：除非性能问题已经真实出现并影响了用户体验，否则不要提前优化。
• 功能蔓延：用户提了很多好建议，比如集成项目管理工具、生成甘特图等。如果都做，产品会变得臃肿，失去焦点。必须坚守MVP的核心：精准计算工作日。所有新功能都要问：这能帮助用户更快、更准地计算工作日吗？如果不能，就放入遥远的“未来可能”清单。
• 定价策略的纠结：定多少钱？我参考了类似工具（如一些日期计算API）的定价，最终决定采用非常简单的策略：个人免费，高级功能（无限自定义节假日、历史记录云同步、API访问）按月/年订阅。定价不宜过高，对于这样一个利基工具，5-10美元/月的价格区间更容易被接受。关键是要提供足够价值的免费版本来获取用户，让付费墙后的功能真正解决“痛点之上的痛点”。

6.3 心态上的“坑”

• “孤独感”与动力维持：一个人开发，没有同事交流，很容易陷入自我怀疑或失去动力。对抗方法是：1) 加入线上独立开发者社区，每天看看别人的进展；2) 设定小而具体的目标（如“本周完成支付集成”），每完成一个就给自己小奖励；3) 记住哪怕只有一个用户从你的产品中受益，你的工作就有价值。
• 对数据的焦虑：上线后，会不自觉地每小时刷新一次分析面板，看访问量、用户数。需要克制这种焦虑。将检查频率调整为每天一次或每周一次，更关注用户的定性反馈而非单纯的数字。早期，一个“这个工具救了我一下午的时间！”的评论，比一百个跳出率数据更有意义。

7. 总结与展望：独立开发的第一步

LastWorkingDay 目前还很小，用户数、收入都微不足道。但对我而言，这个项目的成功标准从来不是商业上的巨大成功，而是我完整地走完了一个SaaS产品从构思到上线的全流程。我验证了一个想法，做出了一个可用的产品，并获得了真实用户的反馈。这个过程带给我的经验、教训和信心，是无价的。

如果你也想开始自己的独立开发之旅，我的建议是：

1. 从你真正遇到的痛点开始：最好的创意来源是你自己的生活和工作。
2. 定义最核心的1%：你的产品最核心、不可替代的价值是什么？集中所有资源先把它做到极致。
3. 拥抱“公开构建”：不要害怕分享未完成的作品。社区的力量和早期反馈至关重要。
4. 技术栈选择“够用就好”：选择你熟悉的、能让你快速上手的工具，而不是盲目追求最新最热的技术。
5. 发布，然后迭代：不要追求完美。发布一个“最小可行产品”，然后根据真实世界的反馈来改进它。

LastWorkingDay 的故事还在继续。下一步，我会根据用户反馈，优先开发“反向计算”和“节假日规则模板”功能。同时，我也会开始尝试一些简单的营销实验，比如针对特定职业群体（如自由职业者、小型HR团队）进行内容推广。独立开发是一场马拉松，而我已经成功地跑完了第一公里。最重要的是，我享受这个过程，并且已经迫不及待地开始构思下一个“小产品”了。