11个主要的市场营销渠道

每个月，我会把星球上的和问答，摘录3篇发到公众号。以下是这个月我要分享的内容。

11个主要的

IndieHackers 上面的这篇文章，总结了 11 个市场营销的渠道。

地址：http://indiehackers.com/post/11-marketing-channels-that-consistently-work-for-founders-8992a89a03

• Product Hunt/Beta List

• App 应用市场

• Reddit

• Email 冷启动

• “Powered By” 市场

• Hacker News

• 用户自传播

  

• 软件推荐名单

• Upwork 等兼职平台

并不适合所有的产品，作为个人或者小团队的话，能专注于其中一个并做出效果就很厉害了。

开发的时候的保留项、冗余的成本

老板说，这个功能我们现在不开发，但是你要留好未来拓展的选项，方便到时候直接拓展，减少开发和重构的成本。

这个时候，涉及到取舍问题，主要需要考虑的是，老板说的这个功能，到底什么时候能真的上。

在现有的基础上为未来可能的功能考虑，是有成本的。架构都可能不一样，开发人员的因此增加工时加起来可能也不少。

一开始架构时，确实要考虑到后期增加功能的可能性，但在架构上，现在是否要以此做设计，就需要综合判断。

主要是判断成本，判断这个功能，实际上大概什么时候能上。

这个什么时候能上，不能以老板说的为准，我见过老板说2个月要上的，所以代码里一直保留着迁移过来的部分代码，最后因为各种老问题、新问题、新需求、新计划，结果2年了，也没有上，最后重构的时候，直接砍掉。

如果是作为个人开发者，自己做小产品，那就更要避免这种情况。

小产品，关键是要小，不要在做小东西的时候，给自己太多的冗余处理的逻辑。

我的经验是，一般我说现在这个功能做成这样，但是我后面还要增加什么什么，这个功能真的加上，有时候都是一年之后了，保留字段的含义、业务逻辑都已经忘得差不多了。

有时候我想，我写好文档，写好注释，就可以避免这个问题。但实际上，我以为我下周就会增加的功能，压根不会写文档写注释，即使写了，能否详细到一年后自己还能看懂？

我举一个简单的例子，我之前做了一个优惠码的逻辑，在库有1个关于时间的字段，过期时间，前端也是按照这个逻辑做的。

后来我觉得还应该加上，开始显示的时间和结束显示的时间，所以在数据库又加了这两个字段。

仅仅这一个，导致我每次需要做优惠活动的时候，我都要去检查前端代码，看我自己是否使用了这两个字段来做判断，来看我是否需要，修改数据库这两个字段的值。

因为我老是忘记，每次确认都要花费一些时间，我又怕麻烦，所以很多时候，索性就不做优惠活动。作为个人小产品，正确的做法当然是尽量简单，我后来直接从数据库把这两个字段删掉了。

App Store Connect 中，技术支持网址怎么填？

以前我是这样做的：自己写一个官网网站，就普通的js、css和 html，写好之后，部署到阿里云，放在 tomcat 下。域名在阿里云买，域名备案，绑定好域名，一个网站就做好了。然后把网址填到技术支持网站那一栏。耗时 2周。

后来我是这样做的：域名在 NameCheap 上面买，建站直接用 Vercel + GitHub，使用 Vercel 推荐的模板框架，改改内容，网站就做好了。耗时 2小时。

现在我是这样做的：在 Notion 上新开一个 page，写上 app 下载地址和联系方式，然后复制分享链接，一个技术支持网站就做好了。耗时 5 分钟。

全文完，既然看到这里了，如果觉得不错，随手点个赞和“在看”吧。

如果转载本文，文末务必注明：“转自微信公众号：我是陈大壮”。