vlog
← 返回全部文章

Tech

They Rebuilt Monday.com in a Weekend. Then Monday Started.

July 7, 2026 · Marcus Webb, Hackers and Painters~5 min read

A handful of CNBC journalists — not engineers, journalists — sat down with AI coding tools over a single weekend and rebuilt the core of Monday.com, a project-management platform worth billions. Two days. Monday's stock dropped. The commentary that followed had a name for it by Monday morning: the SaaSpocalypse. If a few reporters can clone your product in a weekend, the thinking went, what exactly are your customers paying you for?

The demo that scared a stock price

Here's the thing about that weekend build: it's real, and it's genuinely impressive, and it proves less than everybody thinks. Building software got cheap. That part's true. An internal tool that used to eat months of a specialized team's time, you can now stand up in a few days — sometimes over a weekend, apparently, if you're a journalist with something to prove. Nobody's arguing with that. The typing part of software, the part where you turn an idea into working code, fell off a cliff, price-wise.

But watch what got measured there. Somebody built a thing that runs today. They took a snapshot. What the snapshot doesn't show you is the next Tuesday, when a dependency ships a security patch that breaks the login flow. Or the Tuesday after that, when the payments provider changes an API and nobody gets a heads-up. That's not the demo. That's the job.

You don't finish software. You run it.

The whole SaaSpocalypse read makes one quiet mistake, and everything else falls out of it: it treats software like something you finish. You don't finish software. You run it. Security updates land whether you asked or not. Integrations snap without warning. Regulations move. The workflow inside your own company drifts. Users change their minds — constantly, and never in writing. None of that is an edge case you patch later. That is the system. That's what the thing is once it's alive.

And the real cost of software lives there — after deployment, not before. Software spends most of its life being maintained, not written. AI changed how fast you can produce the first version. It did not touch the weight of keeping the thing on its feet, and that weight is most of what software costs over its life. This is the misread that a two-day demo can't catch, because a demo is a photograph of the one moment when everything works.

CHEAPER TO BUILD. NOT CHEAPER TO RUN.The run costthe same weight, forevermaintenance · security updates · integrations · regulation · one ownerBUY SAAS · SPREAD THINThe vendorcustomercustomercustomercustomersplit across thousandsBUILD IT YOURSELF · CONCENTRATEDOne orga few people whounderstand itreliance on individuals+ you now pay for enterprise AI dev toolswhere run cost landsnew bill
Software is cheap to build now — but the real cost sits after deployment, in running it: maintenance, security updates, integrations, shifting regulation, and one owner who understands the system. SaaS spreads that weight across thousands of customers; an internal build concentrates it in one org and a few people. Source: "Is the 'SaaSpocalypse' a myth?", The Next Web, 2026-07-06. Framing: Paul Graham, Hackers and Painters. One working engineer's read, not a verdict on any tool.

What SaaS was actually selling you

A SaaS vendor takes all of that — the maintenance, the upgrades, the 2 a.m. support ticket, the compliance paperwork — and smears it across thousands of customers. The burden's still there. It just gets absorbed into the product and split so many ways you stop noticing it's a cost at all. That's the real thing you're renting. Not the login screen. The person who fixes the login screen when it breaks next quarter.

Rip out the SaaS and build it yourself, and none of those chores vanish. They concentrate. They land inside one company — the same company that now pays for the enterprise AI dev tools instead of the old subscription. And there's a second bill nobody prices in: every system needs an owner. Build internally and the roadmap, the incidents, the support all pile onto a small number of people who actually understand the thing. Companies think they're killing vendor lock-in. What they've really done is trade it for reliance on a couple of individuals — and that's usually a worse trade. An AI-assembled system tends to carry less shared documentation and fewer durable reference points, so the day the builders walk out the door, what's left is harder to read and quicker to break.

Build-vs-buy was never a price tag

It's a question of where the operational weight should sit — spread thin across a vendor's thousands of customers, or piled inside your own shop on the few people who understand it.

What this means for you before you kill that subscription

So before you look at that weekend demo and cancel the SaaS line item, ask the question the demo can't answer: where do you want the running to live? If the answer is "on two engineers who could quit," you didn't remove a risk, you moved it — probably somewhere worse. Build-vs-buy is not a cost exercise. It's a question about who owns the maintenance, the security, the boring Tuesdays, and how much of that complexity you're willing to carry, year after year, after the applause dies down. AI made software cheaper to build. It did not make it cheaper to run. Those are two different numbers, and only one of them showed up in that weekend.

Paul Graham, in Hackers and Painters, has a line I keep coming back to: a painting is never finished — you just stop working on it. Software's the same, except worse, because you don't even get to stop. He also wrote about how Leonardo would paint the background of a picture nobody was ever going to look at closely — the invisible work, the part that decides the quality. That's your maintenance. That's the security patch and the integration fix. Nobody claps for it. It doesn't make a demo. It's just where the software actually lives, and where the money actually goes.

