LLM生成コードで120ドル/年のマイクロSaaSを20分で置き換えた話
著者はLLMを使用して20分で年間120ドルのマイクロSaaSサービスを置き換えることに成功し、LLMが特定のSaaSビジネスを脅かす可能性を示した。
キーポイント
LLMによるマイクロSaaSの置き換え実証
著者はCodexを使用して、年間120ドルかかっていたShoutout.ioのサービスを20分で自前のソリューションに置き換えることに成功した。
SaaSの複雑さによる存続可能性の議論
著者は当初、Workdayのような複雑なSaaSはLLMでは置き換えられないと考えていたが、シンプルなマイクロSaaSは容易に置き換え可能であることを実証した。
実用的なLLM活用プロセス
計画立案から実装、テスト、デプロイまで、LLMを活用した効率的な開発プロセスを具体的に示している。
ソフトウェアエンジニアへの影響
LLMが特定のSaaSを置き換えることで、ソフトウェアエンジニアの役割やSaaSビジネスの存続可能性に影響を与える可能性がある。
開発者と非開発者のLLM利用の違い
開発者はコマンドラインでの更新やLLMのコード出力検証に慣れているが、非開発者には障壁となり得る。また、UI構築時の修正判断など、開発経験があれば迅速に対応できる。
SaaSの置き換え容易性の条件
継続的価値を提供せず静的な機能に留まるSaaSは、LLMを活用した顧客による置き換えリスクが高い。一方、コンプライアンス対応や分析など動的・継続的サービスは置き換えが困難。
SaaSビジネスモデルへの影響
LLMによる顧客自身の置き換えが容易になれば、投資なしで収益を上げるSaaS転売モデルの持続性が低下する可能性がある。
影響分析・編集コメントを表示
影響分析
この記事は、LLMが特定のマイクロSaaSビジネスを脅かす可能性を示す実証例を提供している。複雑なSaaSとシンプルなSaaSでは影響が異なるが、LLMによるソフトウェア開発の民主化が進むことで、ソフトウェアエンジニアの役割やSaaSビジネスモデルに変化が生じる可能性がある。
編集コメント
LLMによる実用的なSaaS置き換え事例として、技術者や起業家にとって参考になる具体的な実証例。ただし、複雑なSaaS全体への影響については限定的な見方も必要。
ソフトウェア・アズ・ア・サービス（SaaS）がLLMによって淘汰されるという数々の主張に対して、私は懐疑的でした。この考えの背景にある理論は以下の通りです：
SaaSは純粋なソフトウェア製品である。人々がSaaSベンダーに支払うのは、そのソフトウェアを構築するよりも購入する方が安上がりだからだ。
LLMはカスタムソフトウェア構築の時間とコストを劇的に削減する。
したがって、ほとんどのSaaSベンダーは廃業するだろう。なぜなら、ほとんどの企業やチームは、チケット管理、会議、顧客関係管理などに必要なソフトウェアを書くようLLMにプロンプトするからだ。
私が懐疑的だった理由は、WorkdayのようなHRソフトウェアなどのSaaSは、単なるソフトウェア以上のものであるからです。例えばWorkdayは、コンプライアンス要件（各国の休暇手当に関するものなど）に対応し、正確性を保証し（現地規制に準拠した給与明細など）、時間の経過とともにソフトウェアが外部および内部環境の変化に対応し続けます。
しかし、今週、SaaSをLLMで置き換えることが今やどれほどばかばかしいほど簡単であるかを直接経験しました。私のウェブサイト pragmaticengineer.com には、この出版物についての実際のLinkedInやXの投稿を表示する「推薦文」セクションがあります。これはShoutout.ioという小さなサービスを利用しており、年間120ドルかかっていました。見た目はこんな感じでした：
そしてこれがバックエンドです：特別なものではなく、推薦文を追加、編集、再編成、削除する方法があるだけです。
私は4年間顧客でしたが、おそらく年に1回ログインする程度でした。最後のログインは、経費の年間請求書を取得するためでした。残念ながら、課金セクションが壊れていたので、サポートにメールを送ると、彼らは請求書の代わりに壊れたリンクを送ってきました。これは苛立たしいことでした：なぜ課金が壊れているSaaSにお金を払う必要があるのか？彼らが来年何を請求してくるかさえわかりませんでした。
そこで、LLMを使って自分のユースケースを迅速に再構築できるかどうか自問しました。私のユースケースは、SaaSそのものよりもはるかに単純でした：
既存の推薦文を同様の方法で表示する
新しい推薦文を簡単に追加できるようにする（例：何らかのJSON形式で推薦文を保存する）
見た目を良くする
驚いたことに、Codexを使ったこの作業全体は、開始から終了まで正確に20分しかかかりませんでした。私が取った手順は十分に単純明快でした：
このサードパーティ依存関係を削除し、すべての推薦文を自分のコードベース（GitHubリポジトリ、Netlifyにデプロイ）でホストする方法について、Codexに計画を立てるよう依頼した
計画を調整した：推薦文を別のJSONファイルに保存し、コンパイル時のビルドステップでHTMLに生成されるモジュール方式を推進した
このビルドステップをローカル環境とNetlifyのビルドトリガーの両方に追加した
ソリューションをテストした
UXを調整し、スキーマを生成した
最終結果は見た目は以前と同じですが、これらすべてをレンダリングするサードパーティ依存関係がなくなった点が異なります！
これはSaaS製品とソフトウェアエンジニアにとって何を意味するのでしょうか？
ソフトウェアエンジニアにとって意味すること：
開発者は、将来の更新にコマンドラインを使用することに（おそらく）一般ユーザーよりもはるかに慣れているでしょう。将来の推薦文を追加するには、AIエージェントを使ってコードベースに挿入してもらい、その後、見た目が良いことを確認する必要があります。これは私にとっては大したことではありませんが、LLMのコード出力を確認することに慣れていない人にとっては、致命的な欠点となる可能性があります。
開発者がSaaSを「移植」するのは、他の誰かがやるよりもはるかに速いです。最初にCodexにUIをコピーするよう指示しましたが、フレックスボックスモデルを使おうとしたため、間違っていました。私はこのUIレイアウトが望んでいないものであることを伝え、UIレイアウトにどのフレームワークを使用するかを決定する必要がありました。非開発者でもおそらくこれらすべてを理解できるでしょうが、より時間がかかるでしょう。
正直なところ、サードパーティの機能を書き直すのは楽しくて興味深いです。お勧めします。私がこのプロジェクトを引き受けた理由の一部は、これが興味深い挑戦になると期待したからです。実際にかかる労力よりも多いと思っていましたし、これらのツールがどれだけうまく機能するかについてより多く学びました。また、より体験するためにCodexを使用しました。
SaaSソフトウェアにとってこれが意味する可能性のあること：
SaaSを再構築することは、依然としてあなたの特定のユースケースを再構築するよりもはるかに難しいと感じられます。私はShoutoutをどのような意味でも「再構築」しませんでした。Shoutoutには、10種類の異なるプラットフォームからの引用の追加、認証、（私には機能しなかった）課金など、10倍以上の機能があります。
継続的な価値を提供しないSaaSは、顧客によって置き換えられるリスクがあります。Shoutoutは、私の推薦文を表示した後、継続的な価値を提供しません。この静的な性質は、置き換えが容易であることを意味します。対照的に、プラットフォームにコンプライアンスを維持し、分析やアラートを提供し、ビジネスに役立つ他のリアルタイムなことを行ってもらうために支払っている場合、再構築はより難しくなるでしょう。
SaaSビジネスの売買は、収益性が低くなる可能性があります。私が2021年に登録したShoutoutのオリジナルバージョンは、2020年に独立系開発者によって構築されました。2022年、この開発者はこのマイクロSaaSをプロダクトスタジオに売却しました。その後、2025年に、Shoutoutは新しい開発者たちに再び売却されました。私の観点からは、課金システムが壊れた以外、何も変わりませんでした。このSaaSの買い手は、投資ゼロで収益が上がり続けると考えたのでしょう。しかし、おそらくある時点で、壊れた製品にうんざりした人々が、特にそうすることがより安価である場合に、辞めてしまうと、それは真実ではなくなります。
「割れた窓」が修理されないことは、以前よりも許容されにくくなっています。私がShoutoutから離れるきっかけは、その課金システムが壊れていたことから始まりました。例えば、以下は私が請求書を確認するために課金セクションにアクセスしたときに見たものです：
これに加えて、カスタマーサポートは私のメールへの返信として壊れたリンクを送ってきました。それだけで、私はこの依存関係を置き換えることを決意するのに十分でした。そして、LLMを使って、何を構築したいかを知っていることで、これがどれほど簡単であるかに驚きました。カスタマーサポートが2時間後に動作するリンクを送ってきた頃には、私はすでにSaaSからの移行を完了していました。
このような記事をメールボックスで受け取るには、私の週刊ニュースレターを購読してください。かなり良い読み物です - Substackで第1位のテックニュースレターです。
原文を表示
I have been sceptical of the manifold claims that software-as-a-service (SaaS) will be killed by LLMs. The theory behind this idea is:
SaaS is a pure software product. People who pay SaaS vendors do so because it’s cheaper to buy this software than build it.
LLMs dramatically reduce the time and cost of building custom software.
Therefore, most SaaS vendors will go out of business because most companies/teams will prompt an LLM to write the software they need, such as for ticketing, meetings, customer relationship management, etc.
The reason for my scepticism has been that SaaS such as HR software Workday is more than just software. Workday, for example, keeps up with compliance requirements (e.g., for holiday pay in different countries), guarantees correctness (e.g., payslips that comply with local regulations), and over time the software keeps up to date with changes in the external and internal environments.
However, this week I had first-hand experience of how ridiculously easy it is now to replace SaaS with LLMs. On my website – pragmaticengineer.com – I have a testimonials section, which displays real LinkedIn and X posts about this publication. It cost $120/year for a small service called Shoutout.io, and looked like this:
And this is the backend: nothing fancy, just a way to add, edit, reorganize, and delete testimonials.
I was a customer for four years and logged in perhaps once a year. My latest login was to get an annual invoice for my expenses. Unfortunately, the billing section was broken, so I emailed support and they sent me a broken link instead of the invoice. This was frustrating: why pay for a SaaS with broken billing? I couldn’t even tell what they would charge me next year.
So I asked myself if I could rebuild my own use case with an LLM, and do it rapidly. My use case was much simpler than the SaaS itself:
Display existing testimonials in a similar way
Make it easy to add new ones, e.g., store testimonials in some JSON format
Make it look good
To my surprise, this whole effort from start to finish took exactly 20 minutes with Codex. The steps I took were straightforward enough:
Asked Codex to make a plan on how to remove this third-party dependency and host all testimonials in my codebase (a GitHub repo, deployed onto Netlify)
Tweaked the plan: I pushed for a modular approach where testimonials are in a separate JSON file, and they get generated into HTML with a compile-time build step
Added this build step both locally and as a build trigger on Netlify
Tested the solution
Tweaked the UX and generated a schema
The end result is visually the same as before, except I no longer have a third-party dependency rendering all of this!
What does this mean for SaaS products and software engineers?
What it means for software engineers:
Devs are (probably) a lot more comfortable using the command line for future updates than regular users. To add a future testimonial, I’ll need to turn to my AI agent to insert it in my codebase, and I’ll then need to verify that it looks good. This is not a big deal for me, but it might be a dealbreaker for someone not comfortable with verifying the code output of an LLM.
It’s a lot faster for a dev to “port” a SaaS than for anyone else. I first told Codex to copy the UI and it got things wrong because it tried to use a flexbox model. I had to tell it that this UI layout was not what I wanted, and then make the decision on which framework to use for the UI layout. A non-developer could probably figure all this out, but it would take longer.
Honestly, it’s fun and interesting to rewrite a third-party feature. I recommend it. Part of why I took on this project is because I expected it to be an interesting challenge. I thought the effort would be more than what it was, and I’ve learned more about how well these tools work. I also used Codex in order to experience it more.
What this could mean for SaaS software:
Rebuilding a SaaS still feels much harder than rebuilding your specific use case. I did not “rebuild” Shoutout in any way. Shoutout has 10x or more features, like adding quotes from 10 different platforms, authentication, billing (which didn’t work for me), and more.
A SaaS that doesn’t give ongoing value is at risk of being replaced by customers. Shoutout doesn’t provide ongoing value after it displays my testimonials, and this static nature means it’s easy to replace. In contrast, it would be harder to rebuild if I paid for the platform to stay compliant, provide analytics or alerting, and do other real-time things that helped my business.
Buying and selling SaaS businesses could become less profitable. The original version of Shoutout that I signed up for in 2021 was built in 2020 by an independent developer. In 2022, this developer sold this micro-SaaS to a product studio. Then, in 2025, Shoutout was sold again to new developers. From my point of view, nothing changed except that the billing system broke. I assume the buyers of this SaaS figured that revenue could keep rising with zero investment. But perhaps at some point that ceases to be true when people get fed up with a broken product and quit – especially when doing so is cheaper.
“Broken windows” not being fixed is less acceptable than it used to be. My journey away from Shoutout began with its billing system being broken. For example, below is what I saw when I went to my billing section to see the invoices:
As well as this, the customer support sent me a broken link in response to my email. That was enough for me to decide to replace this dependency, and I was surprised by how easy this was with an LLM and knowing what I wanted it to build. By the time customer support sent me a working link two hours later, I had finished migrating off the SaaS.
Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 tech newsletter on Substack.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み