Basecamp：当设计公司被自己的混乱搞垮，他们决定自己发明一个工具

2003年，芝加哥。Jason Fried 的设计公司 37signals 正在经历一种特殊的折磨——不是缺乏项目，而是项目太多，多到已有的工具根本撑不住。

37signals 当时大约有十几名员工，同时运营着十多个客户项目。每个项目有不同的利益相关方，不同的反馈周期，不同的文件版本。客户在邮件里提意见，设计师在聊天软件里讨论，文件版本散落在本地硬盘和邮件附件里，里程碑被记录在各自为政的电子表格里。

这套临时拼凑的系统维持了一段时间，然后它崩溃了。

崩溃的方式不是戏剧性的——没有一个重大的失误，而是一种持续的、低强度的失控。文件的旧版本被当成最新版本发给客户；一个在会议里讨论并确认要修改的细节，三周后的交付物里依然是原来的样子；某个客户在上周的邮件里提出的问题，没有人记得跟进了。

Fried 后来描述那段时期，使用的词是”耻辱”。具体的耻辱场景是：客户比公司自己更清楚地知道项目里哪些事情被遗漏了。一个客户在会议上拿出一封三周前发给 37signals 的邮件，里面有一个具体的修改要求，然后问：你们处理这个了吗？

这不只是效率问题，这是一个关于信任和专业度的问题。设计公司卖的东西是执行力，而执行力的第一条件是记得自己承诺要做什么。

找不到合适的工具

面对这个问题，37signals 首先尝试的是市场上已有的解决方案。

2003年的项目管理工具市场并不贫乏，有 Microsoft Project、Basecamp 之前的各类企业软件，以及一批号称能解决协作问题的工具。Fried 和团队尝试了几个，发现它们有一个共同的问题：它们是为大型企业设计的，是为有专职项目经理、复杂的汇报层级、详细的甘特图需求的团队设计的。这些工具在进入使用之前，需要大量的配置和定制，需要团队花时间学习它们的逻辑和操作方式。

对于一个十几人的设计公司来说，这个门槛本身就是一个问题——安装和配置一个项目管理系统所需的时间和精力，和这个系统声称要解决的”效率问题”形成了一种荒诞的悖论。

Fried 意识到，市场上没有一个工具是为他们这种规模和性质的团队设计的。所有的工具要么太简单（只是一个待办清单），要么太复杂（企业级的流程管理系统）。他需要的是一个中间地带：简单到不需要专门学习，但有足够的结构让团队保持对话和决策的同步。

用六周时间构建内部工具

Fried 把这个问题交给了 37signals 的程序员 David Heinemeier Hansson，当时 Hansson 还是一个在哥本哈根的兼职承包商，为 37signals 远程工作。

Hansson 在大约六周的时间里，构建了一个 Web 端的项目管理工具的原型。这个工具从第一天起就有一个核心设计原则：它不试图解决所有问题，它只解决一个问题——确保项目相关的所有内容，包括讨论、文件、待办事项、里程碑，都在同一个地方，而且所有项目成员都能访问。

这个原则排除了大量的复杂性。没有复杂的权限管理，没有甘特图，没有时间追踪，没有资源分配。就是一个共享的项目空间，让每个人都能看到项目的完整历史——哪个决定是怎么做出的，谁发了什么消息，文件的当前版本是什么。

37signals 把这个工具用在了自己的客户项目上，然后发生了一件意想不到的事情。

客户问：“我们也能用吗？”

工具上线后的几个月里，客户开始注意到他们在使用一种不同的工作方式。项目更新出现在同一个地方，反馈可以在讨论串里追踪，文件有清晰的版本标记。几个客户在不同场合问了同一个问题：这是你们自己做的系统吗？我们自己的团队也能用吗？

这个反应让 Fried 意识到，37signals 面对的问题不是特殊的——任何规模相近、以知识工作为主的团队，都面临类似的项目管理困境。如果客户在使用这个工具之后愿意为自己的团队采用，那么市场需求是真实存在的。

2004年初，37signals 决定把这个内部工具作为独立产品发布，命名为 Basecamp。

