千万不要低估内部系统对企业工作的影响力！根据《深度解读：2021 海外企业「内部系统」现状》，在超过 10 人的公司里，每 3 个员工中就有 1 人在使用由开发人员建立的内部应用程序。随着内部系统的重要性日渐提升，到底是选择「自己搭建内部系统」还是「花钱购买」成了许多公司的难题。
如何才能最好地分配开发人员的时间呢？专家表示：「我们首先要明确一点，自己搭建内部系统还是花钱购买其实是一个假两难推理，它们不应该是互斥的，我们要视情况而定，尤其是当使用低代码平台进行内部系统开发的时候，这时自己搭建也可能会需要一些平台的付费服务，所以花钱与否的界限并不清晰」。
低代码平台 Retool 公司曾咨询了三位专家，以了解他们是如何考虑「自己搭建」与「购买」问题的，三位专家都来自专注于技术受众的软件公司。这里码匠总结了三位专家的观点供读者参考，大家有什么想法也欢迎评论区讨论。

Halp：直接花钱

Halp 前 CTO Andrew Homeyer 建议直接花钱使用低代码平台来搭建内部系统。
「事实上我们是自己搭建内部系统的，而且我们使用的是低代码平台」。据 Homeyer 说，低代码平台允许开发者一起构思操作解决方案，听起来有些不可思议，但搭出来的程序都很有用。而且对 Halp 来说，一个能快速解决问题的系统很重要。
通过低代码平台，Halp 可以将开发的过程与结果脱离。「这种感觉超棒！」，Homeyer说，「开发人员所要做的就是对着电脑下指令，然后程序就会按照你的要求执行」。 这就是低代码平台的魅力所在，「给出命令，得到结果」，细节什么的交给平台就好了。
问：我们应该如何给销售部和市场部定制特定需求下的应用程序？
Halp 希望即使是非技术人员也能参与到搭建内部系统的工作中来。Halp 是软件即服务（SaaS）的重度依赖用户，他们使用 Segment、Workato、Salesforce 和 Autopilot 等产品力求创造一个好用的客户关系管理工具。但是 Halp 发现这些程序只有那些直接与客户对接的员工参与搭建、不断迭代，才能发挥出最好的效果，毕竟他们真正知道什么样的功能才能满足工作需求。这也是为什么 Halp 选择低代码平台的原因：销售人员和市场同学都能参与到内部系的搭建中来。
Homeyer 认为主要是「我们应如何确保销售和市场等部门的同学能够按照自己的业务需求去修改应用程序」。直到 Halp 开始使用低代码平台，他们才真正实现了以需求和目标为前提来搭建好用的内部系统。如今 Halp 已经开发出了许多不同的内部工具，尤其是用于数据管理的系统，其中有一个帮助整理公司账单结构的程序，得到了公司内部的广泛好评。
Halp 使用 Stripe 进行用户订阅，据 Homeyer 说「总有些小问题」，比如可能需要给某些客户分配一个特定的折扣，有些客户可能需要延长试用期，还有的客户可能在续订的时候会遇到一些问题。其中有些问题在 Stripe 中无法解决，或者说是不容易解决，Halp 的开发人员往往需要进入 Stripe 的数据库，长此以往肯定是不现实的。Homeyer 表示「我们不希望工程师长期访问数据库，这不安全，很容易出意外」。
总之，Halp 搭建内部系统的思路就是要建立一个轻量级系统，使团队中的每一个人都能进行修改。例如，如果他们只需要输入一串优惠券兑换码，所涉及的只是填一个文本字段。「我们只花了5分钟就做好了这个功能，一劳永逸的那种」。

On Deck: 先自己搭建再花钱

