一个商家的难题是一个功能；十个商家的难题是一个产品。私有应用（custom app）对公开应用（public app）的决策看起来像技术选择——代码放哪、要哪些 API scope、谁付托管费——但它实际上是产品决策：软件为谁服务、怎么卖、你承诺维护什么。往私有方向选错，你建了一个没人用的产品却按产品成本维护；往公开方向选错，你签下了从没要过的支持、分发和升级义务。
问题背后的那个问题
当客户要一个应用，真正的问题是：这是一次性的工作流，还是可复用的能力？ 答案决定下游的一切。追问客户三个问题：
- “这个问题存在于这家店之外吗？” 他们的仓库、审批链、定制定价是功能；同垂直的商家下周会撞上同样的工作流，是产品。
- “愿意以订阅形式、由别人维护地再付费吗？” 一次性构建加免费维护是功能；持续的付费意愿是产品的种子。
- “两年后谁来支持它？” 诚实的答案是“你，花你的钱”，就是功能。产品需要支持预算、SLA 和路线图。
一个决策框架
五个轴打分，三个及以上落在“产品”侧，就该考虑公开应用（或产品化的私有应用）：
- 可复用性。 需求能泛化、靠配置跨店工作，还是代码里写着客户的名字？
- 分发。 公开应用有 App Store 的分发、审核和列表；私有应用只活在一家店上。
- 维护面。 公开应用按 Shopify 的节奏面对 API 版本更替；私有应用按你的节奏，但维护依然存在——只是隐形且没有预算。
- 数据与 scope。 私有应用可安静申请所需 scope；公开应用要过审核，对数据使用和隐私期待更严。
- 商业模式。 公开应用是生意：营销、获客、流失；私有应用是交付物：构建、移交、开票。
陷阱在中间：一个建得“好到能当产品”的私有应用——共享组件、通用设置——却按一次性项目卖，用功能的收入承担产品的成本。既然在泛化，就把定价产品化；既然按功能定价，就别再泛化。
代码是一样的；契约不一样
技术上两者同源：HTTPS 托管的嵌入式应用、Admin API 的 OAuth、scope、webhooks、后台 UI。差别是契约性的：私有应用经 setup URL 逐店安装，公开应用走 App Store 分发并过列表审核（unlisted 是中间路径：用 URL 分发、不上列表）；公开应用被钉在 API 版本上，须按 Shopify 的节奏升级（版本一年后弃用），私有应用的升级时机由你掌控；公开应用过应用审核，是文档、隐私和数据卫生的强制力；两者都在 Partner 账户下，但公开应用有列表归属和分发分析，改变了你对谁负责。
经验法则：说不出第二个买家，是功能——按私有应用建并据此定价；能说出五个，是产品——按公开应用建，把支持和分发当一级成本。 一到五之间，你选的是商业模式，不是代码库，选择要明确而非偶然。
答案会变
决定不是永久的。一个不断被新客户点名的私有应用是披着外衣的产品——三个商家问起同一工作流时经济账就翻转，公开应用成为理性路径；反之，除了第一个客户没人用的公开应用，收成受维护的私有应用或 retainer 才是诚实的做法。
什么时候需要外部帮助
如果你正在私有构建和公开应用之间做决定，或已建了中间的东西说不清它站在哪一侧——一次有边界的架构与产品评审可以梳理需求、分发选项和维护经济账，给出带着数字的推荐。两个方向选错都昂贵，评审是投入构建前便宜的保险。带着那三个客户问题来预约 Commerce Architecture Review。