为非技术创始人写的 SaaS 应用开发

Albert Santalo avatar
Albert Santalo • • 20 分钟阅读
为非技术创始人写的 SaaS 应用开发

一份为非技术创始人写的指南，讲那些决定 SaaS 产品能否活下来的架构决策——已为 AI agent 时代更新。

几年前我写过一篇文章，旨在为着手 SaaS 应用开发的非技术创始人揭开关键架构决策的神秘面纱。此后，技术格局发生了剧烈演变。最显著的变化是生成式人工智能的到来——以及最近，直接消费软件的 AI agent——它正在改变我们构建软件以及与软件互动的方式。下面这些基本原则依然成立；变化的是，如今把它们做对，还决定了你的产品是否对那些越来越多在挑选工具的 AI agent 可见。

软件即服务（SaaS）仍然是创业创新的基石，让企业能通过互联网快速高效地交付方案。然而复杂度增加了，而作为非技术创始人，穿越这片地形可能感觉像在未知水域里驾船。

非技术 SaaS 创始人面临的挑战

创业公司的产品开发，类似在布满冰山的海域航行。虽然那句谚语里的「冰山一角」——用户界面——可能很漂亮、正是你所设想的样子，但水面之下那庞大的结构——应用的基础设施——才是大部分努力、风险和复杂度所在的地方。正是这个隐藏的部分，可能决定你 SaaS 事业的成败。

SaaS 的隐藏复杂度

  • 技术债： 糟糕的架构决策会导致长期问题，而修复它们代价高昂。
  • 糟糕的规划与优先级排序： 弄清什么是必要的、并只专注于此，对雄心勃勃、精力充沛的创始人来说真的很难。
  • 基础设施管理： 确保你的应用可扩展、可靠且安全，需要成熟的基础设施。
  • 集成挑战： 与其他系统和服务连接会增加复杂度的层数。
  • 性能优化： 交付顺畅的用户体验，需要持续的调优和改进。

构建并经营一家 SaaS 企业不只是写代码；事实上，对 65% 非技术出身的创始人来说，它更多关乎战略性的营销、销售和与客户互动。虽然客户非常在意你的产品及其提供的价值，他们并不关心背后的代码。然而，建立在坚实架构地基上的、构造良好的产品，对交付那份价值是关键的。

非技术创始人可能踩的坑

  • 过度工程： 花太多时间打磨产品，会延迟进入市场并耗尽资源。
  • 可扩展性问题： 一个撑不住增长的应用，会在用户需求上升时摇摇欲坠。
  • 优先级排序困难： 在缺乏对技术复杂度清晰理解的情况下，你可能难以有效地为功能和改进排序。这会导致把注意力放在影响较小的功能上，而忽视那些推动用户满意度和业务增长的关键功能。
  • 迭代缓慢： 长开发周期会削弱你回应市场变化的能力。
  • 沟通缺口： 业务目标与技术实现之间的不一致，会导致不令人满意的结果。
  • 昂贵的重写： 根本性的缺陷可能迫使产品从零重建，吞掉宝贵的时间和金钱。

作为非技术创始人，你可能没有招聘和管理技术负责人（CTO）或工程团队的经验，然而你却完全依赖他们做出正确的选择。弥合这个缺口对确保你的愿景被有效实现是必需的。

非技术 SaaS 创始人的新范式

SaaS 模式自诞生以来已显著成熟。仅仅做出一个产品然后指望它成功，已经不够了。现代 SaaS 应用必须可扩展（能承受增长）、安全（能防御威胁）且智能（能学习和适应）。生成式 AI 与大语言模型（LLM）的兴起——如 OpenAI 的 GPT-4、Anthropic 的 Claude 和 Google 的 Gemini——带来了新的可能与新的挑战。

非技术创始人面临的挑战：

  • 技术语言障碍： 「微服务」、「无服务器计算」和「边缘计算」这类术语可能令人不知所措。
  • 战略选择： 在没有技术背景的情况下决定技术方向，可能令人畏惧。
  • 资源管理： 在预算约束与投资正确技术之间取得平衡。考虑到我们今天所经历的更紧的金融市场，这一点尤其重要。

揭开 SaaS 架构的神秘面纱：什么定义了一个现代 SaaS 应用？

