I replaced a $120/year micro-SaaS in 20 minutes with LLM-generated code

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:

1. SaaS is a pure software product. People who pay SaaS vendors do so because it’s cheaper to buy this software than build it.
2. LLMs dramatically reduce the time and cost of building custom software.
3. 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
• Deployed it

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.