Framing drawn from Paul Graham, Hackers and Painters (a painting is never finished, you just stop working on it; the unseen background is where quality lives; wealth is durable value, not the first build). Facts on the weekend rebuild, the SaaSpocalypse, and where software cost actually sits are from "Is the 'SaaSpocalypse' a myth? The real cost of AI-built software," The Next Web (July 6, 2026). This is a fast-moving field and one working engineer's read, not a verdict on any specific tool — for plenty of teams, building beats buying.

技术

他们一个周末重建了 Monday.com——然后,Monday 才刚刚开始

2026年7月7日 · 陈志远,《黑客与画家》约 4 分钟

几个 CNBC 的记者——注意,是记者,不是工程师——一个周末抱着 AI 编程工具坐下来,把 Monday.com 的核心功能给重建出来了。Monday.com 是个市值几十亿的项目管理平台。两天。Monday 的股价应声往下掉。跟着冒出来的那堆评论,周一早上就给这事儿起好了名——SaaSpocalypse,SaaS 大崩塌。几个记者一个周末就能把你的产品克隆一份,那你的客户,到底在付钱买啥?

一个把股价吓崩的 demo

这个周末速建,是真事,也是真唬人,可它证明的东西比大家以为的少得多。造软件,是变便宜了,这话没错。以前得一个专业团队啃好几个月的内部工具,现在几天就能支起来——照这架势,记者带着一股要证明点什么的劲儿,一个周末也行。这没啥可抬杠的。软件里"打字"那一段,就是把点子变成能跑的代码那一段,价钱确实是跳崖式往下掉了。

可你得盯着它到底量了个啥。有人把一个今天能跑的东西造出来了,拍了张快照。快照没告诉你的是下个礼拜二:某个依赖推了个安全补丁,把登录流程给整挂了。或者再下个礼拜二,支付方悄没声改了个 API,谁都没提前收到信儿。那不是 demo。那才是这份活儿。

软件这东西,你不是"做完",是"跑着"

整个 SaaSpocalypse 的说法,犯了一个不吭声的错,剩下的全从这儿掉出来:它把软件当成一个你能"做完"的东西。软件你做不完。你只能跑着它。安全更新,你没求它也照落。集成,说断就断,招呼都不打。法规在动。你自己公司里那套流程也在慢慢挪。用户还老改主意——一天到晚改,还从来不写下来。这些没一样是"边角情况、回头再补"的。这就是系统本身。这玩意儿一旦活了,它就长这样。

而软件真正的成本,就住在这儿——在部署之后,不在之前。软件这辈子,大半时间是被维护,不是被写出来。AI 改的是你造头一版能多快。它压根没碰"把这东西撑住不倒"的那份分量,而这份分量,才是软件一辈子花掉的钱的大头。这就是两天 demo 抓不住的那个误读——因为 demo 是一张照片,拍的正好是万事俱备、一切都严丝合缝的那一瞬。

造它变便宜了,跑它没有跑起来的成本同样的分量,一直背维护 · 安全更新 · 集成 · 合规变动 · 得有个人管买 SAAS · 摊薄供应商客户客户客户客户分摊到成千上万人自己造 · 全压一处一家公司懂这套系统的那几个人变成依赖个人+ 现在还得为企业级 AI 开发工具掏钱跑的成本落这新账单
软件现在造起来很便宜——可真正的成本在部署之后,在跑它:维护、安全更新、集成、合规变动,还得有个真懂这套系统的人。SaaS 把这份分量摊到成千上万的客户身上;自己内部造,则把它全压在一家公司、几个人身上。来源:"Is the 'SaaSpocalypse' a myth?",The Next Web,2026-07-06。框架:保罗·格雷厄姆《黑客与画家》。一位一线工程师的解读,不是对任何工具的判决。

SaaS 其实卖给你的是啥

SaaS 供应商,是把这一整摊——维护、升级、凌晨两点的工单、合规那堆文书——全糊到成千上万个客户身上,一抹平。负担还在,只是被吸进了产品里,摊得七零八落,摊到你根本感觉不出它是个成本了。你真正租的是这个。不是那个登录界面。是下个季度它坏了、有人来修它的那个人。

你把 SaaS 拔掉、自己造,这些杂活儿一样都不会消失。它们只会往一处挤。全落进一家公司里——就是那家现在不再交订阅费、改交企业级 AI 开发工具钱的公司。还有笔账没人算:每套系统都得有个主人。自己内部造,路线图、线上事故、技术支持,全堆到少数几个真懂这东西的人头上。公司以为自己干掉了被供应商绑架,其实是拿它换成了对几个人的依赖——你别看这像是解套,多半是笔更亏的买卖。AI 拼出来的系统,往往共享文档更少、能留下来的参照点更少;等哪天造它的人拍屁股走了,剩下那摊,更难看懂、也更容易散架。