从前，大多数软件是以永久许可一次性买下的，装在客户的电脑上，并需要支付年度维护费。随着万维网的到来，软件即服务——即 SaaS——诞生了。在 SaaS 交付模式中，软件被集中托管，并交付到客户在桌面或移动设备上运行的浏览器里。一个现代 SaaS 应用不只是通过互联网交付的软件。它体现了若干关键特征：

  • 基于云的基础设施： 应用运行在远程服务器（「云」）而不是本地机器上。
  • 多租户： 应用的单个实例服务多个客户，客户数据被安全隔离。
  • 高可配置性： 每个客户都能在不改动核心代码库的前提下把应用调整成适合自己需要的样子。
  • API-first 设计： 以集成为前提构建，让不同软件系统能顺畅通信。
  • AI 赋能的功能： 引入 AI 来增强功能与用户体验。
  • 可扩展性与性能： 能高效承受不断增长的负载。
  • 用户体验： 在各类设备上提供直观且响应迅速的界面。
  • 按订阅和/或按用量计价： 大多数 SaaS 产品基于订阅，部分采用纯用量或混合模式。

什么是单实例多租户架构？

想象一栋高层公寓，每位住户有自己的私人空间，但共用大堂和电梯这类公共设施。类似地，在多租户 SaaS 应用中，多个客户（租户）共用同一套应用基础设施，但各自的数据和配置彼此隔离。

好处：

  • 成本效率： 共享资源为提供方和客户双方降低运营成本。
  • 易于维护： 更新和修复只做一次，所有用户都受益。
  • 可扩展性： 无需大的架构改动就能轻松容纳更多用户。

关键能力：

  • 自助服务： 让用户能独立调整设置、管理账户、个性化功能。
  • 功能开关： 允许客户根据偏好启用或停用特定功能。
  • 定制品牌： 让客户能修改外观风格以匹配自身品牌身份。

示例场景：

一个项目管理 SaaS 平台允许公司设置自定义工作流、通知和仪表盘布局，在无需额外开发投入的情况下提供个性化体验。

架构上的演进：从单体到微服务

随着 SaaS 应用复杂度增长，它们的结构方式变得越来越重要。最初，应用被构建为单体——一个统一的代码库，所有组件互相连接。虽然这种方式起步更简单，但随着应用扩张，它会变得笨重。

向微服务的转变

微服务架构把应用拆成更小的、通过定义良好的 API 通信的独立服务。每个微服务处理一项具体功能，比如认证、支付处理或用户通知。

好处：

  • 灵活性： 更新或替换单个服务而不影响整个系统。
  • 可扩展性： 根据需求独立地为各服务扩容。
  • 韧性： 如果一个服务失败，其他服务继续运转。

挑战：

  • 复杂度： 需要成熟的协调与管理工具。
  • 数据一致性： 确保所有服务都拿到它们需要的数据。
  • 通信开销： 更多服务意味着更多通信，可能影响性能。

最佳实践：

  • 服务发现工具： 帮助各服务彼此定位并通信。
  • API 网关： 管理请求、安全和流量路由。
  • 健壮的监控： 及时发现并处理问题。

理解 API 与 API-first 方法

API（应用程序编程接口）是让不同软件应用能通信和共享数据的信使。把 API 想成餐厅里的服务员。你（用户）下单，服务员（API）把它传达给厨房（服务器），然后把菜送回给你。在软件里，API 让不同的应用或服务能顺畅地互动和交换信息。

API-first 方法

API-first 方法意味着在开发前端或其他组件之前，先设计并构建应用的 API。这在你的后端与前端之间创造出天然的分离，确保：

  • 一致性： 应用的所有部分以标准化的方式通信。
  • 可复用性： API 能被跨平台使用（web、移动、物联网）。
  • 易于集成： 便于与第三方服务集成以及未来扩展。

选择合适的 API 风格

API 可以用不同的架构风格实现，其中 REST 和 GraphQL 最流行。这个选择在 2026 年比以往更重要，因为现在消费 API 的不只是人类开发者，还有 AI agent，而 GraphQL 在 agent 消费上有结构性优势。

REST

  • 结构： 为不同资源或操作使用多个端点（URL）。
  • 用法： 每个端点对应一个具体操作（例如 GET /users）。
  • 局限： 可能需要多次请求才能取到所有需要的数据，导致低效。

GraphQL

  • 结构： 使用单一端点，客户端通过查询精确指定自己需要的数据。
  • 好处：
    • 高效： 减少网络请求次数。
    • 灵活： 客户端只收到它请求的数据。
    • 强类型： 定义数据类型和关系，有助于校验。

