这是对于自己的一次 2 年的副业项目的一次复盘，希望对于那些没有经验的小伙伴，能够避免自己曾走过的坑
今天复盘的项目是给用户快速搭建落地页、营销页的平台。大致长这样

缘起
先介绍为什么开发这个项目。大概从 2020 年，从大厂离职之后， 就一直想开发一个自己的产品。由于之前开发过类似的产品，也看到这件产品对于运营的价值，而且移动互联网是所有流量的入口，那么，快速搭建落地页，必然有其需求。
项目过程
为了区分与其他平台的区别，增加这个项目的核心竞争力，开发了一个功能， 能够让用户可以自定义开发模板以及组件的功能， 让他们开发自己的业务组件， 发布到平台去搭建，也是自认为这个平台最具价值的点之一。但是， 也是因为这个功能，给后续一些迭代埋下了很多坑， 走了很多弯路
项目过程大致是这样的

2020 开始着手搭建整个平台的雏形， 因为要加上自定义组件开发能力，所以，大部分时间是花在如何能让用户开发组件，制定组件的规范，以及组件在平台上如何渲染可编辑等等这些技术方案的预研和制定上。这个大概花了一年的时间，才大致有了一个轮廓。在年底注册了一个公司， 买了一些服务器设备，初步将环境搭建起来
2021 年，基于上一年的技术方案，开始做整个平台设计开发， 包括交互、视觉稿的设计，还有服务端以及前端的开发，以及整体的一个运行时开发包，还有本地研发调试的工具等等一系列配置。由于东西也很多，本人在业余时间进行开发， 所以，大致花了一年，也只是勉强开发到 80%左右，还是只是很粗糙的勉强可运行
2022 年， 在基于上一年的基础上， 继续将其余的一些功能开发完毕。但是， 这个时候，程序员的洁癖就出来了。由于，不满意其中的一些技术设计，以及整个视觉方案，将很多的东西，在原有的基础上进行重新抽象，而且，在重构的过程中，想的东西越来越多， 就不断的去叠加一些功能，觉得要做到自己满意为止。就这样，整个一年都在推到重构当作去做。所以，为什么说自定义开发的功能是坑， 因为，大部分的技术改造，全部集中在这个部分。认为既然是面向自定义组件开发，那么，在技术方案上，一定要做到满意为止才行，所以，花费太多时间在做这些自我构想的功能上
2023 年，做最后的技术优化以及调整，大概在 6 月发布。可想而知的是什么，用户很少，零星会来用。因为，你的核心卖点是开发能力，但是，这部分能力，用户没法直观的去感受到， 觉得，只是做了还行的落地页搭建，相比其他产品也没有优势，就逐渐放弃了。

项目复盘
下面进入整个项目的复盘
问：为什么这个项目最终结果不怎么样？
答：因为这个项目在外人看来没有核心的特点，甚至相比于其他产品，更有点粗糙。也忽略 build in public 这个原则，导致很少人知道
问：这个项目是否本身就没有价值？
答：这个感觉看场景，因为在自己呆过的 2 个公司，都对这个项目有很大依赖程序，对业务的帮助很大。这个项目只适合有研发能力的 2B 公司，面向 C 端的这种开发能力，没有应用场景，反而将项目本身做的过于笨重
问： 这个项目为什么没有继续下去了？
答：因为这件事情已耗费了自己太多的精力和时间，而且也看不到这种自定义研发组件的功能的卖点对用户的吸引力，大部分用户也不需要。相比于其他的产品， 这件产品， 有点鸡肋， 做不了太复杂酷炫的效果。如果核心功能没有需求，感觉还是尽早放弃
问：这个项目持续了很长时间，为什么不先进行 MVP 原则开发，尽早失败？
答：MVP 原则其实自己一直都明白的， 但是，在这个项目实行起来却很难。因为这里的核心功能是自定义组件开发， 而这本身就是需要一套比较完善的技术方案来支撑，而不是简单 CRUD 的业务逻辑。所以，在构想以及优化这套技术方案，再去整合到整个平台中的时候，就耗费了很长的时间。因为不想用不成熟的技术推出去，为以后埋下一些坑。这也是因为自己的核心功能的定位，导致自己无法快速的推出以及验证
问：如果重新回到 2020 年开始的节点，会做出哪些不一样的抉择？
答：如果再回到那个时候，一定会先做最简单的版本，去实验一下，让别人体验这种自定义开发功能是否能符合市场。先做 PMF 。然后再决定是否进行投入。如果市场可行，重新设计方案都可以，而不是在市场未验证，却花费很多时间去做。
一些总结
从上面的分析看来， 其实，自己走进了一个闭门造车的怪圈。 加上自己因为的工作环境， 这件产品的确在公司当中有很高的价值，就盲目的意味，开发完成后就一定会有市场， 也忽略了前期的潜在用户的建设。
所以，本质上，还是自我认知的问题， 一件东西只有在合适的场景才会发生价值，在不一样的地方，就是一件很鸡肋的东西
通过这个项目，我学到了什么？