自建还是买,从来不是一道价签题

它问的是这份运维的分量该搁哪儿——是摊薄在供应商那成千上万个客户身上,还是全堆进你自家、压在那几个懂它的人身上。

这事儿在你砍掉那笔订阅之前,对你意味着啥

所以你看着那个周末 demo、正想把 SaaS 那笔账砍掉之前,先问一句 demo 答不上来的:这东西跑起来,你想让它跑在谁身上?要是答案是"跑在两个随时可能提离职的工程师身上",那你没除掉风险,你只是把它挪了个地方——多半还挪到了更糟的地儿。自建还是买,不是一道成本题。它问的是:这份维护、这份安全、这些无聊的礼拜二,归谁管;掌声散场之后,这堆复杂度,你愿意一年一年背下去多少。AI 让软件造起来更便宜了。它没让软件跑起来更便宜。这是两个数,那个周末只露了一个。

保罗·格雷厄姆在《黑客与画家》里有句话,我总想起来:一幅画永远不会完工,你只是不再画下去。软件也一样,还更惨——你连"不再画"的权利都没有。他还写过达·芬奇会去画一幅画里没人会凑近细看的背景——那些看不见的功夫,恰恰是定成败的地方。那就是你的维护。就是那个安全补丁、那个集成修复。没人为它鼓掌。它做不成一个 demo。它只是软件真正活着的地方,也是钱真正花出去的地方。

框架取自保罗·格雷厄姆《黑客与画家》(一幅画永远不会完工,你只是不再画下去;看不见的背景才是定成败之处;财富是持久的价值,不是头一版)。周末重建、SaaSpocalypse、以及软件成本究竟落在何处等事实,出自 "Is the 'SaaSpocalypse' a myth? The real cost of AI-built software",The Next Web(2026 年 7 月 6 日)。这是个快速演进的领域,也只是一个一线工程师的看法,不是给哪个具体工具下判决——对不少团队来说,自建确实比购买划算。

テクノロジー

週末で Monday.com を作り直した。そして、Monday が始まった

2026年7月7日 · 藤井亮、『ハッカーと画家』約 6 分

CNBC の記者が数人——エンジニアじゃなくて、記者です——ある週末、AI のコーディングツールを前に座って、Monday.com の中核機能を作り直してしまった。Monday.com は時価総額が数十億ドルのプロジェクト管理プラットフォームです。二日。Monday の株価が、すとんと落ちた。あとに続いた論評は、月曜の朝にはもう名前がついていて——SaaSpocalypse、SaaS の大崩壊。記者が数人で週末に製品をコピーできるなら、あなたの顧客は、いったい何にお金を払っているんですか、と。

株価を怯えさせた demo

この週末の突貫、本当の話だし、正直すごい。でも、みんなが思うほどのことは証明していないんですよね。ソフトを作るのは安くなった。そこは本当です。昔は専門チームが数ヶ月かじりついた社内ツールが、今は数日で立ち上がる——この勢いなら、何かを証明したい記者なら、週末でもいけるらしい。ここに文句はないです。ソフトの「タイピング」のところ、アイデアを動くコードに変えるところは、値段でいえば崖から落ちた。

ただ、そこで何が測られたのかを、ちゃんと見てほしくて。誰かが今日動くものを作った。スナップショットを一枚撮った。そのスナップショットが映していないのが、次の火曜日なんです。ある依存パッケージがセキュリティパッチを出して、ログインの流れが壊れる。あるいはその次の火曜、決済側が API を黙って変えて、誰にも一言もない。それは demo じゃない。それが、仕事なんですよね。

ソフトは「作り終える」んじゃない。「動かす」んです

SaaSpocalypse の見立ては、静かな取り違えを一つやっていて、残りは全部そこから転がり落ちてくる——ソフトを「作り終えられるもの」として扱っているんです。ソフトは作り終えられない。動かし続けるものなんですよね。セキュリティ更新は、頼まなくても降ってくる。連携は、前触れなくぷつっと切れる。規制は動く。自分の会社の中の業務フローも、じわじわずれていく。ユーザーは気を変える——ひっきりなしに、しかも書面には残さない。どれ一つ「後で直す例外」じゃない。それが系そのもの。ものが生きた瞬間、それが「そういうもの」になるんです。

そして、ソフトの本当のコストはそこに居座る——デプロイの後で、前じゃない。ソフトは一生の大半を、書かれる時間じゃなく、保守される時間で過ごす。AI が変えたのは、最初の一版をどれだけ速く作れるか。ものを倒れないように支え続ける重さには、手を触れていない。そしてその重さこそ、ソフトが一生で溶かすお金の大半なんですよね。これが、二日の demo には掴めない取り違え。だって demo は、すべてが噛み合った、その一瞬を撮った写真だから。