对比示例：

  • REST： 取用户数据及其帖子可能需要两次独立请求。
  • GraphQL： 两者可以在一次查询里取到。

需要考虑的因素：

  • 学习曲线： GraphQL 引入了需要学习的新概念。
  • 缓存复杂度： 传统缓存策略可能不适用。
  • 适用场景： 特别适合有复杂数据需求和多种客户端类型的应用。

SaaS 应用开发的编程语言

选择合适的编程语言是一个关键决策，会影响项目的成败。语言影响开发速度、性能、可扩展性，以及找到并留住人才的能力。重要的是不只考虑当下需求，还要考虑长期的维护与演进。

不过要小心：开发者往往偏好自己熟悉的语言和技术，而那未必总是最适合你项目的。虽然利用现有专长能加快初期开发，但如果所选技术与你应用的需求不匹配，就可能带来麻烦。作为非技术创始人，与技术团队进行开放的讨论至关重要，以确保语言选择与你的业务目标一致。请考虑：

  • 项目需求： 评估你的应用在性能、可扩展性和特定功能上的需要。
  • 开发者可获得性： 流行语言让招聘和扩充团队更容易。
  • 社群与生态： 强大的社群提供库、框架和支持。
  • 长期可行性： 考虑该语言的前景和持续支持情况。
  • 学习曲线： 容易学的语言能加快新开发者上手。

流行语言及其优势

JavaScript（与 TypeScript）

  • 用途： 前端与后端开发（Node.js）。
  • 优势：
    • 全栈开发： 可同时用于客户端和服务端。
    • 庞大生态： 丰富的库和框架（React、Angular、Vue.js、Next.js）。
    • 社群支持： 资源充沛，社群活跃。

Python

  • 用途： 后端开发、数据分析、AI 与机器学习。
  • 优势：
    • 易于学习： 语法简单，可读性好。
    • AI 与 ML 库： 有 TensorFlow、PyTorch 等库的强力支持。
    • 通用性： 适合快速开发和做原型。

Java

  • 用途： 后端开发、企业应用、Android 应用开发。
  • 优势：
    • 性能： 健壮、可扩展且跨平台。
    • 企业采用： 在大型组织中被广泛使用，工具链完备。
    • 安全特性： 内建的安全机制适合复杂应用。

Ruby

  • 用途： web 应用，尤其配合 Ruby on Rails 框架。
  • 优势：
    • 快速开发： 强调「约定优于配置」，加快开发。
    • 可读性： 语法干净，容易理解。
    • 社群 gem： 大量库和插件可扩展功能。

Go（Golang）

  • 用途： 后端系统、微服务、网络编程。
  • 优势：
    • 性能： 编译型语言，并发支持高效。
    • 简洁： 为简洁而设计，降低代码库的复杂度。
    • 可扩展性： 非常适合构建可扩展的网络服务。

前端开发与用户体验

你 SaaS 应用的前端是产品的脸面。用户在这里与你的服务互动，而第一印象很重要。设计良好的用户界面（UI）和用户体验（UX）能让你的产品从竞争者中脱颖而出。

现代框架

React

  • 开发方： Facebook。
  • 优势： 用可复用组件构建交互式界面。
  • 生态： 丰富的工具和库，比如用于状态管理的 Redux。

Angular

  • 开发方： Google。
  • 优势： 全面的框架，适合大规模应用。
  • 能力： 内建路由、表单处理和 HTTP 服务等工具。

Vue.js

  • 优势： 轻量灵活，易于集成进既有项目。
  • 采用情况： 因简洁和平缓的学习曲线而人气渐涨。

Next.js

  • 构建于： React
  • 优势：
    • 服务端渲染（SSR）： 提升性能与搜索引擎优化。
    • 静态站点生成（SSG）： 在构建时生成静态页面以加快加载。
    • 路由与代码分割： 简化导航并优化性能。

响应式网页设计、原生应用与渐进式 web 应用

响应式网页设计（RWD）

创建能顺畅适配各种屏幕尺寸和设备的网页，确保用户无论在桌面、平板还是手机上都有一致的体验。

  • 好处：
    • 改善用户体验： 提升跨设备的易用性。
    • 搜索优化优势： 移动友好的站点在搜索结果中排名更好。
  • 技术手段：
    • 弹性网格与布局： 随屏幕尺寸调整。
    • 媒体查询： 根据设备特性应用 CSS 样式。

渐进式 web 应用（PWA）

