为什么我们故意不构建大型 POS

如果您曾经为一家小餐馆评估过销售点软件，您会认出这种模式。供应商的演示文稿展示了五十个功能。配置屏幕有数百个设置。经常性费用是为连锁店校准的。三个月后，您和您的团队可能只使用了十二个功能——但您为所有五十个功能付费，并且每次轮班都在其他功能上绊倒。

这不是偶然。这是当一个产品必须满足风险投资支持的供应商的增长曲线和服务于吉隆坡市中心的一家40座餐厅时会发生的情况。这两种需求根本不指向同一个方向。

“最小化 POS” 的实际意义

当我们说“最小化”时，我们并不是指简化或低质量。我们的意思是：仅此餐厅所需，别无其他。以下是我们自己部署的三个具体例子：

• 一家居酒屋柜台，厨师希望订单输入遵循实际的怀石料理流程——而不是通用的“桌子→票据”互动。因此我们建模的是菜品，而不仅仅是项目。
• 一个小型午餐和晚餐概念，厨房运行两个不同的站点。POS 应该将正确的项目以正确的格式路由到正确的打印机。无需“规则引擎”——只需一个清晰的硬编码映射。
• 一位每晚亲自结账的老板，只想在主屏幕上看到三个数字：收入、最畅销菜品和现金差异。这就是主屏幕。不是“仪表板模块”。

我们省略的内容

这个列表至少与我们放入的内容同样重要：

• 没有多租户功能标志。每个商店都获得适合它的构建。
• 没有“可配置的一切”。如果只有一种类型的餐厅需要某个设置，我们会为需要的餐厅硬编码它，并将其从其他餐厅中省略。
• 没有主题引擎，没有插件市场，没有未来功能的路线图。我们只提供现在需要的东西。

我们有意保持小规模的内容

• 数据库。每个商店一个 PostgreSQL 实例，按实际交易量调整大小。没有微服务。
• 代码库。每个商店系列一个 TypeScript 代码库，共享公共模块，只有在确实是相同问题时才共享。
• 运营足迹。一台服务器，一个备份管道，一个监控视图。故意保持简单。

为什么这对小型运营商有效

结果是软件适合运营，而不是要求运营围绕它进行调整。更重要的是，拥有成本显著降低。运行我们最小化 POS 的单个商店支付的费用只是通用企业 POS 供应商的一小部分——并且随着运营的增长，成本保持可预测。

这种方法并不适合每个企业。一个拥有200家店的连锁店需要不同的软件，而我们不是应该构建它的团队。但对于马来西亚的大多数独立餐厅和小型连锁店来说？调整 POS 的规模是业主可以做出的最具杠杆作用的决策之一。

正在为您自己的运营开发 POS？联系我们——我们很乐意交流意见。