做了大半年应用升级项目，我越想越慌：这难道真的是自嗨？

[songangweb]

做了大半年项目，我越想越慌：这难道真的是自嗨？

从敲下第一行代码到现在，整整八个月。当初信心满满要做“解决所有应用升级痛点”的 UpgradeLink ，如今功能堆了一大堆，我却对着后台数据反复发呆——这些我熬夜打磨的功能，真的有人需要吗？越复盘，越觉得自己可能陷入了“自嗨式研发”的陷阱。今天把项目的所有进展摊开，想问问屏幕前的你：我到底错在哪了？

一、我花大力气做的全端支持，是不是“为了全面而全面”？

项目初期，我笃定“全端覆盖”是核心竞争力——毕竟自己之前踩过跨端升级的坑，就想当然觉得大家都需要。于是做了全平台适配：

• 安卓、Mac 、Windows 、Linux 四大系统，每个都开发了专属升级策略管理模块。可现在回头看，后台数据里 Linux 升级数据占比还不到 3%。
• 特意适配了 Tauri 和 Electron 框架，花时间研究官方接口，做到“无缝对接”，想着能帮开发者省重构代码的功夫。可在与相关开源项目开发者聊的时候，开发者要么觉得“原有升级方式够用”，要么根本不知道这个特性存在；
• 还做了 URL 升级、文件更新、JSON 配置在线更新三种模式，想着能覆盖工具类、配置型等不同应用场景。结果呢？ 80%的用户只用了最基础的“文件升级”，剩下两种模式的使用量几乎可以忽略不计。

我当时觉得“多一个功能就多一份竞争力”，可现在才发现没问过用户“这些功能你真的需要吗？”

二、那些自认为“直击痛点”的特性，是不是我的“一厢情愿”？

除了全端支持，我还针对不同行业做了“痛点特性”，现在却越想越心虚：

• 灰度发布：我觉得“小范围验证+逐步放量”能帮研发团队控风险，特意做了精细化的放量节奏设置。可对接的科技公司客户，只用了最基础的“10%用户先测”，那些复杂的节奏配置完全没碰过；有次我主动问他们需不需要再深入开发一些功能，对方说“没必要，简单能用就行”；
• 流量控制：为电商平台大促场景设计的，能根据服务器承载能力调整升级流量。可实际合作中，他们反馈“大促时更关注服务器稳定性，宁愿暂时不推升级，也不想多一个变量”；
• 机型/设备分组升级：为智能家居企业做的定向升级功能，想着能解决老旧机型适配和数据安全问题。得到的反馈，更像是礼貌性的肯定——后来我看他们的更新日志，发现大部分版本还是全量推送。

这些我当初认为“能解决很多问题”的功能，最后要么被闲置，要么只用到了皮毛。我是不是把“自己认为的痛点”，当成了“用户真的有的痛点”？

结尾：求大家给点实在的建议

八个月的时间，我从“信心满满”做到“自我怀疑”，看着后台一堆“没人用的功能”，看着那些“礼貌性的反馈”，我忍不住问自己：这大半年是不是真的在自嗨？

我列了所有我认为“有用”的功能，也说了我的困惑：是功能太复杂，用户用不懂？还是我根本没找对目标用户？是需求挖掘错了，还是推广方式有问题？

如果你是开发者，你会用这样的升级系统吗？如果你是企业负责人，你觉得这些功能有吸引力吗？如果你也做过类似的项目，有没有踩过同样的坑？

求大家别客气，不管是批评还是建议，哪怕是骂我“闭门造车”都好，只要是实在的想法，我都愿意听。毕竟，我不想再花更多时间，做一个“自嗨式”的无用产品了。

[livib]

从你这个帖子里我看不出来你的产品核心竞争力在哪里，我想问：
你的核心用户群体是什么（开发者？），到底能帮助用户解决什么问题，相较于同类型的解决方案你能不能做到更好用更可靠？

[songangweb]

@livib 用户是需要搭建应用升级服务的企业，核心就是帮大家省掉从零开发的成本，多端（安卓 / Windows 等）和 Tauri/Electron 框架都能直接适配。优势的话：完全开源，GitHub 上目前没有同类完整解决方案，

[cnhongwei]

用户群体不一样，当然关注点不一样，你是技术人员，当然想得各种复杂场景。但对普通用户来说，你说越复杂，对他来说，越担心出问题，如果系统简单到只有一个开和关，用户是最开心的了。
所以你这大半年自嗨的确是真的。
所以我喜欢用苹果，现在除了闹钟不支持节假日，其它来说，对我就够了，能打电话，收短信，上上网，扫二维码，广告少点。Android 的各种炫酷对我来说没有用，我的生活没有丰富到要手机、AI 来辅助我，其它苹果的拍照，视频等功能对我都是多余了。