首先第一点，就是不要自己认为有价值的东西，就一定有价值。先去市场上验证一下
别盲目去投入太多时间，超过半年的，就很不值得。
尽早做营销，build in public. 即使是半成品，主功能没问题，也要去看看有没有用户和市场
别将时间都押注在一个项目，同时做做其他的方向，因为，失败是大概率的事情
将这些项目当作随时可丢弃的副业， 别看太重，不然，一旦没有效果，会给自己造成很大压力

以上即是对自己经受 2 年的项目复盘，没有多么高深的东西，反正， 一些很常识的坑，我用亲身经历去趟过了。 都是自己的切身体悟，大家可以从中借鉴或学习或吐槽~

再说几点1. 20%时间写代码，80%时间在推广、营销、SEO2. 别抓细节，一种让自己以为认真做事的错觉，其实，可能时间就这么溜掉了3. 别万全具备在行事，因为你的方向可能就是错的

一些朋友想了解下自定义组件的设计思路，准备写一些文章介绍下，抽空先写一篇。可视化组件拆解系列(一) - 从混沌到有序 mp.weixin.qq.com/s?__biz=MzkwODUyNDEyMQ==&mid=2247483740&idx=1&sn=30b112acf79ba04cb2d9ea1c1f1b1b25&chksm=c0c9ee6af7be677cc463ca955a11204aff08c2344d188eb07f683ae5f06452a3385c4855f3a2＃rd

感谢分享，未来的独立开发者很受用。

感谢分享

感谢，想做一个自己的产品的想法越来越强烈了，感谢分享经验

v2ex 有感谢功能的。。。
感谢分享，看得出来这篇文章都是自己深刻思考后写的，祝好。

谢谢，是的。 这的确是自己的亲身的经验教训， 也是人生必然的一种经历吧

看完了复盘，第一感觉是，开发了一个 ToB 的产品，然后面向 ToC 销售，是这样吗？有两个问题啊：1. 「这个项目只适合有研发能力的 2B 公司」，看起来还是能卖给企业？那还是有希望的，这块业务我不太懂。2. 「如果重新回到 2020 年。。一定会先做最简单的版本。。先做 PMF 」这个说法，跟你前面说的「为什么不先进行 MVP 原则开发。。因为自己的核心功能的定位，导致自己无法快速的推出以及验证」有些矛盾，之前认为不能做 MVP ，现在认为可以做 PMF ，那么 PMF 怎么做呢，按照你说的「先做最简单的版本，去实验一下」，这个你之前肯定也考虑到过的，只不过当时认为「核心功能是自定义组件开发。。需要一套比较完善的技术方案来支撑」，现在就不需要技术方案支撑了吗？这块没有看明白。OP 觉得如果现在让你推出一个最简单的版本，要做到什么程度，花多长时间呢？我觉得当局者迷，很多时候真正投入到一件事情的时候，很难看清做到什么程度算是可以推出的。我自己也是这样。