产品发布的方式非常低调：没有大规模的公关活动，没有销售团队，只是在公司博客上发布了一篇介绍文章，然后开放注册。定价采用了 SaaS 的月订阅模式，从每月24美元到149美元不等，基于项目数量分级，没有按用户数量收费——这个定价策略在当时的企业软件市场里是相当反传统的。

第一年：收入超过设计业务

Basecamp 发布之后的第一年，它的收入增长速度出乎了 37signals 所有人的预期。

产品的传播方式完全是口碑驱动的：一个团队开始使用，觉得有效，推荐给其他团队，其他团队推荐给他们的客户，客户又推荐给他们自己的合作方。这个传播网络建立在一个简单的事实上：Basecamp 解决了一个普遍存在的问题，而且解决方案的使用门槛足够低，任何团队都能在一天之内开始有效使用。

到2004年底，Basecamp 的月订阅收入超过了 37signals 客户设计业务的收入。这是一个清晰的商业信号，也是一个需要做选择的时刻。

Fried 和团队决定转型。他们没有立即完全放弃设计业务，但他们开始把主要的工程和产品资源投入 Basecamp，以及一批类似工具的开发——Backpack（个人信息管理）、Campfire（团队即时通讯）、Highrise（联系人管理）。37signals 从一家设计公司，逐渐转变成一家专注于简单协作工具的软件公司。

Rails：从内部框架到改变Web开发的工具

Basecamp 的故事里有一个经常被提到但常常被低估的副产品：Ruby on Rails。

Hansson 在构建 Basecamp 时，使用的是 Ruby 语言，并在这个过程中发展出了一套构建 Web 应用的框架，他后来把这个框架提取出来，以开源的方式发布，命名为 Ruby on Rails。

Rails 在2004到2010年代，是 Web 开发领域影响最深远的框架之一。它推广了”约定优于配置”（Convention over Configuration）的设计哲学——框架预设了大量合理的默认设置，让开发者可以专注于业务逻辑而不是基础配置。这个哲学影响了后续几乎所有主流 Web 框架的设计。

Rails 的用户包括 GitHub（在成为 GitHub 之前）、Shopify、Airbnb（早期）、Twitter（早期），以及无数的早期 YC 创业公司。从某种意义上说，Basecamp 的真实影响，不只是一个项目管理工具，还包括了 Rails 对整个 Web 开发生态的塑造。

“不需要投资人”的声明

Basecamp 的商业史里有一件值得单独提出来的事：他们几乎不接受外部融资。

在 SaaS 创业公司普遍追求融资、快速扩张的文化里，37signals 的立场是一个异类。Fried 和 Hansson 多次公开表达了对风险投资模式的质疑：融资带来的不只是资金，还有对增长速度的预期和对退出策略的要求。这两者都与他们对公司应该如何运营的想法相悖。

他们的观点在2010年出版的《Rework》一书里有详细的阐述：公司不需要为了增长而存在，可以是一个稳健的、有利润的小公司，服务好自己的用户，保持对产品的完全控制权。这本书在创业圈里产生了广泛的影响，挑战了”融资→扩张→上市”作为创业唯一合法路径的主流叙事。

37signals 最终在2023年把 Basecamp 之外的产品（Hey 邮件服务等）拆分，更名为 37signals，同时 Basecamp 作为独立品牌继续运营。公司从未上市，从未进行大规模融资，在2024年依然是一家私有公司，员工规模保持在相对精简的水平。

这个选择本身，成为了 Basecamp 品牌故事的一部分：一家拒绝了标准创业成功路径的公司，用自己的方式证明了另一种商业模式的可行性。

从2003年那个被自己的混乱搞垮的设计公司，到一个在Web开发工具史上留下了两个独立印记（Basecamp产品和Ruby on Rails框架）的公司，37signals 走的路不是最快的，但对于 Fried 来说，可能是最符合他对”一家好公司应该是什么样子”这个问题的答案的。

“我们不是因为天才的灵感创造了 Basecamp，而是出于绝望的必要性。最好的产品往往不是来自洞见，而是来自亲身的痛苦。” — Jason Fried