作るのは安くなった。動かすのは、なっていない動かすコスト同じ重さを、ずっと背負う保守 · セキュリティ更新 · 連携 · 規制変更 · 所有者が要るSAAS を買う · 薄く広げるベンダー顧客顧客顧客顧客何千人にも分かれる自分で作る · 一点に集中一つの組織それを分かっている数人だけ個人への依存+ 今度は企業向け AI 開発ツール代も払う動かすコストの落ち先新しい請求
ソフトは今や作るのが安い——けれど本当のコストはデプロイの後、動かし続けることに居座る:保守、セキュリティ更新、連携、変わる規制、そしてシステムを分かっている所有者。SaaS はその重さを何千もの顧客に分散させる。社内で作れば、それが一つの組織と数人に集中する。出典:"Is the 'SaaSpocalypse' a myth?"、The Next Web、2026-07-06。枠組:ポール・グレアム『ハッカーと画家』。動きの速い分野の、一エンジニアの読み方であって、特定のツールへの判決ではない。

SaaS が本当に売っていたもの

SaaS のベンダーは、そのひと山を丸ごと——保守、アップグレード、深夜二時のサポートチケット、コンプライアンスの書類仕事——何千もの顧客になすりつけて、ならしてしまう。負担は消えていない。ただ製品の中に吸い込まれて、ばらばらに分かれて、もうそれがコストだとすら気づかなくなる。あなたが本当に借りているのは、そこなんですよね。ログイン画面じゃない。来期それが壊れたとき直してくれる、その人です。

SaaS を引き剥がして自分で作っても、この雑用たちは一つも消えません。一点に寄っていく。ぜんぶ一つの会社の中に落ちる——サブスク代の代わりに、今度は企業向け AI 開発ツール代を払う、その同じ会社に。それに、誰も見積もらない二つ目の請求がある。どんな系にも所有者が要るんです。社内で作れば、ロードマップも、障害対応も、サポートも、その中身を本当に分かっている数人に積み上がる。会社は「ベンダーロックインを断ち切った」と思っている。でも実際にやったのは、それを数人への依存と取り替えただけ——たいてい、もっと悪い取引なんですよね。AI で組み上げた系は、共有ドキュメントが薄くて、残る手がかりも少なくなりがちで、作った本人が去った日、後に残るのは、読みにくくて、壊れやすいものなんです。

作るか買うかは、最初から値札の話じゃない

運用の重さをどこに置くか、という話です——ベンダーの何千もの顧客に薄く分けるのか、それとも自分の店の中、それを分かる数人の上に積み上げるのか。

そのサブスクを止める前に、これがあなたに何を意味するか

だから、あの週末 demo を見て SaaS の項目を解約する前に、demo には答えられない問いを一つ。動かし続けるこの仕事を、誰の上に置きたいですか。答えが「いつ辞めてもおかしくない二人のエンジニア」なら、リスクを消したんじゃなくて、動かしただけ——たぶん、もっと悪い場所へ。作るか買うかは、コストの計算じゃない。保守を、セキュリティを、退屈な火曜日たちを、誰が所有するのか。そして拍手が鳴りやんだ後、その複雑さを、何年も何年も、どれだけ背負う気があるのか。AI はソフトを作るのを安くした。動かすのを安くはしていない。これは別々の二つの数字で、あの週末に出てきたのは、片方だけなんですよね。

ポール・グレアムが『ハッカーと画家』に書いた一言を、僕はよく思い出します——絵は完成することはない、ただ描くのをやめるだけだ、と。ソフトも同じで、もっと厳しい。「やめる」ことすら許されないから。彼はまた、レオナルドが、誰も近くで見やしない絵の背景を描き込んだ話も書いています——目に見えない仕事、質を決めるのはそこだ、と。それがあなたの保守です。あのセキュリティパッチ、あの連携の直し。誰も拍手しない。demo にはならない。ただ、そこがソフトの本当に生きている場所で、お金の本当に出ていく場所なんですよね。

枠組はポール・グレアム『ハッカーと画家』から(絵は完成することはなく、ただ描くのをやめるだけ;目に見えない背景こそ質を決める場所;富とは持続する価値であって最初の一版ではない)。週末の作り直し、SaaSpocalypse、そしてソフトのコストが実際どこに居座るか等の事実は "Is the 'SaaSpocalypse' a myth? The real cost of AI-built software"、The Next Web(2026 年 7 月 6 日)から。動きの速い分野の、現場の一エンジニアの読み方であって、特定のツールへの判決ではありません——多くのチームにとって、作るほうが買うより理にかなうこともあります。