很感谢楼主分享的经历。真的很佩服楼主能坚持这么久昨晚一款产品。我总是喜欢自我怀疑，时不时冒出想法，但是越思考便越是怀疑可行性，最后不了了之，没有一款做完的产品。所以我很想知道楼主是怎么做到坚持这么久的？我的纠结点在于：关于独立开发流程，别人总是将实际开发放到很后面的阶段，前面都是设计、营销等阶段；可是，很多事情，又是需要在实际执行的过程中才会逐渐明晰。这两者并不冲突，但是我始终找不到两者之间的平衡点。

感谢告知。 /dog

其实我们是需要的，有开源或者授权计划吗

1. 的确是可以包装成私有化部署， 目前也有这个打算。但是， 基于目前的环境，不一定有潜在用户感兴趣。但是自己会试试看2. 是的，这也是自我认知的问题。 其实，完全做个简单版本的技术方案，先看看。 但是， 因为技术方案一旦开放，后面做兼容性就很麻烦。所以自己就认为需要先设计好。 如果，重来的话，可能先做一个简单版本的方案， 先试试效果，后面再慢慢迭代。 毕竟， 相比于技术， 验证市场，去验证这件产品有没有价值， 反而是更为重要的

你们有这种需求么， 这种产品对于 2B 公司还是很有价值的

20 年开始做，23 年才推广吗？ 这个进度太慢了。 实际应该 21 年就开始发布推广，先积攒了一批用户，看他们反馈再优化。项目拖了几年，市场就变了。

如果各位觉得公司对这种产品有需求，可以后续改造成私有化部署的方式

我们有个商城模块，但是 diy 页面的部分现在是抽离其他第三方的系统 niushop 的用在自己系统。总归存在版权方面的问题

是的， 因为自己也没有经验， 对于推广营销没有重视，再加上盲目的认为， 这件产品价值一定存在， 所以，就一拖再拖。 因为不是全职， 但这也不是理由。 反正，算是很深刻的教训吧

干活内容，感谢分享

考虑开源吗...也许可以在另一个地方发挥价值？

这个也得看看是否有地方需要，有兴趣的可以留言。我也有这方面的考虑。

我不一定有这个需求，但是如果开源了，我肯定帮忙 star 一下，😄

这种才是正儿八经的分享.

一旦模块需要开发知识，最后使用这个模块的还会是你（而不是运营）

哦，我看明白了，最初你是设计了一套详细的技术方案实现「自定义组件开发」，这块耗费了很多时间，后续 2022 年的技术方案重构、视觉重新设计也花了很多时间。时间倒流的话，实现「自定义组件开发」这个功能本身去验证 PMF ，可能几个月就搞定一个初版。那跟我＃7 楼想的还是不一样，我在＃7 楼表达的是软件功能本身的复杂度做到什么程度。

Mark ！收到！谢谢楼主！

感觉这种项目适合开源加商业的模式，开源推广加引流，商业提供增值服务

这个只要开发跟运营做好约定， 这个组件可以更改什么东西，开发根据规范做成配置化，那么，运营后续就能自己玩转起来了

是的， 这种就是在 2B 公司是有价值的。 本来我的想法是 saas 化， 就是不用部署， 就能使用这种能力。但是，公司不会将业务部署在你这上面，除非很简单的一些组件。否则，他们更愿意私有化部署以及做定制。

总结的都很精辟,程序员思维都是觉得我做了个最牛逼的产品,实际是别人都用不上.还是要挖掘需求,不要自己创造需求.初期要验证想法,有用户愿意买单再下大力气研发.

其实，这件产品的价值的确存在。我身边就是例子， 但是在错误的场景，这样的价值就不存在了

独立开发者做 to b 的项目太难，这个项目感觉至少还是一个小团队来做的比较好，包装一下搞个公司来运营

哥们你这个东西我 19 年带 4 人队 15 天做过一个，你这个怎么做 2 年的呢

感觉这个低代码项目不错啊，应该有市场才对

还是做海外吧

如果再回到那个时候，一定会先做最简单的版本，去实验一下，让别人体验这种自定义开发功能是否能符合市场 ， 我们现在老板让我们做的功能大部分是客户不会用的， 过度复杂化， 提过还不听