On Deck 的高级软件工程师 Curtis Cummings 建议：先尝试自己搭建，不行再购买。
Cummings 说：「On Deck的做法与我在其他大多数初创公司看到的有所不同」。在确认一个定制的解决方案之前，On Deck 会先用低代码平台搭一个小的最简化可实行产品（MVP）。为什么要这样做呢？根据 Cummings 的说法：「这个简单的 MVP 能让你完成 70% 到 80% 的工作，而这 70% 到 80% 的进展往往能为最后正式的解决方案提供不少建议。」
实际上当你构建那 70% 到 80% 时会更明确最后的目的，「你会怎样处理用户数据？这样处理是否合理？还有没有其他需要改进的地方？」。像这样在 MVP 的基础上进行思考，然后完善剩下的 20% 到 30%，一个好用的解决方案或者说内部系统就完成了。
要逐一评估！
涉及到搭建内部系统的问题时 Cummings 十分谨慎，他说他最不希望的就是「辛苦做出来的东西没人愿意用」，这也是 Cummings 之前做咨询工作的时候最不愿意面对的。在他做咨询师的时候，有许多这样的例子，「我们明明是按照行业标准构建，然后再向用户推广的，所有流程中规中矩，但最后的数据都非常难看。因为这些『行业标准』都是所谓的专家建议，他们并没有站在实际用户的角度考虑问题，更没有以实际的用户数据为依据。」
Cummings 表示，通过购买一个低代码平台并利用它建立 MVP，On Deck 可以在投入大量开发资源之前验证这个想法的可行性。开发资源是昂贵的，所以在进行任何投资前都应仔细评估。Cummings 再三强调：「不要抱有侥幸心理，请务必逐一评估内部系统开发方案」。
上述建议的提出是 On Deck 结合购买解决方案和用低代码平台自己构建解决方案的利弊之后提出的。On Deck 主要使用的低代码平台有 Zapier、Airtable 和 Retool。此外 On Deck 还利用低代码平台为运营团队搭建了许多好用的工具以帮助他们进行项目管理，如会员管理系统，在此基础上，他们还建立了一个轻量级的内容管理系统（CMS）用来向会员发送每周上新。

Auth0: 情况不同，选择不同

Auth0 的一位产品经理 Sole Pano 说，「自己搭建」还是「花钱购买」取决于公司正处于哪一阶段。
据 Pano 说，对于一个初创公司来说往往预算少，要求也少。「也许你们目前只需要一个包含『向客户发送通知功能』的应用」，Pano 举例说，「初创公司的客户可能并不多，所以短期内并不需要进行功能上的扩展，不如自己上手搭建，又快又划算，等到公司初具规模后再进行扩展也不迟」。
注意！今天的方案不一定适用于明天的问题。
随着公司不断发展，各种各样的要求也会不断增多，有些特殊问题需要特殊的「内部系统」帮忙解决。Pano 认为在搭建这些内部工具时安全性和合法性是首要关注的问题，但除此之外，Pano 表示「你还应该考虑不断增长的客户和需求，这也将是一项大工程」。
「当客户数量增加时，之前的解决方案在某些问题上可能就不起作用了」，Pano 说到，「然后你就会一直卡在那，那我到底是马上把整个应用重构呢还是直接花钱再让别人帮我们做个新的来的快呢」
所以到底是「自食其力」还是「花钱购买」，这个问题会随着公司的发展而不断发生变化：公司越大客户越多，客户越多赚的越多，要求也越多。Pano 说，「只要你愿意且负担得起，花钱的东西确实会比我们自己做的要好上十倍百倍」。
不管是自己搭内部系统还是花钱买服务，Auth0 都尝试过，全公司上下也有许多使用内部工具的场景。Pano 还补充到：「当然，除非你对某项功能的要求非常细致，这时候自己搭的内部程序才能真正满足你的要求并解决问题」。
目前 Auth0 已经建立了与客户订阅管理和与 Stripe、Salesforce 等系统集成有关的自动化工具。这些内部工具还帮助他们管理了客户环境，包括资源调配和控制管理等。Pano 举例说：「为了帮客户处理票务问题。Auth0 建立了一个安全合规的内部程序。有了这个工具，客户成功团队可以看到客户环境的配置，并为他们的决策提供精确有效的数据支持。」

自己搭建还是花钱购买 - 你中有我而不是非此即彼

这个问题的答案不是非此即彼的，就像 Auth0 说答案会随着公司的成长而发生变化；On Deck 说答案会根据 MVP 的作用与成本发生变化；Halp 认为答案是两者都有：花钱购买低代码工具并使用它们来构建内部系统。
具体情况具体分析，在这之前不妨先问问自己「你的公司有多大？你需要建立一个 MVP 吗？你需要建立多少内部工具？又打算花多少时间呢？」

在了解了三家国外公司对于内部系统建设的考量后，在这里向您介绍下码匠：码匠是一款国内研发的开发者友好的低代码平台，您无需了解 React/Vue 等框架的开发、部署等各种细节，就可以快速打通前后端，连接 REST API、MySQL、MongoDB 等多种数据源，然后通过一套开箱即用的组件，轻松搭建功能完善的数据看板、数据洞察、Admin 管理后台等多种应用。

使用码匠快速搭建 CRM 系统（具体可参考：https://majiang.co/templates/mysql-crm）