用无代码起步，以后会不会推倒重来

同一个界面，两种做法

比较无代码和自研开发时，人们通常摊开一张功能清单：能不能注册会员，能不能接支付，有没有后台管理页。可这张清单得不出结论，因为如今的无代码工具对绝大多数条目都会回答”能”。

真正分开两者的是数据。自研的后端里，会员信息和订单记录躺在你自己签约的数据库中。无代码则把它们放在工具厂商的系统里，你只能通过对方提供的界面和导出功能去接触。单看界面，两个产品运行起来一模一样。差别要等到你和这家厂商的关系结束时才显现。

这里容易生出一个误读：以为无代码是权宜之计，自研才是正经做法。并非如此。预约登记、内部申请表单、小型商城这类数据结构简单、规模可预期的服务，用无代码运行好几年也不会出问题。之所以出现推倒重来，往往不是工具不好，而是产品朝着选型时没预料到的方向长了起来。

无代码真正卡住的三个位置

第一是费用随用量上涨的计价方式。无代码工具大多按记录条数、执行次数或席位计费。如果用户增长的同时收入也增长，这没有问题。但若免费用户占大头、付费转化只是一小部分，涨的只有成本，收入跟不上。算账不要用现在的套餐，要用用户数翻十倍时收到的账单来算。

第二是多人同时改动同一份数据的时刻。库存只剩一件的商品，两位顾客同时下单会怎样。自研后端对这种情况有成熟的处理方式。无代码的自动化流程常常按”步骤依次执行”来设计，因此需要翻厂商文档，确认执行相互重叠时它究竟怎么处理。平时看不见，偏偏在最忙的那天爆出来。

第三是外部服务对接超出内置范围的时候。支付、短信、地图这些常用连接大多已经备好。麻烦的是工具没有直接支持的对象，比如某家区域物流公司或税务系统。这时你会搭一条绕行的路把它接上，而绕行的路一旦累积到三四条，维护难度就超过了自研。不是没有代码，而是代码散落在好几个工具里。

提前压低迁移成本的两件事

这三件都是将来的事，眼下很难判断。所以无论选哪条路，现在都有两件事值得先确认。

看数据能不能整份取出来。 在选定工具之前先查它的导出功能。把界面上看得见的表格下载成表格文件，和连同关联关系一起、通过文件或 API 取走全部数据，这是两回事。未来迁移成本的大部分就在这里定下。数据只要完整出来，界面可以重做；数据被锁住，就得靠人手一条条搬。

决定业务规则写在哪里。 折扣比例、等级判定、结算方式，这些是只属于你这门生意的规则。把它们分散埋进无代码工具的各个自动化模块，将来迁移的第一项工作就是把这些规则一个个找出来。反过来，如果把规则集中放在一处，换工具时这部分可以原样带走。

归结起来，最先要定的不是无代码还是自研，而是这个产品的数据会怎样生长，以及你能不能随时把它取出来。这一点定了，工具的选择自然跟着出来。

如果你已经在用某个工具，告诉我们它的名字就够了。Weple 会先看你现在的结构还能走多远，若确实需要迁移，再把先取什么、按什么顺序取理出来。如果还什么都没选，那就从你想做的产品聊起。