PWA 结合了 web 与移动应用的优点，直接在浏览器里提供类应用体验。如今 PWA 常成为 SaaS 创业者的默认选择，因为在许多情况下，它让人能把「是否构建原生应用」的决定推迟到产品达成产品市场匹配之后。这大幅降低了前期开发开销。

  • 好处：
    • 离线访问： 借助 service worker 在无网络连接时也能运行。
    • 可安装： 用户能把应用加到主屏，无需访问应用商店。
    • 性能： 更快的加载和更顺畅的交互。
  • 实现方式：
    • Service worker： 处理缓存与离线功能的后台脚本。
    • Web App Manifest： 定义图标、主题色和显示选项等元数据。

原生应用与 PWA 的对比

  • 原生应用：
    • 平台专属开发： iOS 和 Android 各自独立的代码库。
    • 访问硬件能力： 与设备功能更深度集成。
    • 分发： 通过应用商店提供。
  • PWA：
    • 跨平台兼容： 所有设备共用一个代码库。
    • 更新简单： 用户总是访问最新版本。
    • 成本效益： 降低开发与维护成本。

集成人工智能

人工智能已成为现代 SaaS 应用的基石，让服务更智能、更个性化、更高效。生成式 AI 与大语言模型（LLM）的到来——如 OpenAI 的 GPT-4、Anthropic 的 Claude 和 Google 的 Gemini——彻底改变了应用与用户互动、处理信息的方式。

理解大语言模型（LLM）

大语言模型是在海量文本数据上训练、用于理解和生成类人语言的 AI 系统。它们能理解上下文、生成连贯的句子、翻译语言，甚至创作内容。

主要的语言模型：

  • OpenAI 的 GPT-4： 以先进的语言理解与生成能力著称，GPT-4 能完成从起草邮件到写代码的各类任务。
  • Anthropic 的 Claude： 以安全与伦理为重点设计，Claude 致力于提供有帮助且可靠的 AI 协助。
  • Google 的 Gemini： 一个整合了文本、图像和音频理解的多模态模型家族，被广泛用于对话式 AI 和其他应用。

智能体式 AI 与语言模型在 SaaS 中的影响

智能体式 AI 指的是能自主行动、基于目标和环境输入做出决策的 AI 系统。把智能体式 AI 和语言模型集成进你的 SaaS 应用，能显著提升功能与用户体验。

应用场景：

  • 增强的客户支持：
    • 对话式 AI： 实现能提供即时、感知上下文回答的聊天机器人，提升客户满意度。
    • 全天候可用： 在无人工介入的情况下提供全天候协助。
  • 自动内容生成：
    • 个性化消息： 基于用户行为撰写定制邮件、通知或推荐。
    • 动态内容创建： 自动生成报告、文章或摘要。
  • 智能自动化：
    • 工作流优化： 自动化数据录入、排期或文档处理等例行任务。
    • 决策支持： 基于数据分析提供洞察与建议。
  • 自然语言处理（NLP）：
    • 情感分析： 理解客户反馈以改进产品或服务。
    • 语言翻译： 通过实时翻译内容打破语言壁垒。

利用 AI 平台

你不需要从零构建 AI 能力。许多平台和工具能帮你把先进的 AI 集成进应用。

大语言模型（LLM）

  • OpenAI 的 GPT-4：
    • 能力： 先进的语言理解、代码生成、内容创作。
    • 用法： 通过 API 访问，可集成进你的应用。
  • Anthropic 的 Claude：
    • 专注安全： 为提供有帮助且合乎伦理的 AI 协助而设计。
    • 用法： 可集成用于对话式 AI 和内容生成。
  • Google 的 Gemini：
    • 多模态能力： 结合文本、图像和音频处理，带来更丰富的交互。
    • 优势： 长上下文处理能力强，与 Google Cloud 生态紧密集成。

基于云的 AI 服务

  • OpenAI API：
    • 访问 GPT-4 及其他模型，用于自然语言理解与生成等任务。
  • Google Cloud AI：
    • Vertex AI： 用于构建、部署和扩展机器学习模型的统一平台。
    • Dialogflow： 为网站、移动应用和消息平台创建对话式界面。
  • Amazon Bedrock：
    • 一个完全托管的服务，通过 API 提供来自 AI21 Labs、Anthropic、Stability AI 和 Amazon 的基础模型（FM）。
  • Microsoft Azure AI：
    • Azure OpenAI Service： 以企业级能力提供对 OpenAI 模型的访问。
    • Cognitive Services： 面向视觉、语音、语言和决策的预制 API。