[xianyulaoye]

是不是自嗨取决于你的用户量，你的同行，以及取决于你的市场地位。

[Kholin]

市场是残酷的，调整心态，这个不行就换个领域。我看了下你做的东西，个人感觉应用范围过窄了，感觉就像是你在之前某家公司遇到的问题，你觉得可能所有公司都会遇到，然后希望用某种通用的方式来解决。一方面这个问题可能本身就比较特殊，并非所有企业都有，另一方面他的解决方案有很多种，本身技术难度也不高，尤其在这种 AI 可以解决绝大多数普通问题的情况下。而且能看出你这个项目本身也是有不少 AI 痕迹的，这就大大降低了竞争力。既然你能轻松用 AI 做到，别人为什么不能？

[weixind]

你说的这个领域是有刚需的，但是个人感觉不会是 saas 或者工具的市场。

存在一个很大的问题。小厂没必要用，对小厂来说有点是超前的基建了。

大厂只会自建，因为大厂需要更复杂的灰度和 AB 测之类的功能。

[songangweb]

@xianyulaoye 现在就是感觉宣传也宣传不上去，用户量的话增长的很慢

[crocoBaby]

大概率你这大半年时间浪费了,好处是你技术广度提升了

[systemGuest]

灰度发布、流量控制，市面上找 100 家小公司估计关注这个的凤毛麟角，因为本身就没什么流量。
小公司他们为什么要折腾这个？
大公司他们自己没有？
我感觉，使用这个东西的人都是图个新鲜感，可能有好奇心的技术偏多。

[songangweb]

@Kholin 确实是你说到的这种情况，开始的目的就是想搞出来一套能够通用的方式来解决应用升级的问题。

[songangweb]

@weixind 相对中间一些体量的公司，你觉得有实用的可能吗？

[weixind]

@songangweb #11

刚好在一家中等体量的公司做过类似的事情。灰度、AB 测其实是和业务贴合的很紧密。而且和部署方式绑定的，还要考虑回滚等逻辑。最多会借鉴开源的技术方案，但是不会使用开源的服务。

[dianso]

没用，完全没用

[christmasin2015]

我看了半天，还看了历史帖子，所以你这是一个 “客户端版本控制工具” 吗？

在讲点商业上的，op 你的目标是赚钱，那第一个问题是你要赚谁的钱？你要找的这些人在哪儿。
再然后，你至少要保证这批人能够明白你提供了什么东西（是不是痛点另外说）

最后在商业上 “开源” 不是你的优势，你的优势应该是雄厚的资金，高水平的团队，过硬的政府关系

[songangweb]

@christmasin2015 原本的想法是做开源宣传项目，然后有一套搭配的企业版本，可以让使用企业不需要自己部署，因为 CDN 本身流量很贵，让接入企业复用 CDN 带宽，减少企业的 CDN 带宽成本，我这边能够稍微挣一点利润

[songangweb]

@weixind 也就是说，即使是中等体量的公司，我当前实现的功能，依然远远满足不了你说到的这些实际情况。

是因为我这个系统太过于独立，无法与公司内部的相关已有大数据同哦，AB 测试数据统计，无法达到联动的效果是吧？

[TrackBack]

你想商业化，应该先找到客户需要什么，然后尽快搓一个糙但是别人愿意付费的 MVP, 再根据客户需求加功能
然后你的 README 和宣传帖写的其实都不好，看了半天都不知道是做什么的，表里每个平台都写一个“专属升级策略模块”简直是废话

按我目前的理解你的升级服务是必须部署一个服务端的，这对用户是一个很大的技术成本，开源项目习惯白嫖 github 等平台根本不会用，小厂为一个更新增加和维护一个额外服务感觉不是很有必要
我的建议是把 client-side 的 sdk 改改支持无服务端（直接检测 github release 或者用户设定的 url ），只做一个方便接入、广泛支持的 dumb updater （光这一点就够在众多项目里脱颖而出了），让更多项目能很低成本、很方便地引入进来，先把吆喝赚到
然后再为有更多策略和统计需求的企业用户提供付费/定制的服务端

[NewYear]

@drymonfidelia

帖子不符合[分享创造]节点要求，这里是分享作品的。希望移动到问答节点或者其他节点。