因为你做的可能是面向内部的，需求确定，要求简单。我基本上单独一个人，一个月就可以做出来。但是，因为是面向产品化，saas 化的方式去做， 导致很多技术方案面临很多问题，比如不同用户之前，这些资源如何隔离等等，还有，从前端，后端，设计基本上都是一个人做，还是业余时间，导致时间上耗费过长。

总结的很好，但据我之前的经验来看，即使知道问题就算再来一次也很难成功，有的时候感觉像是玄学样。 相比较而言，写代码还是太简单了。

@错人了，应该是 的

是的，但是，没有亲身经历过的人， 撞不到南墙，他还是会撞一次的。

感谢分享。我感觉独立开发者，做这种项目，更多的是打磨给别人写外包的脚手架。面向的用户是开发者自己就行了，什么拖拽编辑等等需求都不太强烈。

在某些厂里有用，不代表能推广。我现在再做一个飞书出来有意义吗？基本没有意义，放在各个小厂里面可能大家都自己会用，但是拿出去推广就没戏了

这也是最迷惑人的地方， 明明看到这个东西也有价值了， 但是， 你拿出去之后，就未必可行。这其中的玄学就很多了， 但是，主要还是自己在诸多方面都很不足吧

感谢分享，支持，v2 有你更精彩

这个思路，价值肯定是有价值的。但只是作为一个独立产品存在是否有价值值得商榷。我是做外贸建站的，我们自己包括我知道的我们的平行竞品内部都做过这个产品，或者说功能更合适。1.首先运营是个环，这个本文无关就不展开讲了，落地页只是环中的一个节点。做过或者说做的比较好的运营大抵都是需要前后串联的，对于 B 端用户以及有流程和既往套路的 C 端用户来说，东西本身没问题，但是怎么串进我原有流程是个很大的问题，一旦成本或者不可控因素过多就懒得折腾了。2.其次其实现在低代码建站/页面搭建的产品太多太多了，弱弱的说一句其实可能也许这东西也不是那么的有技术含量，但凡有点追求的 B 端都自己做了，这端是否能找到潜在用户存疑，是买一个不熟悉不可控也许二开还会有问题的，还是自己花点人力做一个，见仁见智。3.就近期我司遇到的运营端瓶颈来看，也许自己开发一个简陋的，功能、UI 、操作便捷性可能不如潜心打磨的这个好，但是运营说到底还是重内容，现在工具实在太多太多了，甚至 AI 建站出来之后，传统工具生存空间又被压缩了。唯工具论的运营到最后都会走近死胡同。大家现在不缺把页面搭起来的工具，缺怎么把内容做起来的工具。东西确实是好东西，但现在有个残酷的现实，我们自己随便拉几个人做出来的半成品落地页搭建，跟这个比很垃圾（我很坦诚），但是在总体流程上看，我能做起来，也能出内容和效果，就目前来看已经够了，无非就是难用点、搭起来慢点、bug 多点。。但是在运营这个需要长期滋养的领域，单个时间节点本身就没想象中额那么铭感。慢点就慢点，重点还是在内容。快挺重要的，但没想象中的那么重要。

是的， 这个很中肯。 现在运营已经有足够多的工具可以使用了。 主要就是这件产品，能否整合内部的流程，比如集成内部的商品系统，内部分群系统，优惠券系统，权限等等，快速的搭建生成跟自己业务紧密结合的系统，形成一套完整体系。这样的搭建工具，才会促成业务快速产生价值。而目前我们也是如此做的，也的确看到了价值。但是， 这样的系统，必然逃脱不了每个公司的集成定制化需求， 如果将搭建的能力抽离出来，在集成方面做到快速可扩展，才是这个产品的价值。但是，to B 这块东西，独立开发很难弄，除非你先走开源让他们先用起来，才能慢慢切入

独立开发者做中国的项目需要开公司吗