如何把 AI 集成进你的 SaaS 应用

  1. 识别机会： 确定 AI 能在哪里增加价值，比如自动化重复任务或增强用户互动。
  2. 选择合适的工具： 挑选与你的需求和技术能力匹配的 AI 模型与服务。
  3. 准备数据： 确保你有高质量的数据用于训练，并在必要时微调 AI 模型。
  4. 开发与测试： 先从试点项目开始验证 AI 功能，再做全面实施。
  5. 监控与迭代： 持续评估 AI 表现，基于用户反馈和分析做改进。

使用 AI 时需要考虑的事

  • 合乎伦理的使用： 确保负责任地部署 AI，处理潜在偏见并保持透明。
  • 数据隐私： 处理用户数据时遵守 GDPR 和 CCPA 等法规。
  • 成本管理： 为使用先进 AI 服务的开销做规划，包括 API 使用费。
  • 用户体验： 把 AI 交互设计得直观，并让它提升整体用户旅程。

数据管理与分析

有效的数据管理对性能、可扩展性以及提供有价值的洞察都是关键。随着对实时数据和低延迟响应的需求增长，尤其在物联网和边缘设备上，理解如何有效处理数据至关重要。

SaaS 应用中的边缘计算

边缘计算在数据产生的地方附近——网络的「边缘」——处理数据，而不是把它送回中心服务器或云端。这种方式降低延迟、减少带宽占用，并允许实时处理。

好处：

  • 降低延迟： 通过本地处理数据获得更快的响应。
  • 带宽效率： 更少的数据在网络上传输，节省成本并提升性能。
  • 增强隐私： 敏感数据可以在本地处理，提升安全性。

适用场景：

  • 物联网设备： 实时管理来自传感器和设备的数据。
  • 内容分发网络（CDN）： 从更靠近用户的服务器提供内容。
  • 实时分析： 为自动驾驶车辆或工业自动化等应用做即时处理。

选择合适的数据库

选择合适的数据库技术，对你应用的性能和可扩展性至关重要。

SQL 数据库（结构化查询语言）

  • 特点： 结构化数据，以带预定义关系的表来组织。
  • 适合： 需要复杂查询和强数据完整性的应用。
  • 例子： MySQL、PostgreSQL、Microsoft SQL Server。

NoSQL 数据库（不只是 SQL）

  • 特点： 面向非结构化或半结构化数据的灵活 schema。
  • 适合： 数据快速变化或需要高可扩展性的应用。
  • 类型与例子：
    • 文档存储： MongoDB
    • 键值存储： Redis
    • 宽列存储： Apache Cassandra

边缘数据库

有了边缘计算，能在边缘高效运作的数据库就变得必要了。

  • 特点：
    • 轻量高效： 能在资源受限的设备上运行。
    • 分布式处理： 在边缘节点与云之间同步数据。
    • 离线能力： 在没有持续网络连接的情况下继续运作。
  • 例子：
    • SQLite： 适合移动和嵌入式应用。
    • Apache Cassandra： 能在多台服务器上处理大量数据，适合边缘部署。
  • 需要考虑的事：
    • 数据同步： 确保边缘与云端数据存储之间的一致性。
    • 安全： 保护静态和传输中的数据，尤其当它分布在许多设备上时。

容器化与编排

容器把一个应用及其依赖封装起来，确保跨不同环境的一致性。

好处：

  • 可移植性： 同一个容器镜像可在开发、测试和生产中运行。
  • 高效： 相比虚拟机更轻量，节省资源。

用 Kubernetes 做编排

在不同环境中管理多个容器可能很复杂。Kubernetes 把容器化应用的部署、扩容和管理自动化。它的能力包括：

  • 自愈： 自动重启或替换失败的容器。
  • 负载均衡： 分配网络流量以维持性能。
  • 扩容： 根据需求调整容器数量。

作为非技术创始人领导技术团队

在没有技术背景的情况下领导一支技术团队可能有挑战，但用正确的方法是可以做到的。成功取决于有效的沟通、持续的学习，以及培育一种协作的氛围。

弥合缺口

建立清晰的沟通渠道至关重要。鼓励团队用平实的语言解释技术概念，让复杂的想法变得可理解。定期的会议和更新帮助你随时了解进展、挑战和里程碑。这份透明建立信任，并确保你能做出明智的决策。

