低代码（零代码）软件平台、套件、工具和相关服务正在快速地广泛普及和扩展。现在许多人都知道，低代码软件解决方案提供的加速器和自动化，可以加速软件应用程序开发人员的工作……这就意味着（在这个开发人员匮乏的星球上) 低代码很受欢迎。
低代码通常是将与软件编码相关的更容易定义和可重复的任务组件化，它并不适合小白，仍然需要通过专业培训的软件工程师来操作（一些业务人员可以使用更高度抽象的零代码服务)，但低代码已被广泛认为是我们现在创建应用程序的重要方式之一。
现在每个供应商都是低代码者
曾经低代码是专业的低代码平台组织独占的专业领域（正如我们之前所说的，通常包括Appian、Mendix和OutSystems），现在低代码已经渗透到整个企业软件供应商领域的计划中，有好几家公司可能只是为了获得一些“话语权”而将其加入进来。
低代码/无代码并不新鲜，十多年来它一直是精打细算的企业和缺乏经验的编程人员的选择。但现在的低代码/无代码平台比以前更强大，在技术环境中长大的年轻一代拥有更广泛的技能基础来操作低代码/无代码平台。
目前市场上有许多低代码平台，那么想使用低代码的企业应该如何与这些提供这种新型企业应用程序工具的公司进行交流呢？
由于低代码提供的范围不同，选择平台这个问题是很棘手的。大多数企业软件都是为一个特定的功能而构建的，比如HR、工资单、采购等等。而对于低代码是没有这种限制的，你可以在任何项目上使用它。
低代码—特殊的工具
在购买低代码产品时需要考虑的事情有很多，这意味着了解怎样与在这个IT市场领域运营的供应商进行沟通是非常重要的。
所有这些低代码的开发工具都是不同的。有一个很好的类比: 把所有可用的低代码工具归入一个类别，就像把旱冰鞋、滑板、轮椅、自行车和汽车归入一个被称为“轮式交通工具”的大类别。它们都可以把你从a点带到b点，但是用户体验差别很大。
对于低代码工具来说也是如此; 各个工具集都有不同的特性、接口、限制和用例。想要采用这些工具的企业需要了解的是，只有明确采购目标，才能找到对应的工具。
第一个要考虑的关键问题是最终交付的应用程序的可定制程度如何？理论上我们认为低代码环境对于使用这些工具生产的软件应用程序具的定制选项有限，但在实践中很少出现这种情况。企业需要考虑客户将如何定制他们的应用程序。
当低代码用户考虑如何定制生成的应用程序时，首先，即使用户可能很少需要编辑代码，但是也需要一个可以在代码级别进行编辑的图形化编辑器。其次，还应该确定是否可以添加自己的定制业务逻辑、规则或流程，这个功能将决定软件能否适应你的业务。
如果我们不用了会怎么样
软件采购主管、系统架构师或软件开发人员很少会想到一些负面影响，例如如果他们停止使用既定的平台、开发环境、套件或工具集会发生什么。但在低代码环境中，这是一个重要的考虑因素，因为使用低代码供应商的工具可能会导致一定程度的锁定。
企业首先要注意数据存储的位置，一般会有两种选择：一种是客户将数据本地存储在自己的总部; 另一种是低代码供应商存储数据并将其作为外部云服务提供。显然，第一种选择会让数据的导出和下载更加方便，而第二种选择会让客户意识到他们无法真正的控制自己的数据。
低代码用户还应该确定他们的低代码应用程序的正常运行是否需要定期订购。如果开发的应用程序需要定期订购才能使用，用户就要与该供应商绑定在一起。为了避免这一点，企业应该寻找不依赖于开发工具运行的平台。这样的话不管是否订购，在这些平台上开发的应用程序都能正常工作。
还有另一个考虑因素是用户能否在低代码工具之外维护应用程序，如升级、 扩展、修补等。一部分低代码平台生成的应用程序可以在平台外部维护，另一部分低代码供应商要求客户使用他们的平台进行维护。用户还应询问低代码平台实际上生成了什么样的代码。用户需要知道该平台是生成特定于低代码平台本身使用的专有代码，还是生成更标准的软件编程语言，如Java、PHP、.Net等。显然，低代码平台专有的特定代码是很难在平台之外维护的。
开发范围
由于低代码软件的本质与传统软件工具的本质大不相同，客户还应该考虑低代码平台能否满足他们的开发范围。
传统软件是封闭式的。软件有固定的功能，用户知道使用它可以开发出什么程序。而低代码软件是不同的。它结合了软件的封闭性和软件开发的开放性，用户可以开发任何平台允许的程序。这可能会导致企业的需求超出工具本身可以开发的范围。因此，低代码平台背后的供应商比传统软件供应商更为重要。
多年来在一系列低代码工具中工作的经验告诉我们，用户应该听取每天都在使用低代码工具的产品专家提出的建议。因此着手寻找一个产品专家比增加基础的客服更加重要，因为这些产品专家可以介入帮助客户更好的使用工具解决问题，例如满足紧张的排期，或攻克开发瓶颈问题。
另一个要考虑的问题是低代码供应商对用户的新功能的支持程度，客户需要考虑如果他们想定制或集成一个新的特性到软件中会发生什么。任何开发过软件的人都知道问题总是出现在像集成这样的小细节里，那么供应商是否支持添加新功能或者协助集成呢？
引入第三方功能
还有一个需要讨论的问题是，低代码供应商的工具能否能连接广泛的第三方API、框架和云服务？
随着企业将更多的业务转移到云端，不同部分之间的数据传递变得至关重要。除此之外，很多开放的框架和服务可以改进低代码的应用程序。用户应该了解低代码平台能否与云服务和框架连接，比如一个平台能否使用REST api；还应该了解能否在他们的应用程序中添加诸如“单点登录”之类的服务。用户应该确定集成这些功能的难易程度，以及如果需要进行集成，厂商是否会提供相关帮助。
来源、范围和简单性
低代码正在不断发展，基于前文的一些观点，部分目前正在使用这些工具的用户可能还不能完全理解它。
对于如今的低代码领域而言，在最初的接洽过程中提出前文的观点，无疑是对来源、范围和简单性达到更深层理解的途径。