＃44 我的角度来看啊，现在目的和思路：1.抽离搭建页面的功能2.快速集成和拓展好，按照这个思路往下继续抽象一下1.抽离搭页面的功能，说白了也就是低代码建站，抽象到这一步，也就跟落地页没啥关系了，啥页面都能做，甚至建站。2.快速集成拓展，说白了就是可以自己搞插件抽象到这，我突然有点迷惑了，这不就是个傻瓜操作版的 WordPress 么？与其费劲巴拉的搞独立产品，我有点疑惑为啥不做成 WordPress 插件呢？简化下操作，在现有基础上丰富或者限制下功能范围做细分领域，也能满足需求啊？如果想做的只有表述出来以及我理解到的这些内容，我实在想不出来独立开发和做 WordPress 插件的优势在哪里。一个是论拓展以及兼容，个人或者小团队开发怎么跟 WordPress 打呢。一个是论低代码搭建，有现成的架子和基础为什么不用呢。固然 WordPress 现在也存在不少限制和缺点，但起码市场认可度高啊，而且潜在用户也多，接入相对也没什么成本。更何况自己从头搞缺点未必就比他少

你可以理解为，你将平时需要开发才能完成的业务，做成了一套可以搭建的组件。也就是，将你们的业务代码，转换成了一套可以可视化组装起来的组件库。里面没有其他第三方平台的代码，我们做的只是，帮你们把业务通过搭建的方式组装起来。

感谢🙏总结分享！很有帮助

差不多理解了 复盘里有很多也确实是系统设计思路和开发过程中很经典的错误学习共勉

可能是因为自己想做完，也许是希望，也许是热情吧

核心问题就是把伪需求当作真需求，很多工具和低代码平台也是类似，有需求的用户要求高，倾向于自建，所以真实的需求其实很少。

的确是如此。 即使是真实的需求， 找到合适的场景， 也才会产生价值。如果，你看到了需求， 但是，选错了受众，这样的需求也就成了伪需求

感谢分享。技术是服务于业务的，然后业务增长驱动技术。

这是什么原型工具？

这不是原型工具，是直接成型的页面

低码平台其实不难，难就难在模板上，卖服务的收益远远没有卖内容收益大，就像知名的 135 编辑器，就是因为模板更新快又丰富，赚麻了。

不管怎么说,你都攒了一大波开发的经验~

感觉你很适合我们团队啊，要不要谈一谈，说不定我可以给你拉到用户

都这么说了，算是吧😂 但是，最终还是想拿到一些结果的吧

你是什么团队啊

做低代码的初创团队，我首页有联系方式

mvp 是必须的，快速验证试水

感谢分享。

纯前端吗

完整的产品， 服务端前端都有

op 的“产品”其实本身是一个很有价值的项目，市场上也有很多类似的商业化产品；有两个方面，一方面是纯内容 CMS 搭建，强调内容展示。在互联网公司其实是有需求希望中，可以应用嵌入到 App 专题页、频道页；通过模块化组织，搭建出整体页面。这类由于业务诉求差异非常大，所以模块内容的丰富度，和模块的可拓展性和使用便捷性是核心；（上半年写需求就涉及到 App 上的活动页，频道页抽象出组件库，以满足不同业务场景的内容展示需求；）另一方面，链接到公司业务实践中，比如与公司业务营销中心可以构建出各类活动页面（类似产品有曾经的活动盒子）。与商品系统、店铺系统构建出商品详情、店铺详情页。这类就是更深层的公司诉求（但这类往往公司偏向于自研），但如果能嵌入到深层业务上，会有长期现金流。总的来说，这类需求方应该都偏互联网初期阶段，公司从 0 到一或快速发展中，都会面临 C 端内容构建的问题，会逐渐从粗放发展到精细化，如果在这个过程中，想办法能将产品嵌入进去，或许也能有出路。

看了分享，感觉是那种老生常谈的“开发做项目”的常见案例虽然我自己也是，一起努力

谢谢分享！很宝贵的经验！

OP 说如果重来一遍，做法就会不同，这表示 OP 确实在反思。也许，可能包括我在内，很多 V2EX 的朋友都和 OP 一样，人生的一段宝贵时光不知不觉就花掉了，还记得曾经那个讨论需求改代码的夜吗？ 也许已经不记得了。祝 OP 能再接再厉，做出更好的产品。