投入时间提升自己的技术素养。虽然你不需要成为专家，但理解基础能显著提升你领导的能力。利用在线课程、工作坊以及为非技术领导者定制的行业出版物等资源。提问不只帮你学习，也展现了你对团队工作的投入。

赋能你的技术团队，把在其专业范围内做决定的自主权交给他们。设定清晰的目标和期望，但在「如何达成」上允许灵活。认可并庆祝他们的成功，在挑战出现时提供支持。这种方式培育出主人翁意识，激励团队做到卓越。

拥抱敏捷方法论

采用敏捷方法论能提升团队内部的协作与适应力：

  • 与客户协作： 让客户和相关方参与开发过程。
  • 适应性规划： 基于反馈和变化的需求调整计划。
  • 早交付： 尽早交付可用的组件以收集用户反馈。

实施敏捷框架：

  • Scrum：
    • 角色： 产品负责人（你或指定代表）、Scrum Master、开发团队。
    • Sprint： 有具体目标的固定长度迭代（通常 2 到 4 周）。
    • 仪式： 每日站会、sprint 规划、评审和回顾。
  • Kanban：
    • 可视化工作流： 用 Kanban 板可视化任务与进展。
    • 在制品限制： 控制每个阶段的任务数量以优化流动。
    • 持续交付： 功能一准备好就发布。

好处：

  • 透明： 所有人都了解项目状态和优先级。
  • 灵活： 能迅速回应变化或新信息。
  • 持续改进： 定期评估流程并实施改进。

延伸阅读

如果你从零开始：如何在没有开发者的情况下做出 MVP。关于词汇：非技术创始人必备技术术语词典。关于选择构建方式：vibe coding 之后是什么和规范驱动开发与重写的终结。

这究竟对你要求了什么

作为非技术创始人着手 SaaS 应用开发可能看起来令人畏惧，但有了正确的知识和方法，你可以把自己的事业引向成功。拥抱生成式 AI、微服务和边缘计算等现代技术，会把你的创业公司放在创新的前沿。

要抓住的东西：

  • 驾驭 AI 的潜力： 集成 GPT-4、Claude 和 Gemini 等 AI 与语言模型，来提升用户体验并自动化复杂任务。
  • 采用现代架构： 为灵活性和性能利用微服务、容器化、无服务器与边缘计算。
  • 专注用户体验： 投资于响应式设计和现代前端框架。
  • 优先做好数据管理： 为数据处理、分析和合规实施健壮的策略。
  • 培育 DevOps 文化： 鼓励协作并自动化流程，以获得高效的开发周期。
  • 自信地领导： 通过沟通和持续学习，弥合技术与非技术方面的缺口。
  • 做这场游戏的学生： 随着新技术出现，确保你清楚理解它们对你公司的影响。

理解并应用这些概念，你就能自信地把自己的 SaaS 事业引向增长与成功。请记住，虽然技术是强大的赋能者，最终目标是为客户交付价值。专注构建一个满足他们需要的产品，成功自会跟来。

常见问题

非技术创始人能不招开发者就做出 SaaS 产品吗？ 你能做到一个能用的产品，而且越来越能做到一个真正的产品。你无法外包的是架构决策——多租户、数据模型、API 接触面、认证如何运作。它们决定产品能否活过头一百个客户，而它们要么被刻意做出，要么按默认值被做出。

什么是单实例多租户架构？ 一个运行中的应用服务许多客户，每个客户的数据在逻辑上隔离，而不是靠跑多个独立副本。它是 SaaS 的标准形态，因为它让更新、监控和成本控制变得可处理——打补丁时部署一次，而不是几百次。

一个新的 SaaS 产品该从微服务开始吗？ 通常不该。微服务解决的是大多数早期产品还没遇到的组织和扩容问题，而它会立刻带来运维开销。一个结构良好、内部边界清晰的单体可以之后再拆开；一个过早的分布式系统要反过来难得多。

API-first 对一个 SaaS 产品意味着什么？ 把 API 设计成产品的主要接口，并把界面构建成它的一个消费方，而不是之后再作为导出功能加一个 API。现在它更重要，因为 AI agent 直接消费 API，所以一个没有被定义的 API 接触面的应用，对它们是不可见的。

非技术创始人到底需要多少技术知识？ 够到能提出好问题、并认出一个糟糕的回答。你不需要写代码。你确实需要理解什么是 schema、为什么迁移有风险、一份 API 契约让你承诺了什么，以及各种东西大概要花多少钱——否则你无法把真正的约束和推托之词区分开。

相关文章

查看全部