On August 19, 2026, Chris Frantz posted a loop that a lot of people recognized: everyone I know is canceling software and rebuilding internally — while their customers are canceling and rebuilding their software internally. The post crossed a quarter million views. The replies split into a useful argument (this is good churn if the clone is shallow) and a useful warning (you live in a bubble; not everyone is a builder; good luck rebuilding Loops).
The question people typed next was not "is Frantz right." It was is software dying or changing?
It is changing. The dying part is a specific layer: software that was rented because a custom build used to cost a team-year, and now costs a weekend plus a person who will still own it. That is not the death of software. It is the build vs buy line moving.
TL;DR — is software dying?
| Question | Direct answer |
|---|---|
| Is software dying? | No. Thin, high-price, low-ops tools are getting rebuilt. Hard-ops products are not. |
| What flipped? | Coding agents made a specified internal tool cheaper to make than to rent — if you will maintain it. |
| What are people canceling? | Dashboards, internal CRUD, lightweight SaaS they used as a substitute for a hire. |
| What are they keeping? | Infra, identity, payments, deliverability, compliance, anything that fails loudly at 3 a.m. |
| Is that good for vendors? | Good churn if those customers never needed your hard problem. Bad churn if they did. |
| Is everyone a builder now? | No. Agents lowered the floor. Most buyers still will not operate the clone. |
| How does the loop end? | At layers where code is cheap and running it is not. Long infra. |
Is software dying or changing?
Changing. Software as a capability is accelerating. Software as a rental of a thin UI over a generic workflow is under price pressure.
That split is already on this site under other names. A software factory is the claim that custom internal software can become a gated process for companies that are not software companies. Software for one is the household version. 2x, not 10x is the productivity version: agents move the bottleneck from keystrokes to judgment and verification. Frantz's tweet is the vendor version of the same shift: if your product was the keystrokes, your customer can now buy the agent instead of you.
The profession is not dying either. The kache debate landed in the same place: implementation gets cheaper; coordination, taste, and the hard problem do not.
What are they canceling — and what are they keeping?
Frantz, when asked which software, waved at everything, then named a favorite: companies pitching turning off the OpenAI spigot because they will "roll their own" with off-the-shelf models. Treat that as a category, not a census. Public tweets are not a churn dashboard.
A more honest split:
| Rebuild candidate | Keep / still buy | Why the line sits there |
|---|---|---|
| Internal admin panels | Auth, SSO, audit logs | The form is cheap; the identity blast radius is not |
| "Lightweight CRM" for 12 people | CRM with workflow, integrations, and legal hold | Prototype vs years of edge cases |
| Reporting dashboards | The warehouse, the pipeline, the access control | Charts are glue; data plane is ops |
| Thin GPT wrappers | Model APIs, evals, routing, spend caps | You can clone a chat box; you cannot cheaply clone reliability and billing |
| Seat-based tools nobody loves | Products whose outage is your outage | Hate is not the same as replaceability |
Vibe coding is how the first column gets a demo. It is not how the second column stays up. Mitchell Hashimoto's line still applies: you still cannot vibe-code a commercial-grade product and call the job done. The rebuild wave is real for low-maintenance clones. It is a fantasy for "we replaced Stripe this sprint."
Replies that said good luck rebuilding Loops are pointing at that second column. Email is not a form. It is deliverability, bounce handling, reputation, and a decade of "this provider marked us as spam." Frantz's own aside — there is enough to build to keep ten engineers busy for years — is the vendor admitting the clone is not the product.
Good churn, bad churn, and the bubble
One reply framed the tweet as good churn: if a customer can vibe-code something low-maintenance to their needs, they were never your genuine customer. Resources go back to people who still have the hard problem. Frantz called it a great take.
That is the charitable reading, and it is sometimes true. It is also how a company talks itself into shrinking until only the hardest 10% of the old TAM is left — which can be a great business, or a round-trip to "we accidentally became infra."
The uncharitable reading is the bubble: everyone you know is a builder with a coding agent and a willingness to own pager duty. Most companies are not. Most departments will not maintain the clone after the person who prompted it leaves. That is shadow IT with a better origin story.
A third reply cut through the slogan: sell to customers who do not have the core competency to build internally. Frantz joked that he thought everyone was a builder now. They are not. Agents increased the number of builders. They did not make "I will run this in production" a mass consumer behavior.
Use all three:
- Good churn if the leaving customer only needed a form.
- Bubble if your feed is only people who ship on weekends.
- Positioning if your remaining buyers are the ones who will never want the pager.
Rolling your own model is the same mistake at a different layer
"Turn off the OpenAI spigot" is the model-layer version of canceling SaaS. Sometimes it is rational: build vs buy for models is a real executive decision, off-the-shelf weights exist, and routing layers exist so you are not married to one lab.
Often it is a pitch. Serving a frontier-quality model, with evals, rate limits, abuse handling, and a bill someone will sign, is not "we downloaded the weights." The code to call a model got cheap. The system that is a model company did not. That is why "become an LLM provider" in the replies is a joke with a kernel: the durable businesses in this loop look like infra, not like another CRUD app.
If you are actually leaving a lab API, you still need a routing and spend story — not a slogan. That is a finance-and-ops problem, which is why it belongs in an ROI framework rather than a vibe session.
What this means for what you build or pay
If you buy software: write down the job, the 3 a.m. failure, and whether you will staff the clone. Cancel the seats where the job is a form and someone on your team will own the repo. Keep the seats where failure is legal, reputational, or unbounded. Do not confuse a working demo with a replacement. Put tests on the rebuild or you are not running a software factory — you are running shadow IT.
If you sell software: assume the shallow 40% of your surface can be cloned. Price and roadmap the 60% that cannot — integrations, reliability, compliance, the workflow your customer cannot prompt into existence. Headless APIs so their agents can operate your hard layer (headless SaaS) is the vendor-side adaptation. A seat tax on a thin UI is the product the tweet is canceling.
If you build internal tools: start with one workflow that has a written "done," then loop. That is loop engineering, not a rewrite of the company. Agents are 2x on coding time, not a license to replace your bank.
If you are tempted to "just rebuild it": ask who gets the pager, who reviews the diffs, and what happens when the original prompter quits. Those three answers decide whether this is changing software or dying reliability.
A cancel-vs-keep checklist
Use this before you kill a vendor or start a rewrite:
- Can you write a failing test for "done"? If not, you do not have a spec. You have a vibe.
- What fails at 3 a.m.? If nothing, rebuild is plausible. If lawyers, customers, or regulators show up, keep paying.
- Is this good churn for the vendor — or are you their actual job? If you only used 10% of the product, leaving is healthy. If you used the hard 10%, you will rebuild it badly.
- Will this be maintained after the person who prompted it leaves? If the honest answer is no, you are buying a future outage.
- Are you cloning a UI or an operation? UIs got cheap. Operations did not.
- Are you in a builder bubble? If your sample is Twitter, widen it to the department that still files tickets in email.
How this all ends
Not with software disappearing. With thinner apps and thicker substrates.
Everyone who can will make their own small software — personal apps, internal factories, one-off dashboards. Vendors who only sold the small software will feel like the industry is ending. Vendors who sold the substrate — hosting, identity, payments, models, deliverability, the thing that has to work when nobody is watching — will feel like demand went up.
The recursive loop Frantz described is real. It ends when you hit a layer you cannot vibe-code an on-call rotation for. That is not a crash. It is a re-sorting of what "buying software" meant when custom was expensive.
Software is not dying. The rental of easy software is getting competed by agents. The operation of hard software is still the job.
Related on explainx.ai
- AI wrote a macOS driver for a Windows-only HP — the right problem, not a screenshot as proof (Aug 20)
- What is a software factory? The SMB promise
- Software for one: personal apps with coding agents
- Headless SaaS for agents, charge per interaction
- AI ROI framework — build vs buy for executives
- What is vibe coding?
- "2x, not 10x" — what coding with LLMs actually delivers
- Programming as low-intelligence work — the kache debate
- Mitchell Hashimoto — you cannot vibe-code commercial-grade apps
- Loop engineering for coding agents
- Good Churn · Shadow IT · Software Factory · Vibe Coding
Primary: Chris Frantz on X (August 19, 2026)
The Frantz thread is a snapshot of builder-feed sentiment on August 19–20, 2026, not a market survey. "Everyone is canceling software" is a vibe, not a churn dataset. Treat cancel-vs-keep as a checklist against your own pager and spec, not as a forecast that SaaS disappears.