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.
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 大崩塌。几个记者一个周末就能把你的产品克隆一份,那你的客户,到底在付钱买啥?
软件现在造起来很便宜——可真正的成本在部署之后,在跑它:维护、安全更新、集成、合规变动,还得有个真懂这套系统的人。SaaS 把这份分量摊到成千上万的客户身上;自己内部造,则把它全压在一家公司、几个人身上。来源:"Is the 'SaaSpocalypse' a myth?",The Next Web,2026-07-06。框架:保罗·格雷厄姆《黑客与画家》。一位一线工程师的解读,不是对任何工具的判决。
框架取自保罗·格雷厄姆《黑客与画家》(一幅画永远不会完工,你只是不再画下去;看不见的背景才是定成败之处;财富是持久的价值,不是头一版)。周末重建、SaaSpocalypse、以及软件成本究竟落在何处等事实,出自 "Is the 'SaaSpocalypse' a myth? The real cost of AI-built software",The Next Web(2026 年 7 月 6 日)。这是个快速演进的领域,也只是一个一线工程师的看法,不是给哪个具体工具下判决——对不少团队来说,自建确实比购买划算。
ただ、そこで何が測られたのかを、ちゃんと見てほしくて。誰かが今日動くものを作った。スナップショットを一枚撮った。そのスナップショットが映していないのが、次の火曜日なんです。ある依存パッケージがセキュリティパッチを出して、ログインの流れが壊れる。あるいはその次の火曜、決済側が API を黙って変えて、誰にも一言もない。それは demo じゃない。それが、仕事なんですよね。
ソフトは今や作るのが安い——けれど本当のコストはデプロイの後、動かし続けることに居座る:保守、セキュリティ更新、連携、変わる規制、そしてシステムを分かっている所有者。SaaS はその重さを何千もの顧客に分散させる。社内で作れば、それが一つの組織と数人に集中する。出典:"Is the 'SaaSpocalypse' a myth?"、The Next Web、2026-07-06。枠組:ポール・グレアム『ハッカーと画家』。動きの速い分野の、一エンジニアの読み方であって、特定のツールへの判決ではない。
SaaS を引き剥がして自分で作っても、この雑用たちは一つも消えません。一点に寄っていく。ぜんぶ一つの会社の中に落ちる——サブスク代の代わりに、今度は企業向け AI 開発ツール代を払う、その同じ会社に。それに、誰も見積もらない二つ目の請求がある。どんな系にも所有者が要るんです。社内で作れば、ロードマップも、障害対応も、サポートも、その中身を本当に分かっている数人に積み上がる。会社は「ベンダーロックインを断ち切った」と思っている。でも実際にやったのは、それを数人への依存と取り替えただけ——たいてい、もっと悪い取引なんですよね。AI で組み上げた系は、共有ドキュメントが薄くて、残る手がかりも少なくなりがちで、作った本人が去った日、後に残るのは、読みにくくて、壊れやすいものなんです。
枠組はポール・グレアム『ハッカーと画家』から(絵は完成することはなく、ただ描くのをやめるだけ;目に見えない背景こそ質を決める場所;富とは持続する価値であって最初の一版ではない)。週末の作り直し、SaaSpocalypse、そしてソフトのコストが実際どこに居座るか等の事実は "Is the 'SaaSpocalypse' a myth? The real cost of AI-built software"、The Next Web(2026 年 7 月 6 日)から。動きの速い分野の、現場の一エンジニアの読み方であって、特定のツールへの判決ではありません——多くのチームにとって、作るほうが買うより理にかなうこともあります。