是的，我们目前的业务就是整合到整个公司的业务链条中的。这样你就快速搭建出商品营销、优惠券营销，大促营销等等一系列，完全属于整个公司自己的业务。而不是，简单的内容展示。 所以说，这个产品只有在 B 端集成才能发挥价值

时间也不会倒流，可能， 这些体悟可能让其他人少走点弯路吧

想知道这个页面和商品的逻辑怎么关联起来呢？例如猜你喜欢模块下面的商品，是需要每一个都上传图片，设置标题价格这些内容，然后再填一个商品详情页面的链接，点击就跳转链接？还是说可以关联选择现有商品？

我们目前是直接开发一个商品组件。公司内部有商品的系统， 在这个组件里面去请求这些商品数据， 商品组件可以在搭建的时候，透出一些可编辑的选项，可以是商品 ID ， 商品的分类等等， 那么， 通过商品组件以及搭配可编辑的选项，就能做到很多的商品展示的场景了。按业务需求来做定制

Mark 一下，感谢分享！

有一点疑问，也是我比较顾虑的，就是副业做的东西，让当前供职的公司用，这个会不会有什么风险？比如1. 很难界定是不是工作产出2. 遇到问题和新需求的时候，需要公司的业务先停下来，等业务时间再去解决这个项目的问题吗？

打错了，是业余时间

当前公司并不是用这个产品，只是技术的理念是一样的。 一个是基于 Vue 技术栈，但是，目前自己开发的是基于 React 技术栈。 我后面其实打算出一个开源版本，如果用私有化部署，有源码，使用自己的服务资源的话，应该就不会有太大的顾虑。

初创过程，资源有限，时间窗口有限，不用也不要追求尽善尽美先考虑理想中的产品，如何和受众连接，提前从受众角度找到合作阻碍，一个个解决 - 销售思维

的确是如此。 程序员的思维惯性， 很容易陷入到打磨产品的舒适圈里，而不是将时间放在如何连接用户和销售上。

比如采访下公司的运营，外面市面上这样一款工具，会直接拿到业务上用吗？如果不会，是因为什么，会经历什么，他们会怎么解决这个痛点答案可能就比如。不会，得先确认功能好不好用（自己），还得确认能不能对接我们系统（涉及技术部门），还得确认采购费用（财务部门），还得提申请等审批（领导），还得问这玩意能带来啥收益（得输出可行性报告），还得谈进一步细则（ xx 部门），还得签合同（法务部门），还得调试。整个流程下来可能还有其他的。那我还不如直接找咱们技术开发呢，一步到位。 他这功能也不是非要不可

是的。 这个商业逻辑， 可能作为开发者， 从未遇到或者考虑过。以为仅仅只是开发出产品就够了。只是产品可能仅仅只是很小的一部分，更大的是，如何商业化的流程上的考虑

目前在处理公司内部前人留下的一个和楼主类似的项目，真的非常类似。但是没有文档，代码也非常杂乱不堪，各种自定义 json schema ，不知道用途的字段。这个项目公司内部已经停止维护很久了（因为维护不动）。考虑开源吗，想看看其他人的是怎么实现的

基本上属于是技术人员做项目常见的问题了，不过很感谢 OP 分享

私有 dsl ？从技术层面我就接受不了这个东西

其实，我也觉得些 json 比较繁琐，所以，做了一个声明式的描述。其实，开发只要维护好这份组件声明即可。差不多是这样，其他其实跟平时开发业务代码没有区别 github.com/akoomitech/round_lottery/blob/main/src/imk-component/ProductCardList/imkdef.js

的确如此，相信依旧还是很多人，会走同样的路。这种思维惯性，有时候就无意识的

可以看下网易云的 Tango ，看介绍没有私有 dsl ，基于 ESTree

＃85 声明式的描述，但是声明的字段没有文档，只能通过源码了解
楼主好，对自定义研发组件的技术细节感兴趣，有空的话能讲讲不，或者提供一些思路也好，甚至给一些搜索关键字也行哈，感谢~

如果感兴趣，我后面就写一些系列的文章，来说下自己的一些考量吧

项目立意很好，只是目前这类同质化的产品比较多。可以考虑出一系列文章，还是想学习下不同大牛的思路和实现方式。