Earlier quoted context omitted.
We just had a $240/year renewal for teamretro.com come due, and while TeamRetro has a lot of components, we are only using the retro and ice breaker components. So I gave Claude Code a couple of prompts and I now have a couple static HTML pages that do the ice breaker (using local storage) and the retro (using a Google sheet as the storage backend, largely because it mimics our pre-teamretro process). It took me no m…
If you're a typical software engineer, that time probably cost your company more than $240.
AI agents are starting to eat SaaS
361–370 of 398 posts
Re: AI agents are starting to eat SaaS
#362Earlier quoted context omitted.
It matters to the comparison being made between the dot com boom and an ai boom, they have completely different fundamentals outside of the hype train. There were not as many consumers buying online during dot com boom. To the extent currently more is being spent on AI than anything in the dot com boom. Nor did companies run their businesses in the cloud, because there was no real broadband. There’s no doubt there’s…
I don't pay anyone for an image generator AI, because I can run an adequate image generator locally on my own personal computer. My computer doesn't have enough RAM to run the state of the art in free LLMs, but such computers can be bought and are even affordable by any business and a lot of hobbyists. Given this, the only way for model providers to stay ahead is to spend a lot on training ever better models to beat…
The best price for dollar/watt of electricity to run LLMs locally is currently apple gear.
I thought the same as you but I'm still able to run better and better models on a 3-4 year old Mac.
At the rate it's improving, even with the big models, people optimize their prompts so they run efficiently with tokens, and when they do.. guess what can run locally.
The dot com bubble didn't have comparable online sales. There were barely any users online lol. Very few ecommerce websites.
Let alone ones with credit card processing.
Internet users by year: https://www.visualcapitalist.com/visualized-the-growth-of-gl...
The ecommerce stats by year will interest you.
Re: AI agents are starting to eat SaaS
#363This article made no sense to me. It is talking about AI-generated code eating SaaS. That's not what is going to replace SaaS. When AI is able to do the job itself — without generating code — that's what is going to replace SaaS. AI-generated code still requires software engineers to build, test, debug, deploy, secure, monitor, be on-call, handle incidents, and so on. That's very expensive. It is much cheaper to pay…
Perhaps OP's argument still applies to dev-oriented SaaS. Are you as a dev still going to pay for analytics and dashboards that you could have propped up by Claude in 5 minutes instead?
Re: AI agents are starting to eat SaaS
#364I'm CTO at a vertical SaaS company, paired with a product-focused CEO with deep domain expertise. The thesis doesn't match my experience. For one thing, the threat model assumes customers can build their own tools. Our end users can't. Their current "system" is Excel. The big enterprises that employ them have thousands of devs, but two of them explicitly cloned our product and tried to poach their own users onto it.…
It's a bit surprising to me that Microsoft hasn't created a product that's "you have an Excel file in one of our cloud storage systems, here's a way for you to vibe code and host a web app whose storage is backed entirely by that file, where access control is synced to that file's access, and real-time updates propagate in both directions as if someone were editing it in native Excel on another computer. And you can…
In my experience, it's actually quite hard to move a business from an excel sheet to software. Because an excel sheet allows the end user to easily handle every edge case and they likely don't even think in terms of "edge cases"
Re: AI agents are starting to eat SaaS
#365I'm CTO at a vertical SaaS company, paired with a product-focused CEO with deep domain expertise. The thesis doesn't match my experience. For one thing, the threat model assumes customers can build their own tools. Our end users can't. Their current "system" is Excel. The big enterprises that employ them have thousands of devs, but two of them explicitly cloned our product and tried to poach their own users onto it.…
Many SaaS products I am interested in have very little “moat”. I am interested in them not because I can’t build them, but because my limited engineering time is better spent building business specific stuff.
Many products with product management teams spend a lot of their effort building functionality either to delight their highest paying customers, or features that are expected to be high-revenue.
I’m never going to be your highest paying customers, so I’m never going to get custom work from you (primarily orienting workflows to existing workflows inside your customers).
What everyone wants when they buys SaaS is to get value from it immediately without having to change our internal processes, broken as they are. But your model of feature prioritization is antithetical to this; you don’t want to build or support the 5-10 integration points I want; because that would allow me to build my own customizations without paying for your upsells.
You aren’t at immediate risk from agentic Ai from losing your big customers. But Agentic AI is enabling me and thousands of others to build hobby projects that deliver part of your core value but with limitless integration. I expect that you’ll see bleeding from the smallish customers way before you see hits from your whales.
However in a couple of years there will be OSS alternatives to what you do, and they will only become more appealing, rapidly.
As a side note it’s not just license pricing that will drive customers to agentically-coded solutions; it’s licensing terms. Nowadays whenever I evaluate SaaS or open source, if it’s not fully published on GitHub and Apache or MIT licensed, then I seriously consider just coding up an alternative - I’ve done this several times now. It’s never been easier.
Re: AI agents are starting to eat SaaS
#366Earlier quoted context omitted.
It's a bit surprising to me that Microsoft hasn't created a product that's "you have an Excel file in one of our cloud storage systems, here's a way for you to vibe code and host a web app whose storage is backed entirely by that file, where access control is synced to that file's access, and real-time updates propagate in both directions as if someone were editing it in native Excel on another computer. And you can…
Probably because Microsoft knows vibe coding is _not_ an actual viable way to build production ready code and does not want to deal with the liability issues of prompting customers to move from a working Excel sheet to a broken piece of software that looks like it works. In my experience, it's actually quite hard to move a business from an excel sheet to software. Because an excel sheet allows the end user to easily…
https://support.microsoft.com/en-us/office/copilot-function-...
Re: AI agents are starting to eat SaaS
#367Classic tell this is tech bro-ese.
Re: AI agents are starting to eat SaaS
#368Earlier quoted context omitted.
I’m just imagining the sweat on the poor IT managers’ brow. They already lock down everything enterprise wide and hate low-code apps and services. But in this day and age, who knows. The cynical take is that it doesn’t matter and nobody cares. Have your remaining handful of employees generate the software they need from the magic box. If there’s a security breach and they expose customer data again… who cares?
That sweat doesn't lessen dealing with nightmare fly-by-night vendors for whatever business application a department wants. Sometimes, the devil you know is preferable -- at least then you control the source. Folks fail to realize the status quo is often the status quo because it's optimal for a historical set of conditions. Previously... what would your average business user be able to do productively with an IDE? W…
They liked buying SAP or M$ because it was fully integrated and turnkey. Every SaaS vendor they added had to be SOC2, authenticate with SAML, and each integration had to be audited… it was a lot of work for them.
And we were highly trained, certified developers. I had to sign documents and verify our stack with regulatory consultants.
I just don’t see that fear going away with agents and LLM prompts from frontline workers who have no training in IT security, management, etc. There’s a reason why AI tech needs humans in the loop: to take the blame when they thumbs up what it outputs.
Re: AI agents are starting to eat SaaS
#369I'm CTO at a vertical SaaS company, paired with a product-focused CEO with deep domain expertise. The thesis doesn't match my experience. For one thing, the threat model assumes customers can build their own tools. Our end users can't. Their current "system" is Excel. The big enterprises that employ them have thousands of devs, but two of them explicitly cloned our product and tried to poach their own users onto it.…
I don’t know what you build, but I’ll share some thoughts from the other side (customer): Many SaaS products I am interested in have very little “moat”. I am interested in them not because I can’t build them, but because my limited engineering time is better spent building business specific stuff. Many products with product management teams spend a lot of their effort building functionality either to delight their hi…
Nobody is building open source software for [niche professional vertical] in their spare time. It's not mass market. It's not something a developer encounters in their daily work and thinks "I could do this better." The domain knowledge required to even understand the problem space takes months to acquire, and there's no personal payoff for doing so.
The "OSS will appear" prediction works for horizontal tools. For deep vertical SaaS, the threat model is different: it's other funded startups or internal enterprise clones (both of which we've already faced and won against).
Re: AI agents are starting to eat SaaS
#370Earlier quoted context omitted.
I don’t know what you build, but I’ll share some thoughts from the other side (customer): Many SaaS products I am interested in have very little “moat”. I am interested in them not because I can’t build them, but because my limited engineering time is better spent building business specific stuff. Many products with product management teams spend a lot of their effort building functionality either to delight their hi…
The OSS point doesn't apply to every vertical. Open source applications come about when developers scratch their own itch. Developer tools, infrastructure, general purpose CRMs, project management get OSS alternatives because developers use them and want to build them. Nobody is building open source software for [niche professional vertical] in their spare time. It's not mass market. It's not something a developer en…
As a matter of fact, I am (in the computer security vertical) - look for an announcement on Hacker News at the beginning of the year. I suspect that others are too, but there's always a discoverability problem for niche tools in verticals that one doesn't participate in, e.g. I know nothing about software for dentists but I know that at least one exists, and that there are probably a lot of dentists who use it but resent the fees, features or support, and there are probably some dentists who could manage an agentic coding project.
There have ALWAYS been niche OSS projects, and agentic coding will make them better and more prolific.
There are people like me who are passionate about a space and have the skills to manage an agentic coding project and the domain knowledge to design the software that they want, but not the skills and time necessary to have built the software in the absence of agentic AI. Last year I would never have started my 100k+ LoC project. This year I am proposing colleagues at two Fortune 50 companies to adopt it (at zero financial benefit to me). I am doing this from love of the problem space and desire to improve software security across the industry.