1. 项目缘起一个独立开发者的“小产品”冲动去年夏天我盯着日历上密密麻麻的会议和项目截止日期突然意识到一个困扰我多年的问题我永远记不清某个特定月份的最后工作日是哪一天。我说的不是法定节假日而是那种“这个月最后一天是周五但公司通知提前半天放假”或者“客户要求月底前交付但月底那天是周日”的混乱情况。我需要一个快速、无脑的工具输入年份和月份它能立刻告诉我那个月实际的最后一个工作日并自动避开周末和常见的节假日。我搜了一圈发现要么是功能臃肿的日历应用要么是需要手动维护的Excel模板没有一个轻量、专注的网页工具。就在那个瞬间一个念头闪过为什么不自己做一个这似乎是个完美的“周末项目”——需求明确、用户群体清晰可能就是我自己和像我一样的职场人、技术栈不复杂。更重要的是我想跳出“为公司写代码”的循环体验一次从零到一构建一个真正属于自己的、能解决实际问题的产品并以“独立开发者”的身份公开发布它。这就是LastWorkingDay诞生的最初火花也是我首次尝试“一人创业”的SaaS产品。2. 产品定义与核心价值它到底是什么解决了谁的问题2.1 从个人痛点到普适需求最初LastWorkingDay 被设想为我个人的效率工具。但当我开始向朋友、前同事提起这个想法时反馈出乎意料地热烈。财务人员需要它来精确计算工资结算日或发票截止日项目经理靠它规划项目里程碑和交付节点HR用它安排月度考核的最终提交时间甚至自由职业者也需要和客户明确“月底付款”的具体日期。这个看似微小的需求背后连接着一个广泛存在的场景在商业和协作中我们需要一个明确的、无歧义的日期锚点。“月底”这个词是模糊的它可能是自然月的最后一天31号也可能是最后一个周五或者是公司规定的“月度经营分析会”前一天。LastWorkingDay 的核心价值就是将这种模糊性标准化、自动化。它不试图取代完整的日历系统而是充当一个高效的“日期查询器”在需要快速决策时提供那个关键的、正确的日期。2.2 目标用户画像与使用场景基于上述分析我勾勒了四类核心用户职场专业人士包括财务、会计、运营、项目经理等。他们的使用场景是高频、刚需的。例如每月底制作报表时需要快速确认数据截取的最后工作日设定项目 deadline 时需要避开周末和假日。团队管理者与HR用于制定团队工作计划、发布内部通知如“请于本月最后一个工作日前提交报销单据”、安排月度会议等确保时间节点对全员清晰一致。自由职业者与小企业主在与客户签订合同、约定付款周期、规划自身工作节奏时需要一个权威的日期参考避免因日期理解不一致产生纠纷。普通办公族用于个人工作规划例如安排休假连上最后一个工作日休长假、提交审批流程等。这个清晰的定义让我意识到LastWorkingDay 不能只是一个简单的周末和节假日排除工具。它需要具备足够的灵活性以适配不同地区、不同公司的差异化规则同时又要保持极致的简单和快捷。3. 技术架构与核心功能设计3.1 技术栈选型为什么是这些组合作为一个独立项目技术选型的核心原则是高效、稳定、低成本、易维护。我不需要追求最前沿的技术而是选择最成熟、文档最丰富、社区支持最好的“组合拳”。前端我选择了React TypeScript Vite。React的组件化思维非常适合构建这种交互明确的工具型应用TypeScript能在开发阶段就捕获大量潜在的类型错误对于单人开发来说这是提升代码质量和后期维护信心的关键Vite则提供了闪电般的启动和热更新速度让开发体验非常流畅。UI框架Tailwind CSS。这是我做过最正确的决定之一。对于独立开发者设计是一个巨大的门槛。Tailwind的实用类Utility-First范式让我无需在HTML和CSS文件间反复切换通过组合类名就能快速构建出美观、响应式的界面极大地提升了前端开发效率。后端与APINext.js API Routes。由于产品逻辑相对简单大部分计算可以在前端完成但节假日数据需要从后端获取。Next.js提供了全栈能力让我能在同一个项目中无缝编写前端页面和API接口部署也极其简单。这避免了维护单独后端服务的复杂性。数据库PlanetScale。这是一个基于Vitess的MySQL兼容、无服务器数据库。对于初期阶段它的免费套餐足够使用并且自动处理了分片、备份和扩缩容。最关键的是它作为Vercel我的部署平台的深度合作伙伴集成和连接都非常顺畅。部署与托管Vercel。对Next.js应用的支持是“开箱即用”的。关联Git仓库后每次推送代码都能自动触发部署。全球CDN、SSL证书自动配置、无服务器函数……这些运维头疼的问题全部被解决了让我能百分百专注于产品开发。节假日数据源这是一个关键且容易忽略的部分。我评估了几个方案1使用公共免费API不稳定且可能不符合特定国家地区规则2手动维护数据库工作量巨大。最终我选择了一个折中方案集成一个开源的、社区维护的节假日数据集作为基础同时预留了“自定义节假日”功能。基础数据保证开箱即用自定义功能满足企业用户个性化需求。注意技术选型没有绝对的对错只有是否适合当前阶段。对于独立项目减少选择、降低运维复杂度、利用成熟生态是最高优先级。不要陷入“技术炫技”的陷阱。3.2 核心功能模块拆解LastWorkingDay 的功能围绕一个核心交互展开输入条件得到日期。但为了让这个结果可靠、有用背后需要多个模块协同工作。日期计算引擎核心算法接收年、月、地区/日历类型作为输入。首先获取该月的自然最后一天如2024-02-29。然后根据设定的“工作日”规则通常是周一至周五向前回溯找到第一个符合条件的工作日。节假日排除这是引擎最复杂的部分。算法需要查询内置或用户自定义的节假日列表。如果回溯到的日期是节假日则继续向前回溯直到找到一个既是工作日又不是节假日的日期。特殊规则处理例如有些公司规定“如果最后一天是周五则提前到周四下午”。这需要引擎支持可配置的偏移规则offset rules。我将其设计为一个可插拔的规则系统初期支持基础规则为未来扩展留出接口。用户交互界面极简输入主界面只有一个年份选择器、一个月份选择器和一个地区选择下拉框。点击“计算”按钮结果立即显示。结果呈现不仅显示日期如“2024-04-30”还以更友好的方式展示如“2024年4月最后一个工作日是 星期二4月30日”。同时高亮显示被跳过的周末和节假日让计算过程透明化。自定义面板这是一个高级功能入口。用户可以添加自己公司的特定假日或者创建一套完整的自定义日历规则如“我们公司每周四、五休息”。数据管理节假日数据同步如何更新每年的节假日我设计了一个后台管理功能不对外开放可以手动导入或通过脚本更新开源数据集。同时计划在未来为付费用户提供自动化的年度数据更新服务。用户自定义数据存储用户添加的自定义节假日或规则会通过API保存到数据库并与用户的账户如果登录了关联。这里采用了轻量级的用户系统基于Next.js的Auth.js实现简单的邮箱注册登录。分享与集成一键复制计算结果的日期可以一键复制到剪贴板方便粘贴到邮件、聊天工具或文档中。固定链接每次计算都会生成一个唯一的URL分享这个链接别人打开就能看到完全相同的计算结果。这在团队协作中非常有用。日历订阅为付费用户规划的功能允许用户订阅一个iCal日历其中包含未来12个月每个月的最后一个工作日自动添加到Outlook、Google Calendar等。4. 开发历程从原型到公开发布4.1 第零周验证与设计在写第一行代码之前我花了整整一周时间做“纸上工作”。手绘原型在笔记本上画出每一个屏幕的草图首页、结果页、自定义设置页。思考用户的操作流程是否足够顺畅。功能优先级排序使用MoSCoW法则必须有、应该有、可以有、不要有对功能列表进行排序。V1.0的“必须有”功能被严格限定为基础日期计算、内置主要国家节假日、结果展示与复制。自定义规则、用户账户等都被划入“应该有”或下一阶段。技术可行性验证快速搭建了一个最简的Next.js项目用硬编码数据测试了核心日期计算逻辑的JavaScript实现确保算法思路正确。命名与域名想一个好名字至关重要。LastWorkingDay 直接、好记、英文拼写清晰。幸运的是lastworkingday.app 这个域名尚未被注册我立刻将其买下。4.2 第一至三周核心功能实现这三周是集中编码期我采用了“垂直切片”的开发方式即尽快做出一个端到端可用的最小功能集合。第一周搭建Next.js项目骨架配置好TypeScript、Tailwind和基础组件库。实现最核心的日期计算函数不考虑任何节假日只处理周末。完成一个极其丑陋但能用的页面选择年月点击按钮显示避开周末的最后一天。第二周集成基础节假日数据。我选择了一个包含多个国家年份数据的JSON文件将其作为静态资源引入。前端计算时会读取这份数据。同时完善UI设计使用Tailwind构建了一个简洁明快的界面结果展示区域做了视觉强化。第三周实现“固定链接”功能。这涉及到将计算参数年、月、地区码编码到URL的查询字符串中。当页面加载时如果检测到这些参数就自动执行计算并显示结果。这是产品“可分享”属性的关键。至此一个可用的MVP最小可行产品诞生了。实操心得在独立开发中“垂直切片”比“分层构建”更有效。先做出一个从输入到输出的完整闭环哪怕它很简陋。这能给你巨大的正反馈并让你立刻开始真实使用自己的产品发现最迫切的问题。4.3 第四至五周打磨、测试与部署产品能用和好用之间隔着巨大的鸿沟。这两周主要进行打磨。用户体验优化输入默认值将年份和月份选择器默认设置为当前年月。即时计算去掉“计算”按钮改为选择年份或月份后立即显示结果让交互更流畅。加载状态在数据加载或计算时显示一个微妙的加载指示器。错误处理对非法输入如过去的年份太早数据不存在给出友好的提示信息。跨浏览器与设备测试在Chrome、Firefox、Safari以及手机和平板设备上测试页面布局和功能。确保Tailwind的响应式设计正常工作。性能检查使用Lighthouse工具检查页面性能、可访问性等。由于逻辑简单且静态资源少很容易就拿到了接近满分的评分。部署上线将代码仓库连接到Vercel配置生产环境变量。整个过程不到10分钟。访问 lastworkingday.app看到自己亲手打造的产品运行在互联网上那种感觉无与伦比。4.4 第六周及以后发布、收集反馈与迭代产品上线不是终点而是起点。公开发布我选择了几个平台进行发布Product Hunt这是面向全球独立开发者和早期用户的产品发布社区。我精心制作了封面图、简介和动图演示在一天中的最佳时间美国西部时间早上发布。Hacker News在“Show HN”板块分享。这里的用户技术背景强反馈非常直接且具有建设性。个人社交网络在Twitter、LinkedIn上向我的关注者介绍这个工具。早期用户反馈发布后我收到了大量宝贵的反馈主要集中在以下几点“我需要考虑调休”这是中国用户提出的最强需求。我们的节假日安排经常出现“周末上班、工作日休息”的调休情况这是最初算法没有考虑的。“能否导出到日历”很多用户希望一次性获得全年的最后工作日并导入日历。“自定义规则太复杂”我初期设计的自定义界面过于技术化普通用户看不懂。快速迭代根据反馈我立即规划了下一版本的开发V1.1紧急优化算法加入对中国特有“调休”规则的支持。这需要更复杂的数据结构和逻辑判断。V1.2重新设计自定义界面用更直观的“添加假期”表单和“选择非工作日”的勾选框来代替原始的规则编辑器。未来规划开发日历订阅功能并开始设计基础的付费墙考虑对高级功能如团队自定义日历、API访问、历史数据查询进行收费。5. 独立开发中的挑战与解决方案5.1 技术挑战数据与算法的准确性挑战节假日的规则因国家、地区甚至公司而异且每年都可能变化。如何保证计算结果的权威性解决方案明确责任边界在网站底部清晰注明“基础节假日数据来源于开源项目 [项目名]仅供参考。对于关键日期请务必以您所在机构官方通知为准。” 这既是免责声明也设定了用户期望。提供“自定义”这个终极解决方案认识到无法做到百分百普适就把工具的能力开放给用户。让用户自己成为数据的维护者来适配他们的独特场景。这反而成了产品的一个亮点。建立数据更新机制编写一个简单的脚本每年年底可以半自动地拉取最新的开源节假日数据更新到数据库中。对于付费用户可以提供“数据更新保障”服务。5.2 产品挑战功能范围的把控挑战用户反馈很多比如“能不能算倒数第二个工作日”、“能不能算季度末” 很容易陷入“功能蔓延”的陷阱把简单工具做复杂。解决方案坚守核心定位。每次收到新功能建议我都会问自己两个问题1这个功能是否服务于“快速确定最后一个工作日”这个核心场景2如果加上它会否让界面变得复杂影响主流用户的体验对于“季度末”这类强相关但非核心的需求我的策略是将其记录到需求池但优先级置后。或许未来可以做一个“LastWorkingDay Pro”系列包含“季度末”、“财年末”等专业工具。5.3 运营与增长挑战一个人如何让产品被看见挑战开发完成只是第一步没有预算做营销如何获取用户解决方案内容营销围绕“最后工作日”这个主题写一些对目标用户有价值的文章。例如《财务人员必知准确计算工资结算日的三个技巧》、《项目管理的隐形陷阱模糊的截止日期》。将这些文章发布在个人博客、Medium或LinkedIn上并在文中自然地介绍LastWorkingDay这个工具。SEO优化在网站中合理布局“last working day calculator”、“month end working day”等关键词。确保页面标题、描述和内容对搜索引擎友好。工具类网站有天然的内容优势因为用户搜索意图非常明确。建立简单的用户反馈循环在网站底部添加一个“发送反馈”的链接直接链到我的邮箱。认真回复每一封邮件让早期用户感到被重视他们很可能成为产品的传播者。探索集成与合作与一些小型SaaS工具如团队待办事项、轻量级CRM的开发者联系探讨能否将LastWorkingDay作为一个微件集成到他们的产品中互相导流。6. 经验总结与避坑指南回顾这次从0到1的SaaS产品构建与发布之旅有几个关键的体会和教训对任何想尝试独立开发的朋友可能都有参考价值。6.1 最重要的决策做什么和不做什么做“止痛药”而不是“维生素”LastWorkingDay解决的是一个具体的、偶尔发生但很恼人的痛点记不清/算不准最后工作日。这种工具比一个“锦上添花”的娱乐应用更容易让用户感知价值。受众要足够广但切入点要足够尖几乎所有职场人都有这个需求这是“广”。但我只做“查询最后工作日”这一件事这是“尖”。这让我能集中所有精力把一个点做到极致。技术服务于产品而不是相反我选择的所有技术都是为了实现“快速开发、稳定运行、易于维护”这个产品目标。没有因为想学某个新技术而用它。6.2 开发流程上的教训尽早发布哪怕不完美我的MVP在第三周末就具备了核心功能但我又花了两周去“打磨”才敢发布。后来发现用户反馈中最重要的“调休”需求如果我早点发布就能更早发现并解决。“完成”比“完美”更重要。自动化一切能自动化的代码格式化、静态检查、测试、部署。对于独立开发者时间是最宝贵的资源。使用ESLint、Prettier、GitHub Actions等工具建立自动化流水线能节省大量时间并减少错误。日志和监控不能省即使是一个简单的静态网站我也接入了像Sentry这样的错误监控服务。上线后不久它就帮我捕获了一个在特定浏览器时区下的日期计算错误让我能在用户大规模抱怨前修复它。6.3 心态调整从工程师到创造者接受“全栈”意味着“全干”你不仅是前后端工程师还是产品经理、UI/UX设计师、运维、客服、市场和销售。需要不断切换角色这对专注深度的工程师思维是个挑战但也是巨大的成长。用户反馈是金矿但也要学会筛选收到负面反馈时第一反应不要是辩护而是理解。但也要明白最响亮的用户不一定代表大多数用户。要用数据如果有的话和产品核心定位来做决策。享受过程而不仅仅是结果构建LastWorkingDay的过程中我重新找回了编程最原始的快乐——创造一个东西看着它运行并真的帮到别人。即使它最终没有带来可观的收入这段经历本身在技能和心态上带给我的回报已经足够丰厚。LastWorkingDay的故事还在继续。它目前有几千名月活用户收到过感谢邮件也收到了不少付费咨询。对我而言它已经成功了——它成功地将一个想法变成了一个真实运行的产品并验证了“独立开发者”这条路的可行性。如果你也有一个想解决的小问题别犹豫从下一个周末开始动手把它做出来吧。