单应用结构越长越乱
模块越多，所有代码都堆在一个 app 里会让 ownership 和重构成本持续上升。
Stack / Monorepo Architecture
让产品面与共享包在真实增长中依然清晰可维护的 monorepo 架构
BunShip 使用 Bun 与 Turborepo 组织 marketing、app、admin、docs 与 shared packages，让系统随着模块增长依然保持边界清晰，而不是变成一个难维护的大仓库。
- shared packages 边界明确
- marketing、app、admin 共处一个 workspace
- docs 与 blocks 可以独立演进
- 更适合持续交付与安全重构
10+
Workspace packages
UI、data、contracts 与 app surfaces 的职责更容易保持清晰。
3
用户面
marketing、app、admin 不会被塞进一个巨大目录树。
1
系统模型
产品可以沿着 package 边界演进，而不是不断返工结构。
重点不是为了显得“高级”而用 monorepo，而是为了保持功能归属、共享包边界与交付流程可理解。
重点不是为了显得“高级”而用 monorepo，而是为了保持功能归属、共享包边界与交付流程可理解。
共享 UI 包共享 DB 包App 边界Docs 集成
这个页面要解决什么问题
架构页应该回答技术评估问题，而不是去和销售型功能页争抢转化叙事。
共享代码没有边界
团队需要 package-level contracts，而不是到处随意 import。
docs 和 product 越走越远
monorepo 能让 docs、UI、app logic 与 shared packages 保持在一个系统里。
What's included
这个页面只讲 workspace 与 package 架构，不去泛化成 feature 营销页。
Bun + Turborepo workspace
应用面与 shared packages 可以相对独立地演进。
应用面分离
marketing、app、admin、docs 处在同一产品系统中，但职责更清楚。
共享 contracts 与 utilities
UI、data 与 common behavior 被抽成可复用包。
Why it matters
这页服务技术尽调，不应该和 feature pages 抢同一层意图。
提高可维护性
新增模块和替换实现时，package ownership 更容易控制。
支持更快交付
marketing、product、admin 可以共用基础能力，减少重复。
增强实现可信度
让买家看到 BunShip 是一个系统，而不是很多页面的拼装。
Implementation notes
更深的技术细节交给 docs，这页只保留架构层信息。
Who it's for
适合关心长期维护性和代码结构的技术买家。
技术型创始人
在决定长期以 BunShip 为基座前，先看清系统如何组织。
创业团队技术负责人
判断 package 边界是否适合团队增长和模块扩张。
Agency 团队
理解 shared packages 如何支撑重复交付。
FAQ
保持它只承接 architecture-specific intent，不和产品功能页重叠。
Next step
把这页当技术尽调入口，再回到更广的架构或商业叙事
继续看 codebase docs，或返回 stacks 总览。