典型周期：6 - 12 周，但决定因素不是代码量
一套覆盖 3 - 5 个角色、含权限与报表的内部系统，通常 6 - 12 周。真正拖慢项目的往往不是开发，而是需求反复、历史数据脏、第三方接口迟迟拿不到、以及关键业务人员没时间验收。
五个阶段分别做什么
按阶段拆开，每个阶段都有可验收的成果：
- 第 1 周｜访谈与建模：和实际使用者（不只是老板）聊，画现状流程图、角色权限矩阵、数据字典。
- 第 2 周｜原型与报价：可点击原型 + 功能清单 + 拆分报价，确认后再写第一行代码。
- 第 3 - 7 周｜核心版本开发：只覆盖高频 80% 场景，每两周给一次可访问测试环境。
- 第 8 周｜真实数据试跑：导入清洗后的历史数据，让一线人员用真实业务跑一遍。
- 第 9 周起｜补细节与上线：报表、导出、权限微调、部署文档与培训，然后再决定二期范围。
为什么建议「先上最小可用版本」
内部系统的需求有个特点：没用起来之前，谁都说不清自己真正要什么。把全部设想一次性做完，结果往往是 40% 的功能没人用，而真正卡住流程的那个异常分支没覆盖。
先上线核心流程、跑两周、看操作日志和用户反馈，再补细节，整体交付质量反而更高。
必须拿到的交付清单
验收时请对照下面这份清单，缺任何一项，后续换团队都会很被动：
- 完整前后端源码（含构建脚本）与数据库结构说明
- 部署文档、环境变量说明、备份与恢复步骤
- 接口文档、角色权限矩阵、数据字典
- 所有第三方账号归属清单（域名、服务器、短信、支付等）
- 测试环境 + 生产环境的访问方式与管理员账号
- 免费修复期与后续维护范围，写进合同
怎么避免项目烂尾
三件事最有效：指定一个能拍板的业务负责人、把验收标准写成可操作动作、约定每两周一次演示。需求变更不怕，怕的是口头变更没有记录，最后双方对「做完了」的定义不一致。