I'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. One gave up. The other's users tell us it's crap. We've lost zero paying subscribers to free internal alternatives.
I believe that agents are a multiplier on existing velocity, not an equalizer. We use agents heavily and ship faster than ever. We get a lot of feedback from users as to what the internal tech teams are shipping and based on this there's little evidence of any increase in velocity from them.
The bottleneck is still knowing what to build, not building. A lot of the value in our product is in decisions users don't even know we made for them. Domain expertise + tight feedback loop with users can't be replicated by an internal developer in an afternoon.
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 eject a codebase that you, as the domain expert, can hand to a tech team to build something more broadly applicable for your organization."
Nowhere near the level of complexity that would enter your threat model. But this would be the first, minimal step towards customers building their own tools, and the fact that not even this workflow has entered the zeitgeist is... well, it's not the best news for some of the most bullish projections of AI adoption in businesses large and small.
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 handle every edge case and they likely don't even think in terms of "edge cases"
> 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.
Whilst you could plausibly argue that Microsoft have spent the past 25 years attempting to stamp them out, this is exactly what VB6 and VBA were.
People built whole businesses on/around these technologies, and people liked them because you could get something working fast. As maligned as they are nowadays they were so widely used because they delivered value.
I miss MSAccess, but for the modern age. It has been replaced by basic CRUD using your platform of choice, but it's not as easy.
That would be similar to your solution, so either one would work.
I think that there might be some similar alternatives (maybe Airtable? probably using Lovable or Firebase counts) but nothing that is available for me for now.
APEX is probably just as widely used now as Access was. Access likely had higher market share but of a much smaller market. There are gazillions of APEX apps out there.
You can use something like Salesforce as an app platform if you want. It lets you create "Custom Objects", which are basically tables, write queries, and so on.
It's just that the hassle of dealing with that platform tends to be similar to the hassle of setting up an app yourself, and now you're paying a per-user license cost.
Even Salesforce doesn't have a good way to quickly port an Excel-based workflow, with file handoffs and backwards compatibility, into Salesforce. In theory, you could have an LLM generate all the metadata files that would execute a relevant schema migration, generate the interface XML, and build the right kinds of API calls and webhooks... but understanding what it's doing requires a Ph.D. in Salesforce, and many don't have time for that.
Microsoft PowerApps has similar workflows for at least 2 years now. The professional development experience is lacking, however enterprise users can create many applications based on Excel files.
This is the answer to a happy B2B SaaS implementation. It doesn't matter what tools you use as long as this can be achieved.
In the domain of banking front/back office LOB apps, if you aren't iterating with your customer at least once per business day, you are definitely falling behind your competition. I've got semi-retired bankers insisting that live edits in production need to be a fundamental product feature. They used to be terrified of this. Once they get a taste of proper speed it's like blood in the water. I'm getting pushback on live reloads taking more than a few seconds now.
Achieving this kind of outcome is usually more of a meat space problem than it is a technology problem. Most customers can't go as fast as you. But the customer should always be the bottleneck. We've done things like install our people as temporary employees to get jobs done faster.
> Doesn't that violate all kinds of compliance controls?
Technically, only if it causes some kind of security, privacy, availability or accounting issue. The risk is high but it can be done.
Half of our customers do not have anything resembling a test environment. It is incredibly expensive to maintain a meaningful copy of production in this domain. Smaller local/regional banks don't bother at all.
Our sales teams heres the "we'll just build it internally" or "we can just throw it into an LLM" all of the time.
Yes, certain parts of our product are indeed just lightweight wrappers around an LLM. What you're paying for is the 99% of the other stuff that's (1) either extremely hard to do (and probably non-obvious) (2) an endless supply of "routine" work that still takes time (3) an SLA/support that's more than "random dev isn't on PTO"
No because it is never a credible bluff. You would not be having the conversation if it was.
In fact having sold stuff If a lead says this, it is a huge red flag for me that I probably don't want to do business with them because they are probably a "vampire customer"
LLMs can write surprisingly decent code a few hundred lines at a time but they absolutely can't write coherent hundred thousand line or bigger programs.
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 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.
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 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).
> Nobody is building open source software for [niche professional vertical] in their spare time.
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.
[niche professional vertical] in my response was a stand-in for the specific vertical my startup targets, which is light years from computer security. Computer security is a vertical where the practitioners are often developers or developer-adjacent. You're building tools for people like yourself. That's exactly the "scratch your own itch" dynamic I'm describing.
The vertical I'm in has zero overlap with the developer population. The end users aren't technical, don't participate on HN, and aren't going to "manage an agentic coding project." There's no equivalent of a developer who moonlights on OSS tooling because they're passionate about the problem space, because the problem space requires domain expertise that developers have no reason to acquire.
> For one thing, the threat model assumes customers can build their own tools.
That's not the threat model. The threat model is that they won't have to - at some point which may not be right now. End users want to get their work done, not learn UIs and new products. If they can get their analysis/reports based on excels which are already on SharePoint (or wherever), they'd want just that. You can already see this happening.
Yes. This is also why trying to add an AI agent chat into one's product is a fool's errand - the whole point of having general-purpose conversational AI is to turn the product into just another feature.
It's an ugly truth product owners never wanted to hear, and are now being forced to: nobody wants software products or services. No one really wants another Widgetify of DoodlyD.oo.io or another basic software tool packaged into bespoke UI and trying to make itself a command center of work in their entire domain. All those products and services are just standing between the user and the thing the user actually wants. The promise of AI agents for end-users is that of having a personal secretary, that deals with all the product UI/UX bullshit so the user doesn't have to, ultimately turning these products into tool calls.
I think that's just true in general. Business users at $work are already saying that they would rather just talk to ChatGPT (with voice for some reason I, a keyboard person, doesn't understand) than deal with GUIs. They want to describe what they need and have the computer do it, not click around.
Once you've abstracted away the UI (and the training on how to use it) it will be a lot easier to just swap one SaaS for another.
Yes, except for the fact that any non-trivial saas does non-trivial stuff that an agent will be able to call (as the 'secretary') while the user still has to pay the subscription to use.
Yes, but now it's easier for other SaaS to compete on that, because they don't get to bundle individual features under common webshit UI and restrict users to whatever flows the vendor supports. There will be pressure to provide more focused features, because their combining and UI chrome will be done by, or on the other side of, the AI agent.
Also, having to retrain users to use a new shitty UI after they got used to the previous shitty UI is a major moat of many SaaS services. The user doesn't care about the web portal, they just want to get work done. Switching to a different web portal needs to be a big net positive because users will correctly complain that now they are unproductive for a while because the quirks and bugs of the previous SaaS don't match those of the new SaaS.
In a world where the interface is "you talk to the computer" you will be able to swap providers way more easily.
That's the brilliance of AI - it doesn't matter if the product actually works or not. As long as it looks like it works and flatters the user enough, you get paid.
And if you build an AI interface to your product, you can make it not work in subtly the right ways that direct more money towards you. You can take advertising money to make the AI recommend certain products. You can make it give completely wrong answers to your competitors.
>> This is also why trying to add an AI agent chat into one's product is a fool's errand - the whole point of having general-purpose conversational AI is to turn the product into just another feature
We built an AI-powered chat interface as an alternative to a fully featured search UI for a product database and it has been one of the most popular features of 2025.
Sure, but it would be even better if it was accessible by ChatGPT[0] and not some bespoke chat interface you created - because with ChatGPT, the AI has all the other tools and can actually use yours in intelligent ways as part of doing something for the user.
> No one really wants another Widgetify of DoodlyD.oo.io
I keep hearing this and seeing people buying more Widgetify of DoodlyD.oo.io. I think this is more of a defensive sales tactic and cope for SaaS losing market share.
The president of a company I work with is a youngish guy who has no technical skills, but is resourceful. He wanted updated analytic dashboards, but there’s no dev capacity for that right now. So he decided he was going to try his hand at building his own dashboard using Lovable, which is one of these AI app making outfits. I sent him a copy of the dev database and a few markdown files with explanations regarding certain trickier elements of the data structure and told him to give them to the AI, it will know what they mean. No updates yet, but I have every confidence he’ll figure it out.
Think about all the cycles this will save. The CEO codes his own dashboards. The OP has a point.
I'd argue it's not CEOs job to code his own dashboards...
This sounds like a vibe coding side project. And I'm sorry, but whatever he builds will most likely become tech debt that has to be rewritten at some point.
Or to steel-man it, it could also end up as a prototype that forced the end user to deal with decision points, and can serve as a framework for a much more specific requirements discussion.
At a certain scale the CEO's time is likely better spent dictating the dashboard they want rather than implementing it themselves. But I guess to your point, the future may allow for the dictation to be the creation.
Agree, as engineers we should be making the car easier to operate instead of making everyone a mechanic.
Focus on the simple iteration loop of "why is it so hard to understand things about our product?" maybe you cant fix it all today but climb that hill more instead of make your CEO spend some sleepless nights on a thing that you could probably build in 1/10th the time.
If you want to be a successful startup saas sw eng then engaging with the current and common business cases and being able to predict the standard cache of problems they're going to want solved turns you from "a guy" to "the guy".
And I wonder if they will discover that in order to interpret those numbers in a lot of cases they will need to bring in their direct reports to contextualise them.
If corporate decisions could be made purely from the data recorded then you don't need people to make those decisions. The reason you often do is that a lot of the critical information for decision making is brought in to the meeting out-of-band in people's heads.
I have also seen multiple similar use cases where non-technical users build internal tools and dashboards on top of existing data for our users (I'm building UI Bakery). This approach might feel a bit risky for some developers, but it reduces the number of iterations non-technical users need with developers to achieve what they want.
Honestly, I'm not sure what to expect. There are clearly things he can't do (e.g. to make it work in prod, it needs to be in our environment, etc. etc.) but I wouldn't be at all surprised if he makes great headway. When he first asked me about it, I started typing out all the reasons it was a bad idea - and then I paused and thought, you know, I'm not here to put barriers in his path.
The Excel holy grail. Dashboard are an abstraction, SaaS is an abstraction of an abstraction from the pov of customers suffering from a one size fits all. Shell scripts generated by LLMs that send automated a customized reports via email will make a lot of corporate heros. No need to login, learn and use the SaaS in many instances for decisions makers.
I feel that large corps have guard rails that will limit this from happening. For SMB's, this is not a new problem. Gritty IT guys have been doing this for decades. I inherit these bootstrapped reporting systems all the time. The issue is when that person leaves, it is no longer maintainable. I've yet to come across a customer who has had any sort of usable documentation. The process then repeats itself when I take over, and presumably when I'm finished. With a SaaS product, you are at least paying for some support and visibility of the processes. I'm not really trying to make a point other than this is not a new, but still intriguing problem, and not sure that LLMs will be some god answer, as the organizations have trouble determining what they even need.
Yes, back in the heyday of Visual Basic (mid-1990s) we had one business analyst who learned enough to build dashboard-like apps with charts and graphs and parameters and filters. He was quick at it and because it was outside of IT there was little in the way of process or guardrails to slow him down. Users loved what he did, but when he left there was nobody else who knew anything about it.
I second this. Most of our customers IT department struggle to look at the responses from their failed API calls. Their systems and organisations are just too big.
As it stands today; just a bit of complexity is all that is required to make AI Agents fail. I expect the gap to narrow over the years of course. But capturing complex business logic and simplifying it will probably be useful and worth paying for a long time into the future.
Also, for many larger companies, access to internal data and systems is only granted to authorized human users and approved applications/agents. Each approval is a separate request.
This means for any "manual" or existing workflow requiring a access to several systems, that requires multiple IT permissions with defined scopes. Even something as simple as a sales rep sending a DocuSign might need:
- CRM access
- DocuSign access
- Possibly access to ERP (if CRM isn't configured to pass signed contract status and value across)
- Possibly access to SharePoint / Power Automate (if finance/legal/someone else has created internal policy or process, e.g. saving a DocuSign PDF to a folder, inputting details for handover to fulfilment or client success, or submitting ticket to finance so invoicing can be set up)
It is much easier to use an AI API in my bank than to use any other tool. Since the AI is from MS, it's ready to go, whereas other tools require a few months of budgeting, licenses, certs, and so on. Since AI/Azure/AWS is already there and 'certified to use,' it is easier for me to patch something together using this stack than to even ask for open-source software
Agreed. I've been on HN for 15 years, and IME maybe 90% of the value has come directly from comments (another 5% from links in commenters' profiles, and 5% from TFAs).
Yeah I think the real values is for the Solo developers, indie hackers & side projects.
Being unrestrained by team protocols, communications, jira boards, product owners, grumpy seniors.
They can now deliver much more mature platforms, apps, consumer platforms without any form of funding. You can easily save months on the basics like multi tenant set up, tests, payment integration, mailing settings, etc.
It does seem likely that the software space is about to get even crowdier, but also much more feature rich.
There is of course also a wide array of dreamers & visionairies who know jump into the developer role. Wether or not they are able to fully run their own platform im not sure. I did see many posts asking for help at some point.
As a solo grumpy senior, I've been pumping out features over the past 6 months and am now expanding into new markets.
I've also eliminated some third party SaaS integrations by creating slimmer and better integrated services directly into my platform. Which is an example of using AI to bring some features in-house, not primarily to save money (generally not worth the effort if that's the goal), but because it's simply better integrated and less frustrating than dealing with crappy third-party APIs.
> For one thing, the threat model assumes customers can build their own tools. Our end users can't.
Even if they could, the vast majority of them will be more than happy to send $20-100 per month your way to solve a problem than adding it to their stack of problems to solve internally.
You'd hear this all the time back when. "Oh you could build Twitter in a weekend". Yes. Also, very no. This mentality is now on agent steroids. But the lesson is the same.
The basic assumption is, that we already see that an LLM can do basic level of software engineering.
This wasn't even an option for a lot of people before this.
For example, even for non software engineering tasks, i'm at an advantage. "Ah you have to analyse these 50 excel files from someone else? I can write something for it"
I myself sometimes start creating a new small tool i wouldn't have tried before but now instead of using some open source project, i can vibe spec it and get something out.
The interesting thing is, that if i have the base of my specs, i might regenerate it later on again with a better code model.
And we still don't know what will happen when compute gets expanded and expanded. Next year a few more DCs will get online and this will continue for now.
Also tools like google firebase will get 1000x more useful with vibe coding. They provide basic auth and stuff like this. So you can actually focus on writing your code.
God, please no more firebase and mongo. AI coding is really really good at sql/relational data and there are services like supabase and neon that make it dead simple.
> The bottleneck is still knowing what to build, not building.
I'd amend this to "the bottleneck is being _interested_ in building."
The piece that is _constantly_ missing from AI discourse is that no amount of "breaking down barriers" will result in people who aren't interested in building, building.
I really think that it's as simple as that. Most either don't have the wherewithal or the interest to try and build something beyond the tools that are currently at their disposal -- they're just trying to complete a task, not build the tool that enables them to complete the task; the few that do become programmers. Thus, you have untold instances where "their 'system' is Excel," and programmers selling them solutions to replace it.
It's not intelligence, it's not knowledge, it's not even really aptitude. It's interest.
Another example of this is the reaction to more "creativity-focused" AI models: you see people acting like they've been gate-kept by having to know _how_ to do a thing in order to _do_ a thing, which is somehow this great injustice and AI has finally leveled the playing field so they can finally show those snooty artists who's boss (this attitude is _all over_ places like /r/aiwars). But the reality is that these people simply are not interested enough in music/photography/whatever to learn it, and will largely remain uninterested in the field once this moment is normalized and we get used to the new position of the goalposts. They don't like _creating_, they like _having created_ and whatever social cache they mistakenly believe comes with it (which explains their near-hatred of artists -- they are, very simply, jealous).
These dynamics also explain why no-code tools don't seem to ever stick. Building something requires that the person doing the building be interested in building, but people who are interested in building will have already learned to build in some form or fashion, or at least can easily see the shortcomings with tools that ultimately take away their agency to build and/or their participation in the process (which, for many -- including myself -- is kind of the whole point: I love the process!)
> I believe that agents are a multiplier on existing velocity, not an equalizer.
Development tooling improvements usually are a temporary advantage end up being table stakes after a bit of time. I'm more worried that as agentic tooling gets better it obsoletes a lot of SaaS tools where SaaS vendors count on users driving conventional point and click apps (web, mobile and otherwise). I'm encouraging the companies I'm involved with to look to moving to more communication driven microexperience UIs - email, slack, sms, etc instead of more conventional UI.
What I'm seeing Ad infinitum on HN in every thread on agentic development: yeah but it really doesn't work perfectly today.
None of these people can apparently see beyond the tip of their nose. It doesn't matter if it takes a year, or three years, or five years, or ten years. Nothing can stop what's about to happen. If it takes ten years, so what, it's all going to get smashed and turned upside down. These agents will get a lot better over just the next three years. Ten years? Ha.
It's the personal interest bias that's tilting the time fog, it's desperation / wilful blindness. Millions of highly paid people with their livelihoods being disrupted rapidly, in full denial about what the world looks like just a few years out, so they shift the time thought markers to months or a year - which reveals just how fast this is all moving.
You aren't wrong, but you’re underestimating the inertia of $10M+/year B2B distributors. There are thousands of these in traditional sectors (pipe manufacturing, HVAC, etc.) that rely on hyper-localized logistics and century-old workflows.
Buyer pressure will eventually force process updates, but it is a slow burn. The bottleneck is rarely the tech or the partner, it's the internal culture. The software moves fast, but the people deeply integrated into physical infrastructure move 10x slower than you'd expect.
Internal culture changes on budget cycles, and right now, most companies are being pushed by investors to adopt AI. Have your sales team ask about AI budgeting vs. SaaS budgeting. I think you'll find that AI budget is available and conventional SaaS/IT budget isn't. Most managers are looking for a way to "adopt ai" so I think we're in a unique time.
> people deeply integrated into physical infrastructure move 10x slower than you'd expect.
My experience is yes, to move everyone. To do a pilot and prove the value? That's doable quickly, and if the pilot succeeds, the rest is fast.
I don't think you can guarantee it will get better. I'm sure it will improve from here but by how much? Have the exponential gains topped out? Maybe it's a slow slog over many years that isn't that disruptive. Has there been any technology that hasn't hit some kind of wall?
> The bottleneck is still knowing what to build, not building. A lot of the value in our product is in decisions users don't even know we made for them. Domain expertise + tight feedback loop with users can't be replicated by an internal developer in an afternoon.
The cost of building is going decreasing every year. The barriers of entry will come down year after year.
So what remains is knowing what you build (= product) as you write and knowing how to get exposure (= marketing). Focus on these two not on building things.
> But my key takeaway would be that if your product is just a SQL wrapper on a billing system, you now have thousands of competitors: engineers at your customers with a spare Friday afternoon with an agent.
I think the issue is that the "two of them explicitly cloned" were trying to clone something that's more than "just a SQL wrapper on a billing system."
That may well be an exception though. I'd imagine most SaaS builders are very much figuring things out as they go rather than starting with deep domain expertise
Agreed. This is why PE buys so many SaaS companies!
My article here isn't really aimed at "good" SaaS companies that put a lot of thought into design, UX and features. I'm thinking of the tens/hundreds of thousands+ of SaaS platforms that have been bought by PE or virtually abandoned, that don't work very well and send a 20% cost renewal through every year.
Not sure why the argument is SaaS or build from the ground up. Agents can deploy open source projects and build new featurees on top of them pretty effectively.
I'm gonna go ahead and guess that if you have open source competitors, within two years your moat is going to become marketing/sales given how easy it'll be to have an agent deploy software and modify it.
Damn, reading this is clear you two know your market well. Congratulations. This is the right way to do it. Domain expertise + tight feedback loop, probably makes customers feel like they are part of the process and that you’re there for them. Are you hiring?
While most here are aligned with your perspective, and for good reasons, let me offer an alternate perspective. Today AI can take the goal and create a workflow for it. Something that orgs pay for in SaaS solutions.
AI does it imperfectly today, but if you have had to bet, would you bet that it gets better or worse? I would bet that it will improve, and as it is often with tech, at exponential rate. Then we would seen any workflow described in plain language and minutes see great software churned out. It might be a questions of when (not if) that happens. And are you prepared for that state of affairs?
I'll add another obvious one: No rule that the SaaS, with its obviously much deeper technical expertise, can itself then leverage these tools to achieve even greater velocity, thereby exacerbating the problem for "internal teams"
Same background as you and I fully agree. Again and again you see market/economic takes from technologists. This is not a technology question (yes, LLMs work), it's an economics question: what do LLMs disrupt?
If your answer is "cost of developing code" (what TFA argues), please explain how previous waves of reducing cost of code (JVM, IDEs, post-Y2K Outsourcing) disrupted the ERP/b2b market. Oh wait, they didn't. The only real disruption in ERP in the last what 30 years, has been Cloud. Which is an economics disruption, not a technological one: cloud added complexity and points of failure and yet it still disrupted a ton of companies, because it enabled new business models (SaaS for one).
So far, the only disruption I can see coming from LLMs is middleware/integration where it could possibly simplify complexity and reduce overall costs, which if anything will help SaaS (reduction of cost of complements, classic Christensen).
> what do LLMs disrupt? If your answer is "cost of developing code" (what TFA argues), please explain how previous waves of reducing cost of code (JVM, IDEs, post-Y2K Outsourcing) disrupted the ERP/b2b market. Oh wait, they didn't. The only real disruption in ERP in the last what 30 years, has been Cloud.
"Cost of developing code" is a trivial and incomplete answer.
Coding LLMs disrupt (or will, in the immediate future)
(1) time to develop code (with cost as a second order effect)
(2) expertise to develop code
None of the analogs you provided are a correct match for these.
A closer match would be Excel.
It improved the speed and lowered the expertise required to do what people had previously been doing.
And most importantly, as a consequence of especially the latter more types of people could leverage computing to do more of their work faster.
The risk to B2B SaaS isn't that a neophyte business analyst is going to recreate you app overnight...
... the risk is that 500+ neophyte business analysts each have a chance of replacing your SaaS app, every day, every year.
Because they only really need to get lucky once, and then the organization shifts support to in-house LLM-augmented development.
The only reason most non-technology businesses didn't do in-house custom development thus far was that ROI on employing a software development team didn't make sense for them. Suddenly that's no longer a blocker.
To the point about cloud, what did it disrupt?
(1) time to deploy code (with cost as a second order effect)
(2) expertise to deploy code
B2B SaaS should be scared, unless they're continuously developing useful features, have a deep moat, and are operating at volumes that allow them to be priced competitively.
Coding agents and custom in-house development are absolutely going to kill the 'X-for-Y' simple SaaS clone business model (anything easily cloneable).
This seems to assume that these non-technical people have the expertise to evaluate LLM/agent generated solutions.
The problem of this tooling is that it cannot deploy code on its own. It needs a human to take the fall when it generates errors that lose people money, break laws, cause harm, etc. Humans are supposed to be reviewing all of the code before it goes out but you’re assumption is that people without the skills to read code let alone deploy and run it are going to do it with agents without a human in the loop.
All those non-technical users have to do is approve that app, manage to deploy and run it themselves somehow, and wait for the security breach to lose their jobs.
I think you're underestimating (1) how bad most B2B is (from a bug and security vulnerability perspective) & (2) how little B2B companies' engineers understand about how their customers are using their products.
The frequency of mind-bogglingly stupid 1+1=3 errors (where 1+1 is a specific well-known problem in a business domain and 3 is the known answer) cuts against your 'professional SaaS can do it better' argument.
And to be clear: I'm talking about 'outsourced dev to lowest-cost resources' B2B SaaS, not 'have a team of shit-hot developers' SaaS.
The former of which, sadly, comprises the bulk of the industry. Especially after PE acquisition of products.
Furthermore, I'm not convinced that coding LLMs + scanning aren't capable of surpassing the average developer in code security. Especially since it's a brute force problem: 'ensure there's no gap by meticulously checking each of 500 things.'
Auto code scanning for security hasn't been a significant area of investment because the benefits are nebulous. If you already must have human developers writing code, then why not have them also review it?
In contrast, scanning being a requirement to enabling fast-path citizen-developer LLM app creation changes the value proposition (and thus incentive to build good, quality products).
It's been mentioned in other threads, but Fire/Supabase-style 'bolt-on security-critical components' is the short term solution I'd expect to evolve. There's no reason from-scratch auth / object storage / RBAC needs to be built most of the time.
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? Weighed against security risks? And so the point that was established.
If suddenly that business user can add substantial amounts of value to the org, I'd be very surprised if that point doesn't shift.
Yeah. I used to manage a team that built a kind of low-code SaaS solution to several big enterprise clients. I sat in on several calls with our sales people and the customer’s IT department.
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.
I'm going to predict there will be a movement into "build it in house with LLMs", these things are going to be expensive, they are going to fail to deliver or be updated and there will be a huge bounce back. The cost of writing software is very small, the cost of running and scaling it is there the money is and these people can't have their own IT teams rebuilding and maintaining all this stuff form scratch.
A lot of them will try though, just means more work for engineers in the future to clean this shit up.
I think there's a good chance. These things happen in cycles. A few decades ago it was common for companies to have in-house software development using something like COBOL or maybe BASIC (and at that time, sofware development was a cost-center job, it paid OK but nothing like what it does today). Then there was a push for COTS (commercial of-the-shelf) software. Then the internet made SaaS possible and that got hot. Developer salaries exploded. Now LLMs have people saying "just do it in house" again. Lessons are forgotten and have to be re-learned.
I'm expecting this to be a bubble, and that bubble to burst; when it does, whatever's the top model at that point can likely still be distilled relatively cheaply like all other models have been.
That, combined with my expectations that consumer RAM prices will return to their trend and decrease in price, means that if the bubble pops in the year 20XX, whatever performance was bleeding edge at the pop, runs on a high-end smartphone in the year 20XX+5.
The technology of LLMs is already applicable to valuable enough problems, therefore it won’t be a bubble.
The world might be using a standard of AI needing to be a world beater to succeed but it’s simply not the case, AI a is software, and it can solve problems other software can’t.
> The technology of LLMs is already applicable to valuable enough problems, therefore it won’t be a bubble.
Dot-com was a bubble despite being applicable to valuable problems. So were railways when the US had a bubble on those.
Bubbles don't just mean tulips.
What we've got right now, I'm saying the money will run out and not all the current players will win any money from all their spending. It's even possible that *none* of the current players win, even when everyone uses it all the time, precisely due to the scenario you replied to:
Runs on a local device, no way to extract profit to repay the cost of training.
Key point. Once people realize that no money can be made from LLMs, they will stop training new ones. Eventually the old ones will become hopelessly out-of-date, and LLMs will fade into history.
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 a hype train, there is also an adoption and disruption train, which is also happening.
I could go on, but I’m comfortable with seeing how well this comment ages.
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 free ones that are being given away. And buy "spend a lot" I mean they are making a loss.
This means that the similarity with the dot com bubble can be expressed with the phrase "losing money on every sale and making up for it in volume".
Hardware efficiency is also still improving; just as I can even run that image model locally on my phone, an LLM equivalent to SOTA today should run on a high-end smartphone in 2030.
Not much room to charge people for what runs on-device.
So, they are in a Red Queen's race, running as hard as they can just to stay where they are. And where they are today, is losing money.
You don't need RAM to run LLMs. Your graphics card does.
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.
Observably, the biggest models we have right now have similar complexity to a rodent's brain, which runs on far less power. Limiting factors for chips in your phone is power, power efficiency is improving rapidly.
It was always relatively easy to copy many SaaS services, especially bootstrapped ones. Unless everybody wants to make and run their service locally, very little changes.
There's been an obvious step change on the coding front from 2 years ago, and it feels obvious to me there's going to be another. The difference now is the people working on systems to clone SaaS at scale are likely starting to put real effort, sustained effort into now that agents are good enough to accomplish subsets of it, can be improved much further with the right techniques and orchestration, and themselves will get better over the next two years along with all the improvements and build up of tooling. Right now feels like one of those "skate to where the puck is going to be" moments in time.
I've found assigning issues to GitHub Copilot on GitHub itself to be a real step-wise change from one off requests to a chat based interface that has no awareness of my codebase. Maybe it's just me, but I'm getting significantly more realworld value out of AI these days. I've been working through doing an implementation of a spec using GitHub Copilot mostly from my phone, and it has been a really instructive exercise in how to squeeze as much out such a narrow interface as possible. I still dip into a full desktop + IDE from time to time, but for like 90% of it I've been doing it in my phone. Slowly but surely working my way from "vibe coded in a weekend" level initial AI slop quality to nice, clean architecture, excellent dev tooling, production grade multitenant SaaS. I've still got a ways to go, but I'm able to make quite a lot of progress just using my phone during my commute, on my lunch breaks, in between meetings, and bathroom breaks etc.
And? How easy will it be to iterate the product and build features and a user experience as it is used in the wild? How easy will it be to find customers willing to pay you money for it?
Doesn’t have to be a commercial solution to change the game. There’s a lot of room between the commercial product and ‘Our end users… current "system" is Excel.’ Especially if the market moves towards making useful APIs at the ERP and vendors endpoints.
And how would the outcome be different after a couple of years than the internally built Excel file with VBScript, Access and VB6 apps built by non developers back in the day?
> The bottleneck is still knowing what to build, not building.
shit, I'm stealing that quote! it's easier to seize an opportunity, (i.e. build a tool that fixes the problem X without causing annoying Y and Z side effects) but finding one is almost as hard as it was since the beginning of the world wide web.
I am the founder of a niche SaaS (https://partsbox.com/ — software for managing electronic parts inventory and production). While I am somewhat worried about AI capabilities, I'm not losing too much sleep over it.
The worry is that customers who do not realize the full depth of the problem will implement their own app using AI. But that happens today, too: people use spreadsheets to manage their electronic parts (please don't) and BOMs (bills of materials). The spreadsheet is my biggest competitor.
I've been designing and building the software for 10 years now and most of the difficulty and complexity is not in the code. Coding is the last part, and the easiest one. The real value is in understanding the world (the processes involved) and modeling it in a way that cuts a good compromise between ease of use and complexity.
Sadly, as I found out, once you spend a lot of time thinking and come up with a model, copycats will clone that (as well as they can, but superficially it will look similar).
> The real value is in understanding the world (the processes involved) and modeling it in a way that cuts a good compromise between ease of use and complexity.
Which I don't think can be replaced by AI in a lot of cases. I think in the software world we are used to things being shared, open and easily knowable, but a great deal of industry and enterprise domain knowledge is locked up inside in companies and will not be in the training data.
That's why it's such a big deal for an enterprise to have on prem tools, to avoid leaking industry processes and "secrets" (the secrets are boring, but still secrets).
A little career advice in there too I guess. At least for now, you're a bit more secure as a developer in industries that aren't themselves software, is my guess.
> Which I don't think can be replaced by AI in a lot of cases
Yes. I try to visit my customers as often as I can, to learn how they work and to see the production processes on site. I consider it to be one of the most valuable things I can do for the future of my business.
Not specific to PartsBox, but we use Inventree (open source similar to PartsBox) and self host it.
Over the past few months we noticed certain pain points in our workflow. Rather than looking for a new tool, we used Claude Code to write some backend services and some frontend modifications. Took 2 days of tinkering. Has easily saved that much time since we implemented it.
While rolling the whole solution with an AI agent is not practical, taking a open source starting point and using AI to overcome specific workflow pain points as well as add features allows me to have a lower cost, specifically tailored solution to our needs.
I would include this in the "spreadsheet" metaphor. I do not know your use case, so please don't take this as addressed to you specifically, but I found that there is a learning/complexity problem: many people do not realize there is much more to inventory and production management than it seems. It might seem easy to AI-code something, only to find out later that things could have been done much better.
This is actually a serious problem for me: my SaaS has a lot of very complex functionality under the hood, but it is not easily visible, and importantly it isn't necessarily appreciated when making a buying decision. Lot control is a good example: most people think it is only needed for coding batches of expiring products. In reality, it's an essential feature that pretty much everyone needs, because it lets you treat some inventory of the same part (e.g. a reel) differently from other inventory of this part (e.g. cut tape) and track those separately.
AI-coding will help people get the features they know they need, but it won't guide them to the features they don't know they could use.
"AI-coding will help people get the features they know they need, but it won't guide them to the features they don't know they could use." Amen to this.
First, I'll second that I've applied agentic LLMs to an open source project to fix bugs and forcibly coerce it to act in ways that the maintainer may or may not approve of. It has been remarkablely effective, so long as I'm willing to apply patches or maintain a fork of the project (trivial, since this particular open-source project is abandoned anyway).
That said, the act of doing this- using LLMs to dominate somebody's legitimately intelligent and unique work- feels not only discourteous, but worse, like it's a short-term solution.
I'm convinced that it's a short-term solution NOT because I don't think that LLMs can continuously maintain these projects, but because open-source itself is going to be clawed back. The raison d'être of open-source is personal pride, hiring, collaboration, enjoyment, trust, etc. These motivations make less sense in an LLM-fueled world.
My prediction is that useful and well maintained open-source projects like we're hijacking will become fewer and far between.
That's great! I'm not accusing you or anything, or myself for that matter, I'm only lamenting that open source will likely decay due to LLMs. Or at the very least, open source will no longer be seen as the height of virtue in our industry.
> Coding is the last part, and the easiest one. The real value is in understanding the world (the processes involved) and modeling it in a way that cuts a good compromise between ease of use and complexity.
Coding and modeling are interleaved. Prototyping is basically thinking through the models you are considering. If you split the two, you'll end up with a bad model, bad software or both.
Coding agents like Claude are just one line of AI making inroads. There are lot of nearly tasks that can be almost, but not quite, implemented effectivly with existing tools like Excel and Word. As they seek a return on their investments, are MS likely to target those nearly cases with AI in their Access, Excel, Word etc product lines?
Clojure is just better than CL in pretty much every respect. Excellent and well designed standard library, great concurrency primitives, core.async, built-in transducers (CL has SERIES which does a kind-of similar thing, but isn't as well designed and integrated) and the dominant immutability all let me write more maintainable code. Also, I can re-use model code on the client side (ClojureScript), so there is lots of code sharing, and I don't have to serialize to a crippled format (JSON), my data can pass from server to client and back intact (with sets, keywords, and other rich data types).
I used to love CL and wrote quite a bit of code in it, but since Clojure came along I can't really see any reason to go back.
I did not try Clojure so I cannot comment on how well implemented the features you quote are, when compared to CL. All I can say is that CL also provides much of the same functionality with its standard, cl-async, lparallel, parenscript, while (im)mutability is a matter of preference (IMO correct decision by CL) rather than dominance. The way I see it, is that CL is superior (opinion) due to reader macros and native compilation, rather than bytecode JVM.
I used CL for many years before I switched to Clojure. And by "used" I mean really used it, not just for applications, but I also dove into CL implementations, for example I added return-from-frame (also known as debug-return) to CMUCL.
So, I kind of know what I'm talking about :-) And I don't miss anything from CL: I honestly can't find a single reason to switch back to CL.
You have a product, which sits between your users and what your users want. That product has an UI for users to operate. Many (most, I imagine) users would prefer to hire an assistant to operate that UI for them, since UI is not the actual value your service provides. Now, s/assistant/AI agent/ and you can see that your product turns into a tool call.
So the simpler problem is that your product now becomes merely a tool call for AI agents. That's what users want. Many SaaS companies won't like that, because it removes their advertising channel and commoditizes their product.
It's the same reason why API access to SaaS is usually restricted or not available for the users except biggest customers. LLMs defeat that by turning the entire human experience into an API, without explicit coding.
> So the simpler problem is that your product now becomes merely a tool call for AI agents. That's what users want.
This is a big assumption, and not one I've seen in product testing. Open-ended human language is not a good interface for highly detailed technical work, at least not with the current state of LLMs.
> It's the same reason why API access to SaaS is usually restricted or not available for the users except biggest customers.
I don't... think this is true? Of the top of my head, aside from cloud providers like AWS/GCP/Azure which obviously provide APIs: Salesforce, Hubspot, Jira all provide APIs either alongside basic plans or as a small upsell. Certainly not just for the biggest customers. You're probably thinking of social media where Twitter/Reddit/FB/etc don't really give API access, but those aren't really B2B SaaS products.
> A good ui will improve on assistant in every way.
True.
"Good" UI seems to be in short supply these days, even from trillion dollar corporations.
But even with that, it is still not "ridiculous" for many to prefer to "hire an assistant to operate that UI for them". A lot of the complexity in UI is the balance between keeping common tasks highly visible without hiding the occasional-use stuff, allowing users to explore and learn more about what can be done without overwhelming them.
If I want a spaceship in Blender and don't care which one you get — right now the spaceship models that any GenAI would give you are "pick your poison" between Diffusion models' weirdness and the 3D equivalent of the pelican-on-a-bike weirdness — the easiest UI is to say (or type) "give me a spaceship", not doing all the steps by hand.
If you have some unformatted time series data and want to use it to forecast the next quarter, you could manually enter it into a spreadsheet, or you could say/type "here's a JPG of some time series data, use it to forecast the next quarter".
Again, just to be clear, I agree with everyone saying current AI is only mediocre in performance, it does make mistakes and shouldn't be relied upon yet. But the error rates are going down, the task horizons they don't suck at are going up. I expect the money to run out before they get good enough to take on all SaaS, but at the same time they're already good enough to be interesting.
I'm seeing the opposite. AI is actually increasing the demand for what would previously be too expensive, bespoke integrations and solutions. Those are now becoming more feasible and doable. There is also the notion that a lot of companies are actually very behind on embracing software or SAAS. Especially in manufacturing it's common to see operations that haven't materially changed anything in decades.
The fallacy here is believing we already had all the software we were going to use and that AI is now eliminating 90% of the work of creating that. The reality is inverted, we only had a fraction of the software that is now becoming possible and we'll be busy using our new AI tools to create absolutely massive amounts of it over the next years. The ambition level got raised quite a bit recently and that is starting to generate work that can only be done with the support of AI (or an absolutely massive old school development budget).
It's going to require different skills and probably involve a lot more domain experts picking up easy to use AI tools to do things themselves that they previously would have needed specialized programmers for. You get to skip that partially. But you still need to know what you are doing before you can ask for sensible things to get done. Especially when things are mission critical, you kind of want to know stuff works properly and that there's no million $ mistakes lurking anywhere.
Our typical customers would need help with all of that. The amount of times I've had to deal with a customer that had vibe coded anything by themselves remains zero. Just not a thing in the industry. Most of them are still juggling spreadsheets and ERP systems.
> Especially in manufacturing it's common to see operations that haven't materially changed anything in decades.
> Especially when things are mission critical, you kind of want to know stuff works properly and that there's no million $ mistakes lurking anywhere.
This is what I'm wondering about; things don't change because the company doesn't like change, and the risks of change are very real. So changes either have to be super incremental, or offer such a compelling advantage that they can't be ignored. And AI just doesn't offer the sort of reproducible, reliable results that manufacturing absolutely depends on.
I don't think that's entirely correct. You can do TDD style development with AI and it leads to better results.
It's just that messing with a company's core manufacturing is something they don't do lightly. They work with multiple shifts of staff that are supposed to work in these environments. People generally don't have a lot of computer skills, so things need to be simple, repeatable, and easy to explain. Any issues with production means cost increases, delays happen, and money is lost.
That being said, these companies are always looking for better ways to do stuff, to eliminate work that is not needed, etc. That's your way in. If there's a demonstrable ROI, most companies get a lot less risk averse.
That used to involve bespoke software integrations. Those are developed at great cost and with some non trivial risk by expensive software agencies. Some of these projects fail and failure is expensive. AI potentially reduces cost and risk here. E.g. a generic SAP integration isn't rocket science to vibe code. We're talking well documented and widely used APIs here. You'd want some oversight and testing here obviously. But it's the type of low level plumbing that traditionally gets outsourced to low wages countries. Using AI here is probably already happening at a large scale.
If you look at past automation efforts, the automation initially made workers more valuable. They could produce more, at lower cost, and there was plenty of demand. Eventually, you hit the realistic limits of demand though, and the number of workers started to drop.
If software gets cheaper, people will buy more of it, to a point.
This 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 a small monthly fee to a SaaS company.
Note that there is zero actual sales/renewal data quoted in the article so this is all the authors vibes based on how he has been able to vibe code a few things for a team of one person to use
> AI-generated code still requires software engineers to build, test, debug, deploy, ensure security, monitor, be on-call, handle incidents, and so on. That's very expensive. It is much cheaper to pay a small monthly fee to a SaaS company.
Yeah it's a fundamental misunderstanding of economies of scale. If you build an in-house app that does X, you incur 100% of the maintenance costs. If you're subscribed to a SaaS product, you're paying for 1/N % of the maintenance costs, where N is the number of customers.
I only see AI-generated code replacing things that never made sense as a SaaS anyway. It's telling the author's only concrete example of a replaced SaaS product is Retool, which is much less about SaaS and much more about a product that's been fundamentally deprecated.
Wake me up when we see swaths of companies AI-coding internal Jira ("just an issue tracker") and Github Enterprise ("just a browser-based wrapper over git") clones.
"Wake me up when we see swaths of companies AI-coding internal Jira".
This shouldnt be the goal. The goal should be to build an AI that can tell you what is done and what needs to be done i.e. replace jira with natural interactions. An AI that can "see" and "understand" your project. An AI that can see it, understand it, build it and modify it. I know this is not happening for the next few decades or so.
> This shouldnt be the goal. The goal should be to build an AI that can tell you what is done and what needs to be done i.e. replace jira with natural interactions. An AI that can "see" and "understand" your project. An AI that can see it, understand it, build it and modify it.
The difference is that an AI-coded internal Jira clone is something that could realistically happen today. Vague notions of AI "understanding" anything are not currently realistic and won't be for an indeterminate amount of time, which could mean next year, 30 years from now, or never. I don't consider that worth discussing.
Analytics like what?! Sentry? See, i'm the first one to waste 15+ hours of my own time claude vibing some barely working analytics in order to save 15 dollars for not paying a proven solution to professionals who really understand that problem domain - but we all agree how dumb this is. But if i really can vibe code that analytics in 5 minutes, that thing was never a proven SaaS business in the first place and my use case with certainty a toy app with zero users..
The value proposition of SaaS is ultimately just that it's not a hack.
Most SaaS products could be replaced by a form + spreadsheet + email workflow, and the reason they aren't is that people don't want to be dealing with a hacky solution. Devs can hack together a nice little webapp instead of a network of spreadsheets, but it's still a hack. Factoring in AI assistance, perhaps SaaS is now competing with "something I hacked together in a week" as opposed to "something I hacked together in a month," but it's a hack either way.
I am absolutely going to pay for analytics and dashboards, because I don't want the operational concerns of my Elasticsearch analytics cluster getting in the way of the alarm that goes off when my primary database catches fire. Ops visibility is too important to be a hack, regardless of how quickly I could implement that hack.
How do you/I know that? I implemented OpenTelemetry in a project of mine recently and was shocked to see the number of AI authored commits in the git repository.
> So, I ask again - how do you know that the service you're paying for is all of those things?
How do you know anything? How do you know the bank won't lose your money? How do you know the bank note you hold is worth what it says? How do you know?
I'd love for SaaS to stay thriving but the flip side is simply the harsh reality that my own second thought these days is immediately "how easily will an agent replace my idea? yea probably quite easily..."
Ideas were never worth much. Implementing a quick prototype was always pretty simple. How easy is it, with modern tooling, to build a collaborative web editor? Just slap together prosemirror and automerge and you're already there. Still, nobody has displaced Google Docs.
The bit about building an internal app for eg marketing or sales is super fun. Getting calls starting at 8am EST because they then (reasonably!) expect it to work less so. Software still has an enormous ktlo tax and until that changes, I'm skeptical about the entire thesis.
Not to mention the author appears to run a 1-2 person company, so ... yeah. AI thought leadership ahoy.
I’m currently working on an in house ERP and inventory system for a specific kind of business. With very few people you can now instead of paying loads of money for some off the shelf solution to your software needs get something completely bespoke to your business. I think AI enables the age of boutique software that works fantastically for businesses, agencies will need to dramatically reduce their price to compete with in house teams.
I’m pretty certain AI quadruples my output at least and facilitates fixing, improving and upgrading poor quality inherited software much better than in the past. Why pay for SaaS when you can build something “good enough” in a week or two? You also get exactly what you want rather than some £300k per year CRM that will double or treble in price and never quite be what you wanted.
> Why pay for SaaS when you can build something “good enough” in a week or two?
About a decade ago we worked with a partner company who was building their own in-house software for everything. They used it as one of their selling points and as a differentiator over competitors.
They could move fast and add little features quickly. It seemed cool at first.
The problems showed up later. Everything was a little bit fragile in subtle ways. New projects always worked well on the happy path, but then they’d change one thing and it would trigger a cascade of little unintended consequences that broke something else. No problem, they’d just have their in-house team work on it and push out a new deploy. That also seemed cool at first, until they accumulated a backlog of hard to diagnose issues. Then we were spending a lot of time trying to write up bug reports to describe the problem in enough detail for them to replicate, along with constant battles over tickets being closed with “works in the dev environment” or “cannot reproduce”.
> You also get exactly what you want rather than some £300k per year CRM
What’s the fully loaded (including taxes and benefits) cost of hiring enough extra developers and ops people to run and maintain the in house software, complete with someone to manage the project and enough people to handle ops coverage with room for rotations and allowing holidays off? It turns out the cost of running in-house software at scale is always a lot higher than 300K, unless the company can tolerate low ops coverage and gaps when people go on vacation.
In my experience, SaaS is also fragile. It's real software, with real bugs. Most complex solutions offer an extensible API/scripting support with tons of switchable/pluggable modules to integrate with your company's infra. This complexity most often means that your particulary combination of features is almost wholly unique, and chances are your SaaS has much less open mindshare/open source support than any free solution.
We often ended up discarding large chunks of these poorly tested features, instead of trying to get them to work, and wrote our own. This got to a point where only the core platform was used, and replacing that seemed to be totally feasible.
SaaS often doesn't solve issues but replaces them - you substitute general engineering knowledge and open-source knowhow with proprietary one, and end up with experts in configuring commercial software - a skill that has very little value on the market where said software is not used, and chains you to a given vendor.
SaaS software, by it's very nature, tends to gets tested tons more than your inhouse software. It also has more devs working on the software. It is almost certainly more stable and can handle more edge cases than anything developed inhouse. It's always a question of scale.
But what you're describing is the narrow but deep vs wide but shallow problem. Most SaaS software is narrow but deep. Their solution is always going to be better than yours. But some SaaS software is wide but shallow, it's meant to fit a wide range of business processes. Its USP is that it does 95% of what you want.
It sounds like you were using a "wide-shallow" SaaS in a "narrow-deep" way, only using a specific part of the functionality. And that's where you hit the problems you saw.
I am speaking from experience. We have a SaaS tool for example to to CI/CD. It's super expensive, has a number of questionable design choices.
It's full of features, half of which either do not work, or do not work as expected, or need some arcane domain knowledge to get them working. These features provide 'user-friendly' abstractions over raw stuff, like authing with various repos, downloading and publishing packages of different formats.
Underlying these tools are probably the same shell scripts and logic that we as devs are already familiar with. So often the exercise when forced to use these things is to get the underlying code to do what we want through this opaque intermediate layer.
Some people have resorted to fragile hacks, while others completely bypassed these proprietary mechanisms, and our build scripts are 'Run build.sh', with the logic being a shell or python script, which does all the requisite stuff.
And just like I mentioned in my prev post, SaaS software in this case might get tested more in general, but due to the sheer complexity it needs to support on the client side, testing every configuration at every client is not feasible.
At least the bugs we make, we can fix.
And while I'm sure some of this narrow-deep kinds of SaaS works well (I've had the pleasure to use Datadog, Tailscale, and some big cloud provider stuff tends to be great as well), that's not all there is that's out there and doesn't cover everything we need.
That's my point, "It's full of features". You said it yourself.
You have bought a shallow but wide SaaS product, one with tons of features that don't get much development or testing individually.
You're then trying to use it like a deep but narrow product and complaining that your complex use case doesn't fit their OK-ish feature.
MS do this in a lot of their products, which is why Slack is much better than Teams, but lots of companies feel Teams is "good enough" and then won't buy Slack.
I'm arguing this is an entirely flawed product category (which might have elements of fraud as well) - things that are easy to get started with, but as your skill level or the requirements complexity increases, you start to see the limitations, and get entangled in the 'ecosystem', so given a sufficiently knowledgeable workforce, you are at a net negative by year 2 or 3 compared to experts having built something bespoke, or going the open-source route.
I'm sure you have encountered the pattern where you write A that calls B that uses C as the underlying platform. You need something in A, and know C can do it, but you have to figure out how you can achieve it through B. For a highly skilled individual(or one armed with AI) , B might have a very different value proposition than one who has to learn stuff from scratch.
Js packages are perfect illustration of these issues - there are tons of browser APIs that are wrapped by easy-to-use 'wrapper' packages, that have unforeseen consequences down the road.
This is true when SaaS is a simple widget for everyone. The problem is that when SaaS becomes a hydra designed to do a million things for a million people, the extra eyeballs aren't helping you, they're creating more error surface.
On top of that, SaaS takes your power away. A bug could be quite small, but if a vendor doesn't bother to fix it, it can still ruin your life for a long time. I've seen small bugs get sandbagged by vendors for months. If you have the source code you can fix problems like these in a day or two, rather than waiting for some nebulous backlog to work down.
My experience with SaaS is that products start out fine, when the people building them are hungry and responsive and the products are slim and well priced. Then they get bloated trying to grow market share, they lose focus and the builders become unresponsive, while increasing prices.
At this point you wish you had just used open source, but now it's even harder to switch because you have to jump through a byzantine data exfiltration process.
> Everything was a little bit fragile in subtle ways.
Maybe write some tests and have great software development practices and most importantly people who care about getting the details right. Honestly there’s no reason for software to be like this is there? I don’t know how much off the shelf ERP software you have used but I wouldn’t exactly describe that as flawless and bug free either!
This is only true if you assume that you are producing the same amount of code as today. Though, AI ultimately will produce more code which will require higher maintenance. Your internal team will need to scale up due to the the amount of code they need to maintain. Your security team will have more work to do as well because they will need to review more code which will require scaling that team as well. Your infrastructure costs will start adding up and if you have any DevOps they will need scaling too.
Soon or later the CTO will be dictating which projects can be vibe coded which ones make sense to buy.
SaaS benefits from network effects - your internal tools don't. So overall SaaS is cheaper.
The reality is that software license costs is a tiny fraction of total business costs. Most of it is salaries. The situation you are describing the kind of dead spiral many companies will get into and that will be their downfall not salvation.
> The reality is that software license costs is a tiny fraction of total business costs
Yes and no. If someone is controlling the SaaS selection, then this is true.
But I've seen startup phase companies with multiple slightly overlapping SaaS subscriptions (Linear + Trello + Asana for example), just because one PM prefers one over the other.
Then people have bought full-ass SaaS costing 50-100€/month for a single task it does.
I'd describe the "Use AI to make bespoke software" as the solution you use to round out the sharp edges in software (and licensing).
The survey SaaS wants extra money to connect to service Y, but their API is free? Fire up Claude and write the connector ourselves. We don't want to build and support a full survey tool, but API glue is fine.
Or someone is doing manual work because vendor A wants their data in format X and vendor B only accepts format Y. Out comes Claude and we create a tool that provides both outputs at the same time. (This was actually written by a copywriter on their spare time, just because they got annoyed with extra busywork. Now it's used by a half-dozen people)
There is no yes and no. This is a fact. Even a small startup of 3-5 people will pay more in terms of salaries than the total license costs they consume. A larger enterprise will will spend 50 to 100 times more on salaries then software license fees.
The reason software licenses are easier to cut by the finance team when things are not going well is because software does not have feelings although we all know that this not making a dent. Ultimately software scales much better than people and if the software is "thinking" it will scale infinitely better.
Building it all in house will only happen for 2 reasons:
1. The problem is so specific that this is the only variable option and the quickest (fear enough).
2. Developers and management do not have real understanding of software costs.
Developers not understanding the real costs should be forgiven because most of them are never in position to make these type of decisions - i.e they are not trained. However a manager / executive not understanding this is sign of lack of experience. You really need to try to build a few medium-sized none essential software systems in-house to get an idea how bad this can get and what a waste of time and money it really is - resources you could have spent elsewhere to effect the bottom the real bottomline.
Also the lines of code that are written do not scale linearly with team sizes. The more code you produce the bigger the problem - even with AI.
Ultimately a company wants to write as few line of code as possible that extract as much value as feasibly possible.
To me AI might have tilted the economic on doing in house a bit but it has been at least a decade or more that I find most enterprise SaaS, in the way they are used 80% of the time, could be recreated with a few developers in house. Instead of 10-20 developers maybe you only need 2-5 with AI, so for most big companies that doesn’t change much. A company that wants to build in house still has to hire a team. And in most non tech industries even if more expensive usually a service is preferred. SaaS was never (only) about costs, developers were already wondering why people would pay for an expensive CRM 10 years ago when it was only basic CRUD.
I work with both enterprise software and in house teams. Each path has its pro and cons. As you put it costly CRM might not be fulfilling its purpose. And the two biggest points in favour of in house are cost and bespoke nature of solution.
Building is only one part. Maintaining and using/running is another.
Onboarding for both technical and functional teams takes longer as the ERP is different from other company.
Feature creep is an issue. After all who can say no to more bespoke features. Maybe roll CRM, Reporting and Analytics into one. Maintenance costs and priorities now become more important.
We have also explored AI agents in this area. People specific tasks are great use cases. Create mock up and wireframes? AI can do well and you still have human in the loop. Enterprise level tasks like say book closing for late company ERP? AI makes lot of mistakes.
I agree about boutique software, but see the development still being external -
To attempt to summarize the debate, there seems to be three prevailing schools of thought:
1. Status Quo + AI. SaaS companies will adopt AI and not lose share. Everyone keeps paying for the same SaaS plus a few bells and whistles. This seems unlikely given AI makes it dramatically cheaper to build and maintain SaaS. Incumbents will save on COGS, but have to cut their pricing (which is a hard sell to investors in the short term).
2. SaaS gets eaten by internal development (per OP). Unlikely in short/medium term (as most commenters highlight). See: complete cloud adoption will take 30+ years (shows that even obviously positive ROI development often does not happen). This view reminds me a bit of the (in)famous DropBox HN comment(1) - the average HN commenter is 100x more minded to hack and maintain their own tool than the market.
benzible (commenter) elsewhere said this well -
"The bottleneck is still knowing what to build, not building. A lot of the value in our product is in decisions users don't even know we made for them. Domain expertise + tight feedback loop with users can't be replicated by an internal developer in an afternoon."
This same logic explains why external boutique beats internal builds --
3. AI helps boutique-software flourish because it changes vendor economics (not buyer economics). Whereas previously an ERP for a specific niche industry (e.g. wealth managers who only work with Canadian / US cross-border clients) would have had to make do with a non-specific ERP, there will now be a custom solution for them. Before AI, the $20MM TAM for this product would have made it a non-starter for VC backed startups. But now, a two person team can build and maintain a product that previously took ten devs. Distribution becomes the bottleneck.
This trend has been ongoing for a while -- Toast, Procore, Veeva -- AI just accelerates it.
If I had to guess, I expect some combination of all three - some incumbents will adapt well, cut pricing, and expand their offering. Some customers will move development in house (e.g. I have already seen several large private equity firms creating their own internal AI tooling teams rather than pay for expensive external vendors). And there will be a major flourishing of boutique tools.
Author here, really good comment and I agree with you.
What _has_ surprised me though is just how many companies are (or are considering) building 'internal' tooling to replace SaaS they are not happy with. These are not the classic HN types whatsoever. I think when non technical people get to play with AI software dev they go 'wow so why can't we do everything like this'.
I think your point 3 is really interesting too.
But yes the point of my article (hopefully) wasn't that SaaS is overnight dead, but some thin/lower "quality" products are potentially in real trouble.
People will still buy and use expertly designed products that are really nice to use. But a lot of b2b SaaS is not that, its a slow clunky mess that wants to make you scream!
I agree - it is surprising how many are looking at doing in house.
I think what they miss (and I say this as someone who spent the early part of his career outside of tech) is an understanding of what goes into maintaining software products - and this ignorance will be short lived. I was honestly shocked how complex it was to build and maintain my first web app. So business types (like I was) who are used to 'maintaining' an excel spreadsheet and powerpoint deck they update every quarter may think of SaaS like a software license they can build once and use forever. They have no appreciation of the depth of challenges that come with maintaining anything in production.
My working model is that of no-code - many non-tech types experimented with bubble etc, but quickly realize that tech products are far deeper than the (heavily curated) surface level experience that the user has. It is not like an excel model where the UI is codebase. I expect vibe-coders will find the same thing.
I have on several occasions built my own versions of tools, only to cave and buy a $99 a year off the shelf version because the maintenance time isn't worth it. Non-tech folks have no idea of the depth of pain of maintaining any system.
They will learn. Will be interesting to see how it plays out.
I like this thoughtful and nuanced response, I think you could be right. Makes me wonder if choosing an extremely boring niche and just making several million dollars could be a good move right now.
Quite honestly, this is exactly what I am currently doing - identified a market with probably $50mm global TAM. Bootstrapping with first design partners currently.
One thing I didn't mention is that there are often a few sleepy legacy SaaS players (often public) in these niche markets who don't have the chops to add AI to their product and may be a good takeout / exit down the line. Won't be for billions, but if you bootstrap, that doesn't really matter.
Maybe someday we'll see job postings for maintaining these in-house SaaS tools. And someday someday, we'll see these in-house SaaS tools being consolidated as its own separate product. Wait what.
providers' ToS explicitly states whether or not any data provided is used for training purposes. the usual that i've seen is that while they retain the right to use the data on free tiers, it's almost never the case for paid tiers
If I were to go out on a limb, those companies spend more on tech companies than you and they have larger legal teams than you. That is a carrot and a stick for AI companies to follow the contract.
I bet companies are circumventing this in a way that allows them to derive almost all the benefit from your data, yet makes it very hard to build a case against them.
For example, in RL, you have a train set, and a test set, which the model never sees, but is used to validate it - why not put proprietary data in the test set?
I'm pretty sure 99% of ML engineers would say this would constitute training on your data, but this is an argument you could drag out in courts forever.
Or alternatively - it's easier to ask for forgiveness than permission.
I've recently had an apocalyptic vision, that one day we'll wake up, an find that AI companies have produced an AI copy of every piece of software in existence - AI Windows, AI Office, AI Photoshop etc.
Given the conduct we've seen to date, I'd trust them to follow the letter - but not the spirit - of IP law.
There may very well be clever techniques that don't require directly training on the users' data. Perhaps generating a parallel paraphrased corpus as they serve user queries - one which they CAN train on legally.
The amount of value unlocked by stealing practically ~everyone's lunch makes me not want to put that past anyone who's capable of implementing such a technology.
I wonder how much wiggle there is for collect now (to provide service, context history, etc), then later anonymise (some how, to some level) and then train on it?
Also I wonder if the ToS covers "queries & interaction" vs "uploaded data" - I could imagine some tricky language in there that says we wont use your word document, but we may at some time use the queries you put against it, not as raw corpus but as a second layer examining what tools/workflows to expand/exploit.
“We don’t train on your data” doesn’t exclude metadata, training on derived datasets via some anonymisation process, etc.
There’s a range of ways to lie by omission, here, and the major players have established a reputation for being willing to take an expansive view of their legal rights.
Ironically (for you), copilot is the one provider that is doing a good job of provably NOT training on user data. The rest are not up to speed on that compliance angle, so many companies ban them (of course, people still use them).
There are claims all through this thread that “AI companies” are probably doing bad things with enterprise customer data but nobody has provided a single source for the claim.
This has been a theme on HN. There was a thread a few weeks back where someone confidently claimed up and down the thread that Gemini’s terms of service allowed them to train on your company’s customer data, even though 30 seconds of searching leads to the exact docs that say otherwise. There is a lot of hearsay being spread as fact, but nobody actually linking to ToS or citing sections they’re talking about.
Sources aren't hard to find[1]. But getting software developers to look outside their idiot-savant caves and not dismiss the entire legal system as "unrealistic", is much harder to accomplish.
Even if they're were doing this (I highly doubt it) so much would be lost to distillation I'm not convinced there would be much that actually got in, apart from perhaps internal codenames or whatever which will be obvious.
Well, perhaps this is naive of me from the perspective of not fully understanding the training process. However, at some point, with all available training data having been exhausted, gains with synthetic data exhausted, and a large pool of publicly available AI generated code, at what point is it 'smart' to scrape codebases from what you identify as high quality code based, clean it up to remove identifiers, and use that for training a smaller model?
It could be a wide range of things depending on your field: highly particular materials, knowledge or processes that give your products or services a particular edge, and which a company has often incurred high R&D costs to discover.
Many businesses simply couldn't afford to operate without such an edge.
Using an LLM on data does not ingest that data into the training corpus. LLMs don’t “learn” from the information they operate on, contrary to what a lot of people assume.
None of the mainstream paid services ingest operating data into their training sets. You will find a lot of conspiracy theories claiming that companies are saying one thing but secretly stealing your data, of course.
Companies have already shifting from not using customer data to giving them an option to opt out ex:
“How can I control whether my data is used for model training?
If you are logged into Copilot with a Microsoft Account or other third-party authentication, you can control whether your conversations are used for training the generative AI models used in Copilot. Opting out will exclude your past, present, and future conversations from being used for training these AI models, unless you choose to opt back in. If you opt out, that change will be reflected throughout our systems within 30 days.” https://support.microsoft.com/en-us/topic/privacy-faq-for-mi...
At this point suggesting it has never and will her happen is wildly optimistic.
> LLMs don’t “learn” from the information they operate on, contrary to what a lot of people assume.
Nothing is really preventing this though. AI companies have already proven they will ignore copyright and any other legal nuisance so they can train models.
They're already using synthetic data generated by LLMs to further train LLMs. Of course they will not hesitate to feed "anonymized" data generated by user interactions. Who's going to stop them? Or even prove that it's happening. These companies have already been allowed to violate copyright and privacy on a historic global scale.
I have no doubt that Microsoft has already classified the nature of my work and quality of my code. Of course it's probably "anonymized". But there's no doubt in my mind that they are watching everything you give them access to, make no mistake.
That’s a training step. It requires explicitly collecting the data and using it in the training process.
Merely using an LLM for inference does not train it on the prompts and data, as many incorrectly assume. There is a surprising lack of understanding of this separation even on technical forums like HN.
They are not directly ingesting the data into their trainning sets but they are in most cases collecting it and will be using it to train future models.
If they weren't, then why would enterprise level subscriptions include specific terms stating that they don't train on user provided data? There's no reason to believe that they don't, and if they don't now then there's no reason to believe that they won't later whenever it suits them.
This is so naive. The ToS permits paraphrasing of user conversations, by not excluding it, and then training on THAT. You’d never be able to definitively connected paraphrased data to yours, especially if they only train on paraphrased data that covers frequent, as opposed to rare, topics.
“Hey DoctorPangloss, how can we train on user data without training on user data?”
“You can use an LLM to paraphrase the incoming requests and save that. Never save the verbatim request. If they ask for all the request data we have, we tell them the truth, we don’t have it. If they ask for paraphrased data, we’d have no way of correlating it to their requests.”
“And what would you say, is this a 3 or a 5 or…”
Everything obvious happens. Look closely at the PII management agreements. Btw OpenAI won’t even sign them because they’re not sure if paraphrasing “counts.” Google will.
"We will train new models using data from Free, Pro, and Max accounts when this setting is on (including when you use Claude Code from these accounts)."
> You will find a lot of conspiracy theories claiming that companies are saying one thing but secretly stealing your data, of course.
It's not really a conspiracy when we have multiple examples of high profile companies doing exactly this. And it keeps happening. Granted I'm unaware of cases of this occuring currently with professional AI services but it's basic security 101 that you should never let anything even have the remote opportunity to ingest data unless you don't care about the data.
I am aware, I've trained my own models. You're being obtuse.
The big companies - take Midjourney, or OpenAI, for example - take the feedback that is generated by users, and then apply it as part of the RLHF pass on the next model release, which happens every few months. That's why they have the terms in their TOS that allow them to do that.
>Ah yes, blindly trusting the corpo fascists that stole the entire creative output of humanity to stop now.
Stealing implies the thing is gone, no longer accessible to the owner.
People aren't protected from copying in the same way. There are lots of valid exclusions, and building new non competing tools is a very common exclusion.
The big issue with the OpenAI case, is that they didn't pay for the books. Scanning them and using them for training is very much likely to be protected. Similar case with the old Nintendo bootloader.
The "Corpo Fascists" are buoyed by your support for the IP laws that have thus far supported them. If anything, to be less "Corpo Fascist" we would want more people to have more access to more data. Mankind collectively owns the creative output of Humanity, and should be able to use it to make derivative works.
No calling every possible loss due to another persons actions "Stealing" is simplistic. We have terms for all these things, like "intellectual property infringement".
Trying to group (Thing I dont like) with (Thing everyone doesnt like) is an old semantic trick that needs to be abolished. Taxonomy is good, if your arguments are good, you dont need emotively charged imprecise language.
> Stealing implies the thing is gone, no longer accessible to the owner.
You know a position is indefensible when you equivocation fallacy this hard.
> The "Corpo Fascists" are buoyed by your support for the IP laws
You know a position is indefensible when you strawman this hard.
> If anything, to be less "Corpo Fascist" we would want more people to have more access to more data. Mankind collectively owns the creative output of Humanity, and should be able to use it to make derivative works.
Sounds about right to me, but why you would state that when defending slop slingers is enough to give me whiplash.
> Scanning them and using them for training is very much likely to be protected.
Where can I find these totally legal, free, and open datasets all of these slop slingers are trained on?
>You know a position is indefensible when you equivocation fallacy this hard.
No its quite defensible. And if that was equivocation, you can simply outline that you didn't mean to invoke the specific definition of stealing, but were just using it for its emotive value.
>You know a position is indefensible when you strawman this hard.
Its accurate. No one wants thes LLM guys stopped more than other big fascistic corporations, plenty of oppositional noise out there for you to educate yourself with.
>Sounds about right to me, but why you would state that when defending slop slingers is enough to give me whiplash.
Cool, so if you agree all data should usable to create derivative works then I don't see what your complaint is.
>Where can I find these totally legal, free, and open datasets all of these slop slingers are trained on?
You invoked "strawman" and then hit me with this combo strawman/non sequitur? Cool move <1 day old account, really adds to your 0 credibility.
I literally pointed out they should have to pay the same access fee as anyone else for the data, but once obtained, should be able to use it any way. Reading the comment explains the comment.
Unless, charitably, you are suggesting that if a company is legally able to purchase content, and use it as training data, that somehow compels them to release that data for free themselves?
This resonates strongly, especially the shift in the build vs buy calculus happening almost invisibly. What feels under-discussed is that agents are not just reducing the cost of building software — they are collapsing the coordination and abstraction costs that SaaS historically justified.
One emerging pattern I’m seeing is teams moving toward agent-orchestrated internal tooling rather than traditional “one-off” internal apps. Instead of rebuilding entire SaaS products, they compose narrow, task-specific agents that sit directly on top of their own data and workflows. This avoids both feature bloat and long-term roadmap dependency while keeping maintenance tractable. Platforms like Coldi AI, for instance, point toward this middle ground: not “replace all SaaS,” but replace the parts that are really just opinionated CRUD, dashboards, or glue code with agents that can evolve alongside the organization. That feels like the real threat surface for SaaS — not total displacement, but systematic erosion of NRR as customers internalize more of the value chain.
It was common in the early 2000s for big companies to have large internal IT teams to build "line of business" apps. Then SaaS came along and delivered LoB apps for a fraction of the price and with a monthly subscription.
Looks like we're headed back to the internal IT days of building customized LoB apps.
Or perhaps there will arise a new kind of external service provider that delivers customized SaaS services to those same users, using AI. There's no reason the work has to go back to the internal IT people who were fired long ago.
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 more than 2 hours to put those together. We didn't renew our TeamRetro
> It took me no more than 2 hours to put those together. We didn't renew our TeamRetro
Okay, so two hours with an LLM vs maybe 2.5 days without an LLM in the best-case scenario (i.e. LLMs gave you a 10x boost. I would expect it to be less than that though, like maybe a 2x boost) - it sounds like it was always pretty cheap to replace the SaaS, but the business didn't do it.
TBH, the arguments were never "It would take too long to do ourselves", it was always "but then we'd have to maintain it ourselves".
The place I am consulting at now just moved (i.e. a month ago) from their in-house built ticketing system ($0/m as it had not needed maintenance for over a year) to Jira (~$2k/m).
In this specific case, it was literally 0 hours to avoid paying the SaaS, and they still moved, because they wanted some modern features (billing for time on support calls, etc) and figured that rather than update their in-house system to add support hours costing (a day, at most) they may as well move to a system that already had it.
(Joke's on them though - the Jira solution for support hours costing is not near the level of granularity they need, even with multiple paid plugins).
Once again, companies aren't using SaaS because it's cheaper or quicker; they could already quickly replace their SaaS with in-house.
>.e. LLMs gave you a 10x boost. I would expect it to be less than that though, like maybe a 2x boost
I'm not a frontend guy, I'm an operations guy that sometimes does some backends. So it's likely a solid 2.5 days for me to build the pair of these, probably more I haven't touched Javascript in over a decade.
> I'm not a frontend guy, I'm an operations guy that sometimes does some backends. So it's likely a solid 2.5 days for me to build the pair of these, probably more I haven't touched Javascript in over a decade.
Right, understood and agreed, but this was not about you and your specific skills or lack thereof; your anecdote was in support of an argument that companies would stop their SaaS because LLMs enable them to build in house.
That was your argument, right?
So in the absence of LLMs, if the company wanted to stop paying for the SaaS, would they have chosen you to do the replacement, or someone who had recent experience in the tech?
Look, we are interested in comparing the time taken to replace the SaaS with an LLM, and the time taken to replace the SaaS without LLM assistance.
That's really the only two scenarios under discussion, so lets explore those exhaustively:
1. Without LLMs: In the worst case scenario, the company had to pay for 2.5 days of employee time with the best case being 1 day of employee time. Lets go with something in-between like 1.5 days of dev time.
2. With LLMs: The company pays for 0.5 days of employee time (includes the overhead of token cost/subscription).
The difference between the only two scenarios that we have is literally a single day of employee costs!
I am skeptical that the company failed to leave the SaaS earlier because they didn't want to eat the cost of a 1.5 paid days for an employee, but a difference of a single day of cost was enough to tip the scales.
I wasn't intending to make an argument, I was specifically replying to:
>does not mention a single specific SaaS subscription he’s cancelled
I was imagining it could start a thread of examples where it's happened.
>would they have chosen you to do the replacement, or someone who had recent experience in the tech?
I get what you're saying, but those aren't the only two options; they very likely would have chosen neither of those options. The resources we had available was an ops guy who is pretty handy with the LLMs.
I get the point you're making, I really do. My counterpoint is that there are some SaaSes out there that people can build replacements for by using the LLMs at no incremental cost.
>I am skeptical that the company failed to leave the SaaS earlier because they didn't want to eat the cost of a 1.5 paid days for an employee
Sure, I'd be skeptical about it when put that way as well. That's not how it played out however: We were having a retro and the guy running it said that our subscription was expiring the end of the month and wanted discussion about whether we wanted to purchase it for another year. 2 weeks later, before our next retro, I threw a prompt at Claude Code and asked a couple people to try out the result, incorporated their feedback and we ran the retro on it. We aren't planning to renew.
This was not something "the company" had a big discussion about; my boss made an offhand comment about it, and I did it as a side project while I was doing something else.
It is fine. We already had a retro process we were using, and teamretro didn't really enable us to change or improve our process so much as just continue doing our existing process. It is a solid product, but honestly we just used a google sheet prior to it and that worked fine as well.
I didn't look at the product. But $240/year is nothing for an org. Plus not only just the time to make it. What about the time fixing bugs? hosting costs? backups? I'm sure there will be products that can be replaced (possibly this one), but I'm not convinced the death of SaaS is here yet.
Good point! For me the only change that happened so far (because the agentic product was better) was switching from JetBrains to Cursor. I'm sure this will happen with more products I use in the future
I often give the follow analogy which I think is a good proxy to what is going on.
Spreadsheets! They are everywhere. In fact, they are so abundant these days that that many are spawned for a quick job and immediately discarded. In fact, the cost of having these spreadsheets is practically zero so in many cases one may find themselves having hundreds if not thousands of them sitting around with no indication to ever being deleted. Spreadsheets are also personal and annoying especially when forced upon you (since you did not make it yourself). Spreadsheets are also programming for non-programmers.
These new vibe-coded tools are essentially the new spreadsheets. They are useful,... for 5 minutes. They are also easily forgettable. They are also personal (for the person who made them) and hated (by everyone else). I have no doubt in my mind that organisation will start using more and more of these new types of software to automate repetitive tasks, improve existing processes and so on but ultimately, apart from perhaps just a few, none will replace existing, purpose-built systems.
Ultimately you can make your own pretty dashboard that nobody else will see or use because when the cost of production is so low your users will want to create their own version because they would think they could do better.
After all, how hard is to prompt harder then the previous person?
Also, do you really think that SaaS companies are not deploying AI themselves? It is practically an arms race: the non-expert plus some AI vs 10 specialist developers plus their AIs doing this all day long.
There are SO MANY Excel sheets someone automated a decade+ ago still used in essential parts of the government and big corporations.
Nobody knows how they work, very few have the skills or time to edit them or check them. People just use them for the convenience.
The magic sauce of Excel is that it's free an scriptable (programmable even). If you want a SaaS, you need to involve IT, Legal, your supervisors and it's a whole-ass thing of contracts and shit.
Excel? It's just there.
There are so many stories and anecdotes of people being in stupid data entry jobs, getting bored and finding out their whole job can be automated with a single smartly done Excel sheet. Then they press F9 once per day and do something else for the rest of the time =)
And just because, my main gripe about Excel: there are no unit tests or validators for it. There's no easy way to programmatically confirm that Cell C5 has the same formula as C875
If (when?) people start AI-coding the things they used to use Excel for, we might get some actual tests and validation to confirm what the code is supposed to actually happens.
I mostly agree. What it does do is raise the bar for a viable SaaS, and seeing some examples elsewhere in this thread, that’s a good thing.
I’d also add a number of the vibe tools tech adjacent people on my team have made are used and liked by the team. Even engineering likes them because it frees up their time to work on customer facing things.
AI coding IS SaaS. Claude Code is a subscription service I pay to create the exact, niche, I need you to build a form that submits a blog post to Wordpress here’s my api key, here’s the word doc format it comes in, I’ll paste it in the chat and you make a paste from word button so I don’t have to manually enter the form and it works first try. That is the definition of software as a service. And it’s mine and it’s exactly what I need. Tomorrow I’ll need something else…
You can already hire Indians to make your own HR system. People still choose SAAS, because the system already works.
You do not want to have to plan out a system with 800 unique requirements yourself. It takes a ridiculous amount of work, and you are then stuck maintaining it.
It’s never been about the difficulty of programming, it’s been about the pain of designing and maintaining.
This is why I started working on an open source, generic protobuf sqlite ORM + CRUD server (with search/filtering) + type/service registry + grpc mesh, recently: https://github.com/accretional/collector Note: collector's docs are mostly from LLMs, partially because it's more of a framework for tool-calling LLMs than humans
Then this project lets you generate static sites from svelte components (matches protobuf structures) and markdown (documentation) and global template variables: https://github.com/accretional/statue
A lot of the SaaS ecosystem actually has rather simple domain logic and oftentimes doesn't even model data very well, or at least not in a way that matches their clients/users mental models or application logic. A lot of the value is in integrations, or the data/scaling, or the marketing and developer experience, or some kind of expertise in actually properly providing a simple interface to a complex solution.
So why not just create a compact universal representation of that? Because it's not so big a leap to go beyond eating SaaS to eating integrations, migration costs/bad moats, and the marketing/documentation/wrapper.
I’m glad the author of the article mentions a lot of the limitations of this idea, but taking the final sentence:
> But my key takeaway would be that if your product is just a SQL wrapper on a billing system, you now have thousands of competitors: engineers at your customers with a spare Friday afternoon with an agent.
I think it’s pertinent to point out that a lot of SaaS products are aimed at businesses and individuals who don’t have engineers at all.
AI agents aren’t going to disrupt the SaaS market for software intended for businesses like small business retail where the owners and staff have minimal technical knowledge and zero extra time.
I also think that some SaaS products are so cheap that about an hour of effort is too much. Is it worth a month of effort to vibecode a Dropbox alternative? Even some pretty complicated software that is untouchable by agents and engineers’ side projects like the Microsoft 365 suite and Jira are priced at under $20/month/user.
On the other hand, some entrenched solutions that aren’t all that complicated could be finding themselves with new, smaller competitors.
The problem is that we are still talking only about software. If that is the only thing agents can do then they are just better IDE’s for programmers. This would be an enabler for building stuff faster. Think about it, there is already a huge market for SAAS, but most of the companies have contracts in place, so what we’ll have is just more competition which will drive prices down. Companies will not start changing internal tools, refactoring is a bad investment in general, if you choose that over some new features or products it signals larger issues, so nobody will replace existing cheap stuff that is working.
Going back to the beginning, I think we just lack good tools for other cases where agents could be used. Copilot is not great, chatgpt alone lacks some features to use it for business as is. I think what will happen is that we will see a lot more new tooling pop up that relies on agents in niche markets which will just amplify the power users. It will be another category of SAAS the companies will adopt.
Teams I've worked in choose SaaS offerings based on how little expertise we have in the given domain, and the price (which includes actual monies going to the SaaS, but also the expected time of integrating with them and an expectation cost of migrating away from them).
Experienced developers have the humility to understand that there are always roadbumps and risks in building a system in a domain we do not understand, and therefore paying another company with expertise can often be worth it. Obviously some SaaS companies are better than others, which is why there is an evaluation process.
It does not surprise me (unfortunately) that proponents of using AI agents for everything minimize the value of actual lived experience in working in a given domain.
Ah, yes. If the thing that is false is true, all kinds of interesting things happen! For example, if I became the queen of France, I could make people do silly dances! That is an interesting hypothesis that could play out in my imaginary world!
SaaS maintenance isn't about upgrading packages, it's about accountability and a point of contact when something breaks along with SLAs and contractual obligations. It isn't because building a kanban board app is hard. Someone else deals with provisioning, alerts, compliance, etc. and they are a real human who cannot hallucinate that the issue has been fixed when it hasn't. Depending on the contract and how it is breached, you can potentially take them to court and sue them to recover money lost as a result of their malpractice. None of that applies to a neural network that misreads the alert, does something completely wrong, then concludes the issue is fixed the way the latest models constantly do when I use them.
There are already plenty of SaaS that offer open source version as a way to push to the cloud and charge for hosting, maintenance, support and some extra features. In that way, a working code have already been commoditized and those companies didn't disappear.
I was looking for this comment (I was going to say the same) - I'm mostly on the backend services and infra side, and I have the option to host a lot of open-source tooling as opposed to paying for a service. I have to weigh up my options when deciding what to do, but a lot comes down to how much time I have and how much I'm willing to waste in time & hosting costs to keep the thing running. Also, do I need support, and ensure uptime and SLAs etc. Or what if I'm on holidays. I'm sure there are other things I'm not thinking of right now.
This is what I don't get with a lot of the AI based saas projects - what is your value add? If you can build it with AI then (in theory) your customer can also build it with ai, so why do they need you? In the SaaS world you don't because the cost of development and maintenance just doesn't scale well, but if you're 99% a wrapper around an AI, your 'business' feels easily replicable to me.
But that does leave a weird gap where SaaSes that took a lot of time to make but can now be handled by an Ai won't survive either. If the business stays hand-coded it costs too much to be viable, if it moves to Ai it looses any advantage over doing it youself.
I dont think any opinion right now is going to be definitive. This is like mixing paint, the edges are still white, while the centre is colored.
What Iam seeing is that customers are delaying purchases of large expensive software. Prime example; SAP. ECC migrations to SaaS model RISE/GROW-PublicCloud are stalling, same with onprem S4 to RISE. I see a whole bunch of my customers instead go with retaining the core but modernize surround apps with intelligent custom apps without feature bloat. For now, SAP/oracle/whatever remains the system of record, the edges are going away. I guess the same is likely happening in other spaces.
This change is coming. Definitely. The current moats around SaaS will fall and the alternate ecosystem might not have moats at all.
There is a significant risk of uncertainty in all of this, the most damaging aspect really. If AI improves, and it is threatening to, then growth in SaaS may decline to a point where investing in it needs to be reconsidered.
The problem is, nobody knows how much and how fast AI will improve or how much it will cost if it does.
That uncertainty alone is very problematic and I think is being underestimated in terms of its impact on everything it can potentially touch.
For now though, I've seen a wall form in benchmarks like swe-rebench and swebench pro. Greenfield is expanding, but maintenance is still a problem.
I think AI needs to get much better at maintenance before serious companies can choose build over buy for anything but the most trivial apps.
Indeed, wisdom is being able to see the lifecycle like a time knife and making favorable decisions based on past experiences (ie getting the most value from what may need to be built and operated for its lifetime). Writing code is easy, managing a living codebase with ever changing business requirements and stakeholders is hard.
Many SaaS are not products, but 1-2 features. And an LLM can generate a single-purpose script to replace that one feature you're using. Opus 4.5 does that very well.
As for Retool, I see the several waves of low/no-code products, the current one being LLMs, as repeated attempts to get non technical idea-guys to build their ideas. Where they all fail, and this is fundamental to the problem they're trying to solve, is that idea-guys' ideas crack when meeting reality. And neither Retool nor LLM fix that.
> is that idea-guys' ideas crack when meeting reality.
This is definitely the hardest nut to crack. I worked on a product a while ago that needed to track maintenance periods on equipment quite carefully and then use that to filter data to provide insights about how it was performing. The 'user story' was light on detail. As we got into it, there were tons of questions about how to deal with source data that was often inconsistent or patchy, time zones became an issue because much of the data we received wasn't matched correctly to their local time (customers fault not ours) and our ideas guy just couldn't deal with it - "make it work" - when ultimately they were business questions that needed answering, not just pure software tasks. AI is so sycophantic it'd just go off and write something.
I think that there have always been a ton of SaaS things that are basically circular - startup company paying silly amounts per month to another startup company. I think the market for these things will drop as part of AI, but I think that was always going to be the case with higher interest rates as investors questioned the revenue/spend balance.
When it comes to SaaS that's industry specific, I just don't see it'll be that much of a change any time soon. I've worked heavily in the engineering industry and the security requirements that get put upon anything are nuts. It is difficult to enter this market, ISO compliance is important, even being in the cloud is a barrier for some customers, and often the type that you have no choice but to contract with if you want to make a profit because of their outsized importance in the market.
When I speak to customers, they actually quite often have tried to build something themselves. Usually it's been an intern or grad trying to make their life easier. Often it's spreadsheet based, but some go as far as knocking up little Python web apps. In one company I interned in they had a shadow PHP app. They often have a small 'data science' team that has struggled to get access to the data they need. While they can often get something that does the barebones of the tasks, and can do it well, where they fall down is that they're vulnerable to security issues and can't navigate their internal company politics to get permission to host things in the cloud and make their life easy, plus they don't have the experience to know what's good practice. I don't see AI changing things that much in that.
I'm building a vibe-coding platform that helps with building internal apps and dashboards, and this is exactly what I have seen with some of our clients.
A couple of them mentioned that they plan to cancel subscriptions totaling more than $100k/year for the apps they will replace with that SaaS. According to them, they have many subscriptions they keep only because of one feature. Another issue is that their workflows become a real mess when they need to copy and paste data into multiple tabs. Custom-built internal tools seem like an obvious solution. Those who migrate to custom-built tools, however, will face the challenge of orchestrating their lifecycle and creating a consistent deployment workflow, but this is one of the challenges we are trying to solve at UI Bakery.
In my understanding, SaaS products that provide customers access to proprietary data are in a much better position than other SaaS platforms. HubSpot’s acquisition of Clearbit a couple of years ago now makes even more sense because it will help them retain some of their clients.
> I'm starting to see is people really questioning renewal quotes from larger "enterprise" SaaS companies
This practice predates even SaaS.
I read this article expecting to see a specific SaaS that was at risk, and the most I saw was "dashboards." (Which: dashboards frequently aggregate data, while the ongoing work of collection/maintenance/etc. is done by more complex applications.)
The thesis seems to be that companies can use coding agents to build one-off internal versions of SaaS apps like e.g. Workday or Salesforce or Slack or Jira or MixPanel or HubSpot. Which, if one could make such a thing for free and maintain it for free, why not?
Fortunately/unfortunately depending on where you sit, magical thinking isn't going to get Claude Code to build Workday, regardless of the quality of your AGENTS.md. Sometimes I wonder if the people who write these takes have spent any real time using Claude Code. It's good, but please be realistic.
Author here. What I'm seeing in particular is CRM/ERP solutions at risk. I know of two people in my peer group who are actively trying to replace a 'niche' ERP/CRM (not salesforce) with a agent built alternative. These are both >$100k/yr contracts.
They've outgrown the current (industry specific) products, arguably a long time ago. The discussions started like this:
1) Started building custom dashboards on top of data exports of said product with various AI tooling.
2) This was extremely successful, as a non developer "business" person could specify, build and iterate on the exact analytics. Painful to work with a developer on this as you need to quickly iterate once you see the data and realise where your thinking was wrong. Non developers also really struggle to explain this in a way that makes sense from a developers PoV.
3) ERP system at play wanted a renewal price which was a big increase, and API deprecation. This would require a lot of existing (pre "AI") integrations to be rewrote/redone.
4) Now building an internal replacement. They would not have even considered this before AI Agents.
FWIW this tool is not super complex, but it is extremely expensive (for what it does). It already has a load of limitations which are being worked round with various levels of horrible hacks.
There are a _lot_ of these kind of SaaS products about, for each industry. You never really hear about them.
Btw I use claude code nearly every day for many hours. Opus 4.5 has been a huge leap forward, I am blown away with how it can do 10-30 minute sessions without going wrong (Sonnet definitely needed constant babysitting). And the models/agent harnesses are only getting better. Claude Code isn't even a year old yet!
Thanks for responding. This sounds like the type of thing companies have done in cycles over the years. Some % gets dissatisfied with their vendor, so they bring in-house. That predictably sucks (distraction, can't keep up with third-party tools, etc.) and so the companies go back into the marketplace. I've even been the one building some of those internal tools. :-)
Overall, that story sounds more like the niche is not well-served by software and perhaps there is an opening for a competitor to serve them well. Or perhaps the attrition will make the incumbents improve.
This article seems to suggest that businesses are going to swap domain-specific SaaS tools, written and tested by people knowledgable in the domain with specific SLAs for vibe coding everything. But your AI subscription is still a SaaS?
All you've done is swapped a SaaS built for your problem domain with another, more expensive SaaS that has no support at all for your actual problem. Why would anyone want that? People buy SaaS products because they don't want to solve the problem, they just want it fixed. AI changes nothing about that.
Some of the risk outlined here are real for SaaS businesses that rely on user licenses. Automation, APIs and AI are going to reduce the no of people needed which means businesses buying less licenses overall. That's why smarter SaaS solutions are moving towards pay per usage.
This is inevitable, you can't rely on user licenses as a growth metric
Vibe Coding is so easy nowadays, I coded an app almost by mistake. I put a short cryptic prompt into Kim2 to see how it would respond and it immediately (and very much to my surprise), coded an entire website with the functionality I was thinking about.
It wasn't even a coherent grammatically correct sentence that I entered and it busily went to work building the site I had in mind.
It's not hard to imagine that in the next 2-3 years, anyone will be able to build personalized apps on request.
Not for my company. In my research AI is just completely incapable of doing what we do in a cost effective way and our customers don’t have the technical know-how to vibe an alternative.
Our customers ask for about AI features and it’s a constant struggle to explain to them that they just aren’t there yet.
"It was always possible to clone software, but doing so was costly and time consuming, and the clone would need to be much cheaper, making any such venture financially non-viable.
With AI, that equation is now changing. I anticipate that within 5 years autonomous coding agents will be able to rapidly and cheaply clone almost any existing software, while also providing hosting, operations, and support, all for a small fraction of the cost.
This will inevitably destroy many existing businesses. In order to survive, businesses will require strong network effects (e.g. marketplaces) or extremely deep data/compute moats. There will also be many new opportunities created by the very low cost of software. What could you build if it were possible to create software 1000x faster and cheaper?"
SaaS was always just a transitional phase between desktop software and... this. We built entire businesses around being the interface layer, but if AI can interact with APIs directly, that whole layer gets compressed.
The optimistic angle nobody's exploring: maybe 'eating SaaS' means we finally escape the subscription hellscape where every basic function costs $29/month. If an AI agent can stitch together free/cheap APIs instead of forcing you into Notion/Airtable/Whatever, that's not destruction—that's evolution.
I worked at a couple of companies that tried to do internal LOB apps. Every single time, these projects have failed because the cost to maintain usually is more than just paying a subscription fee to a third party.
Agents offer a very attractive level of abstraction, and its customers, aren't necessarily human: it could be other agents. Many saas we have today would simply be unnecessary in the future.
If 90% of the actual work is waiting for Agent to get the work done, why would those companies keep paying those saas companies license fee per seat? It doesn't make sense.
Really interesting read, thank you!
I'm currently working for a very traditional SaaS company (let's call us FooBar for the discussion), and I can say that this fear is very real. We talk a lot about the "FooBar killer" which is a theoretical startup company working right now on a better solution than ours. We know that there are a few of those and we even started working on one of our own exactly because of that. If you can't beat the "engineers with a spare Friday afternoon" you might as well join the attempt to replace you.
"I think we can start to see a world already where demand from new customers for certain segments of tooling and apps begins to decline. That's a problem, and will cause an increase in the sales and marketing expenditure of these companies."
I think this sort of ignores the fact that S&M agentic tools exist and the cost of those services is also dramatically decreasing, so does it net out and just become a more efficient model in general?
> most SaaS products contain many features that many customers don't need or use. A lot of the complexity in SaaS product engineering is managing that - which evaporates overnight when you have only one customer (your organisation).
This is the key point. Sure, you don't have the chops to be able to replicate the SaaS product locally with Claude/Gemini, but you don't have to, because you're no trying to make a product that can handle N+1 workflows.
If businesses are rational agents that seek to maximize profit then yes you would expect agentic AI to eat SaaS. But this is not the world we live in. So much of business could be automated with 1990s technology. A model that predicts societal change should also be able to explain why this time it's different. Historical precedent says we should expect:
- modest incremental gains in productivity
- society will remain mostly the same
- very few people will take advantage of the opportunities unlocked by AI
for back office software, I'm actually getting more interest in building weird back office stuff than before, because people know what's possible now.
I'm not a consultant anymore but my friend who owns a dental clinic asked me if I could build them a personalized system that checks in with the staff every week; a thing that helps analyze how they feel week to week and helps my friend update her management strategy and coaches her on how to talk with her staff / helps her figure out her staff's communication strategies and what work they prefer to do; and she'd like me to run and host it so she can't see the raw data from her staff so they'll trust it more as it's run by a third party.
She could probably figure out how to do this but she'd still rather pay me like $5k to do this than spend 100+ hours figuring this out herself. Even with AI it'd probably take me at least a couple of weeks to get it working 100% as intended, and I don't have a dentist business to run.
I think we'll see more back office SaaS, becuase the problems to solve are near infinite, and no one has time to build all these themselves.
Present day AI is a box that has these properties: a human has to create its inputs; a human has to verify its outputs; a human has to create the next input based on the last output. Extremely useful for sure, but this is not the kind of box you can use to scale a service delivered directly to end users who can't perform the activities labeled "human" in the sentence above.
> If anything, I think we'll see (another) splintering in the market. Companies with strong internal technical ability vs those that don't.
A tangent, I feel, again, unfortunately, the AI is going to divide society into people who can use the most powerful tools of AI vs those who will be only be using chatGPT at most (if at all).
I don't know why I keep worrying about these things. Is it pointless?
I do feel this divide, but from what I've read, and ehat I've observed, it's more a divide between people who understand the limited use-cases where machine learning is useful, and people who believe it should be used wherever possible.
For software engineering, it is useless unless you're writing snippets that already exist in the LLMs corpus.
> For software engineering, it is useless unless you're writing snippets that already exist in the LLMs corpus.
If I give something like Sonnet the docs for my JS framework, it can write code "in it" just fine. It makes the occasional mistake, but if I provide proper context and planning up front, it can knock out some fairly impressive stuff (e.g., helping me to wire up a shipping/logistics dashboard for a new ecom business).
That said, this requires me policing the chat (preferred) vs. letting an agent loose. I think the latter is just opening your wallet to model providers but shrug.
If you need a shipping dashboard, then yeah, that's a very common, very simple use-case. Just hook up an API to a UI. Even then I don't think you'll make a very maintainable app that way, especially if you have multiple views (because the LLMs are not consistent in how they use features, they're always generating from scratch and matching whatever's closest).
What I'm saying is that whenever you need to actually do some software design, i.e. tackle a novel problem, they are useless.
1) helping to saturate traditional SaaS because code is being commoditized / the effort to build is dropping significantly.
2) defining an adjacent sub-category of SaaS: "Service-as-a-Software" where the SaaS provides _outcomes_ instead of _tools_; this couldn't really exist at scale before recently.
When you say agents, do you mean the workflow runners that can call APIs and automate the workflow steps?
Automation is not new. What's new is the capabilities of the models that can be assigned with some of the workflow steps. If these steps were served by SaaS companies so far, they will still serve it. Maybe they make it much cheaper and use a model themselves.
This is borderline schizophrenia. Firstly, nobody replaces something that works with something that might or might not work.
Secondly, the way this person describes "agents" is not rooted in reality:
>Agents don't leave. And with a well thought through AGENTS.md file, they can explain the codebase to anyone in the future.
>What's going to be difficult to predict is how quickly agents can move up the value chain. I'm assuming that agents can't manage complex database clusters - but I'm not sure that's going to be the case for much longer.
What in the world. And of course he's selling a course. This is the same business as those people sitting in Dubai selling $6000 options trading courses to anyone who believes their bullshit. The grifter economy around AI is in full swing like it was around blockchain/crypto in 2017-2020.
But who's going to deploy it, make backups, integrate authentication, review security?..
Now, perhaps, it would be nice to have some kind of a ERP framework which would host AI-generated apps and connect them to each other. Is there anything like that?
The ffmpeg wrapper use case is interesting. Reusing some core software for speed and reliability but to get better usability by leveraging LLMs seems like the sweet spot for SaaS use cases. A lot of these CRM products are basically wrappers around DBs and sheets like core products with terrible UI. The new breed will solve the UI ease of use issues.
The real question isn’t whether we’ll run out of SaaS customers, it’s whether we’ll run out of new problems that can be solved by the current set of tools. I doubt it, it’d be a historical first in the modern era. But the solutions may move closer to the companies with the problems. More in-house, fewer intermediaries.
I think the biggest impact will be on SaaS products from startups and side projects. People will think, "I can build something myself with the help of AI, so why should I pay to try your unfinished product?" The barrier to entry has become higher, requiring a more complete product.
The only SaaS that AI has eaten for us is Retool. It wasn't the cost (we were paying < $200 per month). Retool has become more clunky to use vs. writing code with AI to solve the problems we used Retool for.
I get and agree with a lot of skepticism (and I get where ad-hominem attacks come from:). I have AI shoved my throat at work and at home 24x7 and most of it not for my benefit, and the writer doesn't out as much rigor into writing as might be beneficial.
At the same time, to the core theme of the article - do any of us think a small sassy SaaS like Bingo card creator could take off now? :-)
I have been the tech lead for two companies between 2015-2020.
The first company was a low margin business that sent home health care nurses to special needs kids and reimbursements came from Medicaid.
I was hired by the new director to modernize their aging in house Electronic Medical System built on FoxPro 1999 running on SQL Server 2000 - in 2016.
They had two “developers” who had been their for 10 and 20 years respectively who only knew Sql Server and FoxPro.
They also had some other software.
After doing some assessments of the situation, my report to the director and the CTO was that this company should not try to support a software development department and hire new people. Their margins are too small to be competitive or to keep people.
I suggested we outsource everything to other consulting companies - not staff augmentation. Let the consulting company do the entire implementation based on a Statement of Work.
The two “developers” role changed to “data analyst”. Even with AI I would have said the same thing today. Not every company needs to try to do software engineering. Every company does need to understand its data. [1]
The next company was a startup. I was adamant about blocking every developer who suggested any internal tool that we could get a well known SaaS to do or where AWS had a service that wasn’t firefly related to our product. To use the cliche - anything “that didn’t make the beer taste better”. My opinion wouldn’t have changed with AI.
The last thing I want is a bunch of bespoke internal vibe coded AI Slop that we have to support that is not in service to the product when we can find a reputable third party product.
And no that doesn’t mean I am going to trust some unknown one person SaaS company.
[1] 18 months into the job, I walked into the director’s office and told him, “let’s be honest, you all don’t need me anymore”. I purposefully put myself out of job. But boy did I have a story to tell during behavioral interviews at my next job at the startup and my interview for my job at BigTech after I left the startup.
In my experience, AI/Vibe-coded tools crumble under their own weight given enough iterations and even faster if there is no (real) developer in the loop overseeing/planning/reviewing.
I think that _developers_ might be reaching for more LLM-built tools instead of SaaS in some cases and I also can believe that plenty of people _think_ they are vibe-coding up alternatives to SaaSes they pay for but I think those people are going to have a bad time when it eventually collapses (the tool they made, not talking about the AI bubble).
I'm not anti-LLM (not in the slightest) and you can sometimes (it's not a given) get to 80-90% of an existing product/service with vibe-coding or LLM-assisted development but that last 10-20% (and especially that last 1-5%) are where it gets hard. Really hard.
It's the typical "you can already build such a system yourself quite trivially"-mentality IMHO. I feel this myself all the time, even before LLMs, "Oh, I could clone this easily!" and in many cases I could or even did... or at least I cloned the easy/basic/happy-path version that eschewed a whole slew of features I didn't need/care for. But then the complexity started to set in. [0]
I have the same feeling for things I'm not even trying to clone, just build from scratch. I put together a cookbook for friends and family recently and used LLMs to help write essentially a static site generator to read my JSON data I created (some with the help of LLMs) and render it out as HTML (which I then turned into a PDF). My mind started to run with "Hmm, could I create a product out of this? It was relatively easy to get started..." but then reality set in and I remembered all the little tweaks I had to do (shorten a title here, reduce padding there, etc to make everything fit and look good). Sure, I got 80% of the way there in the first or second iteration of it using LLMs but there was plenty of massaging that had to happen to turn it into something usable that I could send to a printer.
Hackernews seems completely astroturfed in the last weeks.
It's not the hackernews i knew even 3 years ago anymore and i'm seriously close to just ditching the site after 15+ years of use.
I use AI heavily but everyday there's crazy optimistic almost manic posts about how AI is going to take over various sectors that are completely ludicrous - and they are all filled with comments from bizarrely optimistic people that have seemingly no knowledge of how software is actually run or built, ie. it's the human organisational, research and management elements that are the hard parts, something AI can't do in any shape or form at the moment for any complex or even small company.
I'm reading this thread's comments and a LOT of you are missing OP's point. OP is not describing the risk that your SaaS product is now easily cloned by your customers' internal devs (or startup competitors) armed with agents. The risk is that certain SaaS products (but not all) mostly exist to provide answers to end users' questions about data, answers that can now be obtained by providing the same raw data to an agent with a prompt.
Summary is that for agents to work well they need clear vision into all things, and putting the data behind a gui or not well maintained CLI is a hinderance. Combined with how structured crud apps are an how the agents can for sure write good crud apps, no reason to not have your own. Wins all around with not paying for it, having a better understanding of processes, and letting agents handle workflows.
honestly, if you are bootstrapping anything, you don't need saas now for the start
SaaS are swiss-army knife tools and you don't need all of this.
do you want to have a contact form on your site? Don't but the whole WP plugin for forms, ask AI for tiny, well-aligned plugin which will display form fields and process the input.
Do you need to A/B test your landing page? Just ask for another plugin which will switch page versions and track impressions.
No need for Hubspot when you have google sheets + AI-made plugin for this.
5. Initially it did equally bad job but I noticed it had a switch "Real-time diff" which did exactly what I wanted.
6. I got curious what is this algorithm. So I asked Gemini with "Deep Research" mode: "The website https://www.diffchecker.com/ uses a diff algorithm they call real-time diff. It works really good for reformatted and corrected text documents. I'd like to know what is this algorithm and if there's any other software, preferably open-source that uses it."
7. As a first suggestion it listed diff-match-patch from Google. It had Python package.
8. I started Antigravity in a new folder, ran uv init. Then I prompted the following:
"I installed the missing dependance for you. Please continue." - I noticed it doesn't use uv for installing dependencies so I interrupted and did it myself.
[...]
"This project uses uv. To run python code use
uv run python test_diff.py" - I noticed it still doesn't use uv for running the code so its testing fails.
[...]
"Semantic cleanup is important, please use it." - Things started to show up but it looked like linear diff. I noticed it had a call to semantic cleanup method commented out so I thought it might help if I push it in that direction.
[...]
"also display the complete, raw diff object below the table" - the display of the diff still didn't seem good so I got curious if it's the problem with the diffing code or the display code
[...]
"I don't see the contents of the object, just text {diffs}" - it made a silly mistake by outputting template variable instead of actual object.
[...]
"While comparing larger files 1.txt and 2.txt I notice that the diff is not very granular. Text changed just slightly but the diff looks like deleting nearly all the lines of the document, and inserting completely fresh ones. Can you force diff library to be more granular?
Maybe there's some better matching algoritm in the library?" - it seemed that while on small tests that Antigravity made itself it worked decently but on the texts that I actually wanted to compare was still terrible although I've seen glimpses of hope because some spots were diffed more granularly. I inspected the code and it seemed to be doing character level diffing as per diff-match-patch example. While it processed this prompt I was searching for solution myself by clicking around diff-match-patch repo and demos. I found a potential solution by adjusting cleanup, but it actually solved the problem by itself by ditching the character level diffing (which I'm not sure I would have come up with at this point). Diffed object looked great but as I compared the result to https://www.diffchecker.com/ output it seemed that they did one minor thing about formatting better.
[...]
"Could you use rowspan so that rows on one side that are equivalent to multiple rows on the other side would have same height as the rows on the other side they are equivalent to?" - I felt very clumsily trying to phrase it and I wasn't sure if Antigravity will understand. But it did and executed perfectly.
I didn't have to revert a single prompt and interrupted just two times at the beginning.
After a while I added watch functionality with a single prompt:
"I'd like to add a -w (--watch) flag that will cause the program to keep running and monitor source files to diff and update the output diff file whenever they change."
[...]
So I basically went from having two very similar text files and knowing very little about diffing to knowing a bit more and having my own local tool that let's me compare texts in satisfying manner, with beautiful highlighting and formatting, that I can extend or modify however I like, that mirrors interesting part of the functionality of the best tool I found online. And all of that in the time span shorter than it took me to write this comment (at least the coding part was, I followed few wrong paths during my search for a bit).
My experience tells me that even if I could replicate what I did today (keeping motivated is an issue for me), it would most likely be multi-day project full of frustration and hunting small errors and venturing into wrong paths. Python isn't even my strongest language. Instead it was a pleasant and fun evening with occasional jaw drops and feeling so blessed that I live in SciFi times I read about as a kid (and adult).
> 3. I tried the usual diff tools. They diffed line by line and result was terrible.
Um. I don't want to be That Guy (shouting at clouds, or at kids to get off my lawn or whatever) but ... what "usual diff" tools did you use? Because comparing two text files with minor edits is exactly what diff-related tools have excelled at for decades.
There is word-level diff, for example. Was that not good enough? Or delta [0] perhaps?
On first glance delta is also doing completely standard thing. But I can't rule out that there are some flags to coerce it to do the thing I wanted. But searching for tools and flag combinations is not that fun and success is not guaranteed. Also I found a (SaaS) tool and a flag there that did exactly what I wanted. Just decided to make my own local tool afterwards for better control. With an agent.
> Because comparing two text files with minor edits is exactly what diff-related tools have excelled at for decades.
True. And I ended up using this excellent Google diff-match-patch library for diffing. AI didn't write me a diffing algorithm. Just everything around it to make a convenient tool for me. Most tools are for source code and treat end lines as a very strong structural feature of compared texts. I needed something that doesn't care about end lines all that much and can show me which characters changed between one line of one file and five lines it was split into in the second file.
Another post with no data, but plenty of personal vibes.
> The signals I'm seeing
Here are the signals:
> If I want an internal dashboard...
> If I need to re-encode videos...
> This is even more pronounced for less pure software development tasks. For example, I've had Gemini 3 produce really high quality UI/UX mockups and wireframes
> people really questioning renewal quotes from larger "enterprise" SaaS companies
> For example, I've had Gemini 3 produce really high quality UI/UX mockups and wireframes
Is the author a competent UX designer who can actually judge the quality of the UX and mockups?
> I write about web development, AI tooling, performance optimization, and building better software. I also teach workshops on AI development for engineering teams. I've worked on dozens of enterprise software projects and enjoy the intersection between commercial success and pragmatic technical excellence.
How wrong the author is about that! IMO As soon as the bubble bursts, which is already evident and imminent, these agents will raise their subscription fees to ridiculous amounts. And when that happens, entire organizations will abandon them and return to good ol' human engineering
But local agents will still keep working. Of course they're not as poweful as an acre of industrially cooled compute power, but still a massive improvement over "Intellisense" and code snippets.
You're 100% right though, you shouldn't build your business on top of an AI service and not have a plan what to do _when_ it either goes away or just prices itself out. It's a massive bubble where money is just moving in a circle.
> IMO As soon as the bubble bursts, which is already evident and imminent, these agents will raise their subscription fees to ridiculous amounts. And when that happens, entire organizations will abandon them and return to good ol' human engineering
It's worse than you state; a primary premise of the current AI expansion and investment, continuously repeated, is that computational resources are increasing for the same price-point.
So tell me, when we have these hardware gains in 5 years, why the fuck would I pay for fractionally better output on a cloud subscription when I could run on-prem GPUs for a fraction of what the actual subscription would be, giving me 24x7 agents working with no limit?
Current highly-invested AI providers are token providers - they are sitting at the bottom of the value-chain. They are trying to climb the value-chain, but the real value is in the models, and since all models have mostly converged on the same performance, running your own gives a very tiny drop in value.
Their problem is that, even at $200/m, it is not feasible to offer 24x7 access to the models - that max subscription has tiny limits: on that subscription you most definitely are not enabling even a single agent to run f/time.
You might get 3 hours per day, maybe. Best case, you get half a working day (4 hours), for five days. So double the subscription, and you're still looking at only a single simply agent that you can run f/time for $400/m.
For collaborating agents, you'll have, what, 4 - 5 diving into a large task in parallel? That's maybe $1600/m - $2000/m to solve tasks. You still have to pay the (increasingly incompetent) human operator to manage them.
That sort of workflow is what is being sold as the vision, and yet that will only be economically viable if you're self-hosting your own model.
The way things are going personal computing will be a thing of the past. It started with GPUs being too expensive but now it’s RAM and eventually SSDs.
We’ll need AI not because it is actually better but because future generations won’t have personal computing hardware to start learning when they are 7.
I'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. One gave up. The other's users tell us it's crap. We've lost zero paying subscribers to free internal alternatives.
I believe that agents are a multiplier on existing velocity, not an equalizer. We use agents heavily and ship faster than ever. We get a lot of feedback from users as to what the internal tech teams are shipping and based on this there's little evidence of any increase in velocity from them.
The bottleneck is still knowing what to build, not building. A lot of the value in our product is in decisions users don't even know we made for them. Domain expertise + tight feedback loop with users can't be replicated by an internal developer in an afternoon.
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 eject a codebase that you, as the domain expert, can hand to a tech team to build something more broadly applicable for your organization."
Nowhere near the level of complexity that would enter your threat model. But this would be the first, minimal step towards customers building their own tools, and the fact that not even this workflow has entered the zeitgeist is... well, it's not the best news for some of the most bullish projections of AI adoption in businesses large and small.
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 handle every edge case and they likely don't even think in terms of "edge cases"
> 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.
Whilst you could plausibly argue that Microsoft have spent the past 25 years attempting to stamp them out, this is exactly what VB6 and VBA were.
People built whole businesses on/around these technologies, and people liked them because you could get something working fast. As maligned as they are nowadays they were so widely used because they delivered value.
You say that, but the crazy people at Microsoft put a COPILOT function into Excel already...
https://support.microsoft.com/en-us/office/copilot-function-...
Reliability doesn't matter any more, there's no liability for being wrong any more.
I miss MSAccess, but for the modern age. It has been replaced by basic CRUD using your platform of choice, but it's not as easy.
That would be similar to your solution, so either one would work.
I think that there might be some similar alternatives (maybe Airtable? probably using Lovable or Firebase counts) but nothing that is available for me for now.
Agree. Lack of something as accessible and useful as Access is a major hole. AppSheet comes close: https://about.appsheet.com/home/
The modern version of Access is something like APEX.
https://www.oracle.com/apex/
APEX is probably just as widely used now as Access was. Access likely had higher market share but of a much smaller market. There are gazillions of APEX apps out there.
You can use something like Salesforce as an app platform if you want. It lets you create "Custom Objects", which are basically tables, write queries, and so on.
It's just that the hassle of dealing with that platform tends to be similar to the hassle of setting up an app yourself, and now you're paying a per-user license cost.
Even Salesforce doesn't have a good way to quickly port an Excel-based workflow, with file handoffs and backwards compatibility, into Salesforce. In theory, you could have an LLM generate all the metadata files that would execute a relevant schema migration, generate the interface XML, and build the right kinds of API calls and webhooks... but understanding what it's doing requires a Ph.D. in Salesforce, and many don't have time for that.
Are you calling out Microsoft specifically or just in general any big tech company? Because Google can do this with Google sheets using Apps Script.
https://developers.google.com/apps-script/guides/web
Microsoft PowerApps has similar workflows for at least 2 years now. The professional development experience is lacking, however enterprise users can create many applications based on Excel files.
It’s possible to do this with excel cia azure or even tying it into power bi first.
> Domain expertise + tight feedback loop
This is the answer to a happy B2B SaaS implementation. It doesn't matter what tools you use as long as this can be achieved.
In the domain of banking front/back office LOB apps, if you aren't iterating with your customer at least once per business day, you are definitely falling behind your competition. I've got semi-retired bankers insisting that live edits in production need to be a fundamental product feature. They used to be terrified of this. Once they get a taste of proper speed it's like blood in the water. I'm getting pushback on live reloads taking more than a few seconds now.
Achieving this kind of outcome is usually more of a meat space problem than it is a technology problem. Most customers can't go as fast as you. But the customer should always be the bottleneck. We've done things like install our people as temporary employees to get jobs done faster.
I might be missing something but live edits in production and banking? Doesn't that violate all kinds of compliance controls?
> Doesn't that violate all kinds of compliance controls?
Technically, only if it causes some kind of security, privacy, availability or accounting issue. The risk is high but it can be done.
Half of our customers do not have anything resembling a test environment. It is incredibly expensive to maintain a meaningful copy of production in this domain. Smaller local/regional banks don't bother at all.
Our sales teams heres the "we'll just build it internally" or "we can just throw it into an LLM" all of the time.
Yes, certain parts of our product are indeed just lightweight wrappers around an LLM. What you're paying for is the 99% of the other stuff that's (1) either extremely hard to do (and probably non-obvious) (2) an endless supply of "routine" work that still takes time (3) an SLA/support that's more than "random dev isn't on PTO"
> "we'll just build it internally" or "we can just throw it into an LLM" all of the time.
Is that a bluff used to negotiate the price?
If it is a credible bluff, does it work?
No because it is never a credible bluff. You would not be having the conversation if it was.
In fact having sold stuff If a lead says this, it is a huge red flag for me that I probably don't want to do business with them because they are probably a "vampire customer"
LLMs can write surprisingly decent code a few hundred lines at a time but they absolutely can't write coherent hundred thousand line or bigger programs.
> (3) an SLA/support that's more than "random dev isn't on PTO"
Why do they have an internal engineering org at all if they can't manage the most basic maintenance of a software product?
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 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.
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 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).
> Nobody is building open source software for [niche professional vertical] in their spare time.
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.
[niche professional vertical] in my response was a stand-in for the specific vertical my startup targets, which is light years from computer security. Computer security is a vertical where the practitioners are often developers or developer-adjacent. You're building tools for people like yourself. That's exactly the "scratch your own itch" dynamic I'm describing.
The vertical I'm in has zero overlap with the developer population. The end users aren't technical, don't participate on HN, and aren't going to "manage an agentic coding project." There's no equivalent of a developer who moonlights on OSS tooling because they're passionate about the problem space, because the problem space requires domain expertise that developers have no reason to acquire.
Most OSS is build by companies to commoditize their complement, not by some random devs building random stuff in free time.
> For one thing, the threat model assumes customers can build their own tools.
That's not the threat model. The threat model is that they won't have to - at some point which may not be right now. End users want to get their work done, not learn UIs and new products. If they can get their analysis/reports based on excels which are already on SharePoint (or wherever), they'd want just that. You can already see this happening.
Yes. This is also why trying to add an AI agent chat into one's product is a fool's errand - the whole point of having general-purpose conversational AI is to turn the product into just another feature.
It's an ugly truth product owners never wanted to hear, and are now being forced to: nobody wants software products or services. No one really wants another Widgetify of DoodlyD.oo.io or another basic software tool packaged into bespoke UI and trying to make itself a command center of work in their entire domain. All those products and services are just standing between the user and the thing the user actually wants. The promise of AI agents for end-users is that of having a personal secretary, that deals with all the product UI/UX bullshit so the user doesn't have to, ultimately turning these products into tool calls.
Assuming this ever works, this is no threat to the SaaS industry. If anything it increases its importance.
SaaS products rely on resisting commoditization. AI agents defeat that.
You're probably thinking "SaaS for other tech end users". Most SaaS is not that.
I think that's just true in general. Business users at $work are already saying that they would rather just talk to ChatGPT (with voice for some reason I, a keyboard person, doesn't understand) than deal with GUIs. They want to describe what they need and have the computer do it, not click around.
Once you've abstracted away the UI (and the training on how to use it) it will be a lot easier to just swap one SaaS for another.
Isn't the majority of SaaS in ERP systems?
Yes, except for the fact that any non-trivial saas does non-trivial stuff that an agent will be able to call (as the 'secretary') while the user still has to pay the subscription to use.
I don't think history opines favorably on companies that lose the last-mile connection with their customers.
For purposes of this thread, if chat AI becomes the primary business interface, then every service behind that becomes much easier to replace.
Yes, but now it's easier for other SaaS to compete on that, because they don't get to bundle individual features under common webshit UI and restrict users to whatever flows the vendor supports. There will be pressure to provide more focused features, because their combining and UI chrome will be done by, or on the other side of, the AI agent.
Also, having to retrain users to use a new shitty UI after they got used to the previous shitty UI is a major moat of many SaaS services. The user doesn't care about the web portal, they just want to get work done. Switching to a different web portal needs to be a big net positive because users will correctly complain that now they are unproductive for a while because the quirks and bugs of the previous SaaS don't match those of the new SaaS.
In a world where the interface is "you talk to the computer" you will be able to swap providers way more easily.
That's the brilliance of AI - it doesn't matter if the product actually works or not. As long as it looks like it works and flatters the user enough, you get paid.
And if you build an AI interface to your product, you can make it not work in subtly the right ways that direct more money towards you. You can take advertising money to make the AI recommend certain products. You can make it give completely wrong answers to your competitors.
Will the SaaS also use LLMs? If so it opens the questions, why not and do we really need, as the article points out.
>> This is also why trying to add an AI agent chat into one's product is a fool's errand - the whole point of having general-purpose conversational AI is to turn the product into just another feature
We built an AI-powered chat interface as an alternative to a fully featured search UI for a product database and it has been one of the most popular features of 2025.
Sure, but it would be even better if it was accessible by ChatGPT[0] and not some bespoke chat interface you created - because with ChatGPT, the AI has all the other tools and can actually use yours in intelligent ways as part of doing something for the user.
--
[0] - Or Claude, or Gemini.
Right -- and that's likely because search was completely broken, people always complained about it, and nothing was ever done to improve it.
> No one really wants another Widgetify of DoodlyD.oo.io
I keep hearing this and seeing people buying more Widgetify of DoodlyD.oo.io. I think this is more of a defensive sales tactic and cope for SaaS losing market share.
The president of a company I work with is a youngish guy who has no technical skills, but is resourceful. He wanted updated analytic dashboards, but there’s no dev capacity for that right now. So he decided he was going to try his hand at building his own dashboard using Lovable, which is one of these AI app making outfits. I sent him a copy of the dev database and a few markdown files with explanations regarding certain trickier elements of the data structure and told him to give them to the AI, it will know what they mean. No updates yet, but I have every confidence he’ll figure it out.
Think about all the cycles this will save. The CEO codes his own dashboards. The OP has a point.
I'd argue it's not CEOs job to code his own dashboards...
This sounds like a vibe coding side project. And I'm sorry, but whatever he builds will most likely become tech debt that has to be rewritten at some point.
Or to steel-man it, it could also end up as a prototype that forced the end user to deal with decision points, and can serve as a framework for a much more specific requirements discussion.
Exactly -- vibe coded PoC becomes a living spec for prod
That's a good point
We perpetually find worse and more expensive ways to reinvent Microsoft Access.
Interesting comment. Which ways have people been doing this?
At a certain scale the CEO's time is likely better spent dictating the dashboard they want rather than implementing it themselves. But I guess to your point, the future may allow for the dictation to be the creation.
Agree, as engineers we should be making the car easier to operate instead of making everyone a mechanic.
Focus on the simple iteration loop of "why is it so hard to understand things about our product?" maybe you cant fix it all today but climb that hill more instead of make your CEO spend some sleepless nights on a thing that you could probably build in 1/10th the time.
If you want to be a successful startup saas sw eng then engaging with the current and common business cases and being able to predict the standard cache of problems they're going to want solved turns you from "a guy" to "the guy".
Most engineers like being mechanics though.
All tech problems are actually people problems.
once the Csuite builds their own dashboards, they quickly decide what they actually need versus what is a nice to have.
And I wonder if they will discover that in order to interpret those numbers in a lot of cases they will need to bring in their direct reports to contextualise them.
If corporate decisions could be made purely from the data recorded then you don't need people to make those decisions. The reason you often do is that a lot of the critical information for decision making is brought in to the meeting out-of-band in people's heads.
Totally!
I have also seen multiple similar use cases where non-technical users build internal tools and dashboards on top of existing data for our users (I'm building UI Bakery). This approach might feel a bit risky for some developers, but it reduces the number of iterations non-technical users need with developers to achieve what they want.
> No updates yet, but I have every confidence he’ll figure it out.
"It" being "that it's harder than it looks"?
> "It" being "that it's harder than it looks"?
Honestly, I'm not sure what to expect. There are clearly things he can't do (e.g. to make it work in prod, it needs to be in our environment, etc. etc.) but I wouldn't be at all surprised if he makes great headway. When he first asked me about it, I started typing out all the reasons it was a bad idea - and then I paused and thought, you know, I'm not here to put barriers in his path.
Update us when you have an actual success story.
The Excel holy grail. Dashboard are an abstraction, SaaS is an abstraction of an abstraction from the pov of customers suffering from a one size fits all. Shell scripts generated by LLMs that send automated a customized reports via email will make a lot of corporate heros. No need to login, learn and use the SaaS in many instances for decisions makers.
I feel that large corps have guard rails that will limit this from happening. For SMB's, this is not a new problem. Gritty IT guys have been doing this for decades. I inherit these bootstrapped reporting systems all the time. The issue is when that person leaves, it is no longer maintainable. I've yet to come across a customer who has had any sort of usable documentation. The process then repeats itself when I take over, and presumably when I'm finished. With a SaaS product, you are at least paying for some support and visibility of the processes. I'm not really trying to make a point other than this is not a new, but still intriguing problem, and not sure that LLMs will be some god answer, as the organizations have trouble determining what they even need.
Yes, back in the heyday of Visual Basic (mid-1990s) we had one business analyst who learned enough to build dashboard-like apps with charts and graphs and parameters and filters. He was quick at it and because it was outside of IT there was little in the way of process or guardrails to slow him down. Users loved what he did, but when he left there was nobody else who knew anything about it.
I second this. Most of our customers IT department struggle to look at the responses from their failed API calls. Their systems and organisations are just too big.
As it stands today; just a bit of complexity is all that is required to make AI Agents fail. I expect the gap to narrow over the years of course. But capturing complex business logic and simplifying it will probably be useful and worth paying for a long time into the future.
Also, for many larger companies, access to internal data and systems is only granted to authorized human users and approved applications/agents. Each approval is a separate request.
This means for any "manual" or existing workflow requiring a access to several systems, that requires multiple IT permissions with defined scopes. Even something as simple as a sales rep sending a DocuSign might need:
- CRM access
- DocuSign access
- Possibly access to ERP (if CRM isn't configured to pass signed contract status and value across)
- Possibly access to SharePoint / Power Automate (if finance/legal/someone else has created internal policy or process, e.g. saving a DocuSign PDF to a folder, inputting details for handover to fulfilment or client success, or submitting ticket to finance so invoicing can be set up)
It is much easier to use an AI API in my bank than to use any other tool. Since the AI is from MS, it's ready to go, whereas other tools require a few months of budgeting, licenses, certs, and so on. Since AI/Azure/AWS is already there and 'certified to use,' it is easier for me to patch something together using this stack than to even ask for open-source software
God I hope my bank isn't using agents to build things. "Sorry, Grok misplaced your retirement funds."
Skills seem to be promising.
I never understood the evolvement around agents, they just appeared to me as Python scripts initially (Crewai 2-3 years ago).
The question is can people see that agents will evolve? Similar to how software evolves to handle the right depth of granularity.
The beauty of HN: frequently comments are way more valuable than the article being shared
There are plenty of HN posts where I only read the comments because the discussion around that topic is the most interesting part.
Agreed. I've been on HN for 15 years, and IME maybe 90% of the value has come directly from comments (another 5% from links in commenters' profiles, and 5% from TFAs).
Yeah I think the real values is for the Solo developers, indie hackers & side projects.
Being unrestrained by team protocols, communications, jira boards, product owners, grumpy seniors.
They can now deliver much more mature platforms, apps, consumer platforms without any form of funding. You can easily save months on the basics like multi tenant set up, tests, payment integration, mailing settings, etc.
It does seem likely that the software space is about to get even crowdier, but also much more feature rich.
There is of course also a wide array of dreamers & visionairies who know jump into the developer role. Wether or not they are able to fully run their own platform im not sure. I did see many posts asking for help at some point.
As a solo grumpy senior, I've been pumping out features over the past 6 months and am now expanding into new markets.
I've also eliminated some third party SaaS integrations by creating slimmer and better integrated services directly into my platform. Which is an example of using AI to bring some features in-house, not primarily to save money (generally not worth the effort if that's the goal), but because it's simply better integrated and less frustrating than dealing with crappy third-party APIs.
> For one thing, the threat model assumes customers can build their own tools. Our end users can't.
Even if they could, the vast majority of them will be more than happy to send $20-100 per month your way to solve a problem than adding it to their stack of problems to solve internally.
You'd hear this all the time back when. "Oh you could build Twitter in a weekend". Yes. Also, very no. This mentality is now on agent steroids. But the lesson is the same.
The basic assumption is, that we already see that an LLM can do basic level of software engineering.
This wasn't even an option for a lot of people before this.
For example, even for non software engineering tasks, i'm at an advantage. "Ah you have to analyse these 50 excel files from someone else? I can write something for it"
I myself sometimes start creating a new small tool i wouldn't have tried before but now instead of using some open source project, i can vibe spec it and get something out.
The interesting thing is, that if i have the base of my specs, i might regenerate it later on again with a better code model.
And we still don't know what will happen when compute gets expanded and expanded. Next year a few more DCs will get online and this will continue for now.
Also tools like google firebase will get 1000x more useful with vibe coding. They provide basic auth and stuff like this. So you can actually focus on writing your code.
God, please no more firebase and mongo. AI coding is really really good at sql/relational data and there are services like supabase and neon that make it dead simple.
> Their current "system" is Excel.
> The bottleneck is still knowing what to build, not building.
I'd amend this to "the bottleneck is being _interested_ in building."
The piece that is _constantly_ missing from AI discourse is that no amount of "breaking down barriers" will result in people who aren't interested in building, building.
I really think that it's as simple as that. Most either don't have the wherewithal or the interest to try and build something beyond the tools that are currently at their disposal -- they're just trying to complete a task, not build the tool that enables them to complete the task; the few that do become programmers. Thus, you have untold instances where "their 'system' is Excel," and programmers selling them solutions to replace it.
It's not intelligence, it's not knowledge, it's not even really aptitude. It's interest.
Another example of this is the reaction to more "creativity-focused" AI models: you see people acting like they've been gate-kept by having to know _how_ to do a thing in order to _do_ a thing, which is somehow this great injustice and AI has finally leveled the playing field so they can finally show those snooty artists who's boss (this attitude is _all over_ places like /r/aiwars). But the reality is that these people simply are not interested enough in music/photography/whatever to learn it, and will largely remain uninterested in the field once this moment is normalized and we get used to the new position of the goalposts. They don't like _creating_, they like _having created_ and whatever social cache they mistakenly believe comes with it (which explains their near-hatred of artists -- they are, very simply, jealous).
These dynamics also explain why no-code tools don't seem to ever stick. Building something requires that the person doing the building be interested in building, but people who are interested in building will have already learned to build in some form or fashion, or at least can easily see the shortcomings with tools that ultimately take away their agency to build and/or their participation in the process (which, for many -- including myself -- is kind of the whole point: I love the process!)
</rant>
> I believe that agents are a multiplier on existing velocity, not an equalizer.
Development tooling improvements usually are a temporary advantage end up being table stakes after a bit of time. I'm more worried that as agentic tooling gets better it obsoletes a lot of SaaS tools where SaaS vendors count on users driving conventional point and click apps (web, mobile and otherwise). I'm encouraging the companies I'm involved with to look to moving to more communication driven microexperience UIs - email, slack, sms, etc instead of more conventional UI.
What I'm seeing Ad infinitum on HN in every thread on agentic development: yeah but it really doesn't work perfectly today.
None of these people can apparently see beyond the tip of their nose. It doesn't matter if it takes a year, or three years, or five years, or ten years. Nothing can stop what's about to happen. If it takes ten years, so what, it's all going to get smashed and turned upside down. These agents will get a lot better over just the next three years. Ten years? Ha.
It's the personal interest bias that's tilting the time fog, it's desperation / wilful blindness. Millions of highly paid people with their livelihoods being disrupted rapidly, in full denial about what the world looks like just a few years out, so they shift the time thought markers to months or a year - which reveals just how fast this is all moving.
You aren't wrong, but you’re underestimating the inertia of $10M+/year B2B distributors. There are thousands of these in traditional sectors (pipe manufacturing, HVAC, etc.) that rely on hyper-localized logistics and century-old workflows.
Buyer pressure will eventually force process updates, but it is a slow burn. The bottleneck is rarely the tech or the partner, it's the internal culture. The software moves fast, but the people deeply integrated into physical infrastructure move 10x slower than you'd expect.
Internal culture changes on budget cycles, and right now, most companies are being pushed by investors to adopt AI. Have your sales team ask about AI budgeting vs. SaaS budgeting. I think you'll find that AI budget is available and conventional SaaS/IT budget isn't. Most managers are looking for a way to "adopt ai" so I think we're in a unique time.
> people deeply integrated into physical infrastructure move 10x slower than you'd expect.
My experience is yes, to move everyone. To do a pilot and prove the value? That's doable quickly, and if the pilot succeeds, the rest is fast.
I don't think you can guarantee it will get better. I'm sure it will improve from here but by how much? Have the exponential gains topped out? Maybe it's a slow slog over many years that isn't that disruptive. Has there been any technology that hasn't hit some kind of wall?
> The bottleneck is still knowing what to build, not building. A lot of the value in our product is in decisions users don't even know we made for them. Domain expertise + tight feedback loop with users can't be replicated by an internal developer in an afternoon.
The cost of building is going decreasing every year. The barriers of entry will come down year after year.
So what remains is knowing what you build (= product) as you write and knowing how to get exposure (= marketing). Focus on these two not on building things.
That's basically the conclusion of the library:
> But my key takeaway would be that if your product is just a SQL wrapper on a billing system, you now have thousands of competitors: engineers at your customers with a spare Friday afternoon with an agent.
I think the issue is that the "two of them explicitly cloned" were trying to clone something that's more than "just a SQL wrapper on a billing system."
That may well be an exception though. I'd imagine most SaaS builders are very much figuring things out as they go rather than starting with deep domain expertise
Additional hot take: deep domain expertise is only value-add while actively adding new features
There's a huge subset of SaaS that's feature-frozen and being milked for ARR.
Agreed. This is why PE buys so many SaaS companies!
My article here isn't really aimed at "good" SaaS companies that put a lot of thought into design, UX and features. I'm thinking of the tens/hundreds of thousands+ of SaaS platforms that have been bought by PE or virtually abandoned, that don't work very well and send a 20% cost renewal through every year.
Deep domain expertise is not common enough.
Not sure why the argument is SaaS or build from the ground up. Agents can deploy open source projects and build new featurees on top of them pretty effectively.
I'm gonna go ahead and guess that if you have open source competitors, within two years your moat is going to become marketing/sales given how easy it'll be to have an agent deploy software and modify it.
Damn, reading this is clear you two know your market well. Congratulations. This is the right way to do it. Domain expertise + tight feedback loop, probably makes customers feel like they are part of the process and that you’re there for them. Are you hiring?
While most here are aligned with your perspective, and for good reasons, let me offer an alternate perspective. Today AI can take the goal and create a workflow for it. Something that orgs pay for in SaaS solutions.
AI does it imperfectly today, but if you have had to bet, would you bet that it gets better or worse? I would bet that it will improve, and as it is often with tech, at exponential rate. Then we would seen any workflow described in plain language and minutes see great software churned out. It might be a questions of when (not if) that happens. And are you prepared for that state of affairs?
I'll add another obvious one: No rule that the SaaS, with its obviously much deeper technical expertise, can itself then leverage these tools to achieve even greater velocity, thereby exacerbating the problem for "internal teams"
Customers will be able to build skills.
Not being able to see this is a blind spot.
Domain expertise in an industry usually sits within the client, and is serviced to some degree by vendors.
Not all CEOs have deep domain expertise, nor do they often enough stick to one domain. Maybe that’s where a gap exists.
I completely agree.
Corporates are allergic to risk; not to spending money.
If anything, I feel that SaaS and application development for larger organisations stands to benefit from LLM assisted development.
Same background as you and I fully agree. Again and again you see market/economic takes from technologists. This is not a technology question (yes, LLMs work), it's an economics question: what do LLMs disrupt?
If your answer is "cost of developing code" (what TFA argues), please explain how previous waves of reducing cost of code (JVM, IDEs, post-Y2K Outsourcing) disrupted the ERP/b2b market. Oh wait, they didn't. The only real disruption in ERP in the last what 30 years, has been Cloud. Which is an economics disruption, not a technological one: cloud added complexity and points of failure and yet it still disrupted a ton of companies, because it enabled new business models (SaaS for one).
So far, the only disruption I can see coming from LLMs is middleware/integration where it could possibly simplify complexity and reduce overall costs, which if anything will help SaaS (reduction of cost of complements, classic Christensen).
I'll take a crack.
> what do LLMs disrupt? If your answer is "cost of developing code" (what TFA argues), please explain how previous waves of reducing cost of code (JVM, IDEs, post-Y2K Outsourcing) disrupted the ERP/b2b market. Oh wait, they didn't. The only real disruption in ERP in the last what 30 years, has been Cloud.
"Cost of developing code" is a trivial and incomplete answer.
Coding LLMs disrupt (or will, in the immediate future)
(1) time to develop code (with cost as a second order effect)
(2) expertise to develop code
None of the analogs you provided are a correct match for these.
A closer match would be Excel.
It improved the speed and lowered the expertise required to do what people had previously been doing.
And most importantly, as a consequence of especially the latter more types of people could leverage computing to do more of their work faster.
The risk to B2B SaaS isn't that a neophyte business analyst is going to recreate you app overnight...
... the risk is that 500+ neophyte business analysts each have a chance of replacing your SaaS app, every day, every year.
Because they only really need to get lucky once, and then the organization shifts support to in-house LLM-augmented development.
The only reason most non-technology businesses didn't do in-house custom development thus far was that ROI on employing a software development team didn't make sense for them. Suddenly that's no longer a blocker.
To the point about cloud, what did it disrupt?
(1) time to deploy code (with cost as a second order effect)
(2) expertise to deploy code
B2B SaaS should be scared, unless they're continuously developing useful features, have a deep moat, and are operating at volumes that allow them to be priced competitively.
Coding agents and custom in-house development are absolutely going to kill the 'X-for-Y' simple SaaS clone business model (anything easily cloneable).
This seems to assume that these non-technical people have the expertise to evaluate LLM/agent generated solutions.
The problem of this tooling is that it cannot deploy code on its own. It needs a human to take the fall when it generates errors that lose people money, break laws, cause harm, etc. Humans are supposed to be reviewing all of the code before it goes out but you’re assumption is that people without the skills to read code let alone deploy and run it are going to do it with agents without a human in the loop.
All those non-technical users have to do is approve that app, manage to deploy and run it themselves somehow, and wait for the security breach to lose their jobs.
I think you're underestimating (1) how bad most B2B is (from a bug and security vulnerability perspective) & (2) how little B2B companies' engineers understand about how their customers are using their products.
The frequency of mind-bogglingly stupid 1+1=3 errors (where 1+1 is a specific well-known problem in a business domain and 3 is the known answer) cuts against your 'professional SaaS can do it better' argument.
And to be clear: I'm talking about 'outsourced dev to lowest-cost resources' B2B SaaS, not 'have a team of shit-hot developers' SaaS.
The former of which, sadly, comprises the bulk of the industry. Especially after PE acquisition of products.
Furthermore, I'm not convinced that coding LLMs + scanning aren't capable of surpassing the average developer in code security. Especially since it's a brute force problem: 'ensure there's no gap by meticulously checking each of 500 things.'
Auto code scanning for security hasn't been a significant area of investment because the benefits are nebulous. If you already must have human developers writing code, then why not have them also review it?
In contrast, scanning being a requirement to enabling fast-path citizen-developer LLM app creation changes the value proposition (and thus incentive to build good, quality products).
It's been mentioned in other threads, but Fire/Supabase-style 'bolt-on security-critical components' is the short term solution I'd expect to evolve. There's no reason from-scratch auth / object storage / RBAC needs to be built most of the time.
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? Weighed against security risks? And so the point that was established.
If suddenly that business user can add substantial amounts of value to the org, I'd be very surprised if that point doesn't shift.
It matters AND...
Yeah. I used to manage a team that built a kind of low-code SaaS solution to several big enterprise clients. I sat in on several calls with our sales people and the customer’s IT department.
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.
>> 2) expertise to develop code
This is wrong. Paradoxically, you need expertise to develop code with LLM.
For LOB CRUD apps? We blew past that capability point months ago.
I'm going to predict there will be a movement into "build it in house with LLMs", these things are going to be expensive, they are going to fail to deliver or be updated and there will be a huge bounce back. The cost of writing software is very small, the cost of running and scaling it is there the money is and these people can't have their own IT teams rebuilding and maintaining all this stuff form scratch.
A lot of them will try though, just means more work for engineers in the future to clean this shit up.
I think there's a good chance. These things happen in cycles. A few decades ago it was common for companies to have in-house software development using something like COBOL or maybe BASIC (and at that time, sofware development was a cost-center job, it paid OK but nothing like what it does today). Then there was a push for COTS (commercial of-the-shelf) software. Then the internet made SaaS possible and that got hot. Developer salaries exploded. Now LLMs have people saying "just do it in house" again. Lessons are forgotten and have to be re-learned.
> The bottleneck is still knowing what to build, not building.
My hot take - LLMs are exposing a whole bunch of developers to this reality.
I'm seeing that in the GRC industry where SaaS companies are getting churned out by an internal IT guy who automated their "Excel" as a database.
Yap. AI and agents help to centralise, not decentralise
For now.
I'm expecting this to be a bubble, and that bubble to burst; when it does, whatever's the top model at that point can likely still be distilled relatively cheaply like all other models have been.
That, combined with my expectations that consumer RAM prices will return to their trend and decrease in price, means that if the bubble pops in the year 20XX, whatever performance was bleeding edge at the pop, runs on a high-end smartphone in the year 20XX+5.
The technology of LLMs is already applicable to valuable enough problems, therefore it won’t be a bubble.
The world might be using a standard of AI needing to be a world beater to succeed but it’s simply not the case, AI a is software, and it can solve problems other software can’t.
> The technology of LLMs is already applicable to valuable enough problems, therefore it won’t be a bubble.
Dot-com was a bubble despite being applicable to valuable problems. So were railways when the US had a bubble on those.
Bubbles don't just mean tulips.
What we've got right now, I'm saying the money will run out and not all the current players will win any money from all their spending. It's even possible that *none* of the current players win, even when everyone uses it all the time, precisely due to the scenario you replied to:
Runs on a local device, no way to extract profit to repay the cost of training.
> repay the cost of training
Key point. Once people realize that no money can be made from LLMs, they will stop training new ones. Eventually the old ones will become hopelessly out-of-date, and LLMs will fade into history.
Ai is much more developed at its entrance to the economy than most anything during the dot com boom.
Dot com is not super comparable to AI.
Dot com had very few users on the internet compared to today.
Dot com did not have ubiquitous e-commerce. The small group of users didn’t spend online.
Search engines didn’t have the amount of information online that there is today.
Dot com did not have usable high speed mobile data, or broadband available for the masses.
Dot com did not have social media to share and alas how things can work as quickly.
LLMs were largely applicable to industry when gpt 4 came out. We didn’t have the new terms of reference for non deterministic software.
None of that matters to this point, though I'd dispute some of it if I thought it did.
"Can they keep charging money for it?", that's the question that matters here.
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 a hype train, there is also an adoption and disruption train, which is also happening.
I could go on, but I’m comfortable with seeing how well this comment ages.
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 free ones that are being given away. And buy "spend a lot" I mean they are making a loss.
This means that the similarity with the dot com bubble can be expressed with the phrase "losing money on every sale and making up for it in volume".
Hardware efficiency is also still improving; just as I can even run that image model locally on my phone, an LLM equivalent to SOTA today should run on a high-end smartphone in 2030.
Not much room to charge people for what runs on-device.
So, they are in a Red Queen's race, running as hard as they can just to stay where they are. And where they are today, is losing money.
You don't need RAM to run LLMs. Your graphics card does.
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.
The big models will never run locally, and I doubt that titan and co will run locally, just way to much resources needed
"never" vs https://en.wikipedia.org/wiki/Koomey%27s_law
Observably, the biggest models we have right now have similar complexity to a rodent's brain, which runs on far less power. Limiting factors for chips in your phone is power, power efficiency is improving rapidly.
Maybe expect more paragraph 2 for flat fees or cheaper as many people who know how to code find themselves without employment?
A year or two from now it will be trivial to copy your product
Did you claim the same a year or two ago? Why or why not?
It was always relatively easy to copy many SaaS services, especially bootstrapped ones. Unless everybody wants to make and run their service locally, very little changes.
But what about their two year head start? If everyone is executing at the speed of light, there will still be winners and losers
Yes friend. That's what people said 2 years ago. Next?
There's been an obvious step change on the coding front from 2 years ago, and it feels obvious to me there's going to be another. The difference now is the people working on systems to clone SaaS at scale are likely starting to put real effort, sustained effort into now that agents are good enough to accomplish subsets of it, can be improved much further with the right techniques and orchestration, and themselves will get better over the next two years along with all the improvements and build up of tooling. Right now feels like one of those "skate to where the puck is going to be" moments in time.
Personally, hard disagree. There were improvements, yes, but the last year felt particularly stagnant to me
I've found assigning issues to GitHub Copilot on GitHub itself to be a real step-wise change from one off requests to a chat based interface that has no awareness of my codebase. Maybe it's just me, but I'm getting significantly more realworld value out of AI these days. I've been working through doing an implementation of a spec using GitHub Copilot mostly from my phone, and it has been a really instructive exercise in how to squeeze as much out such a narrow interface as possible. I still dip into a full desktop + IDE from time to time, but for like 90% of it I've been doing it in my phone. Slowly but surely working my way from "vibe coded in a weekend" level initial AI slop quality to nice, clean architecture, excellent dev tooling, production grade multitenant SaaS. I've still got a ways to go, but I'm able to make quite a lot of progress just using my phone during my commute, on my lunch breaks, in between meetings, and bathroom breaks etc.
And? How easy will it be to iterate the product and build features and a user experience as it is used in the wild? How easy will it be to find customers willing to pay you money for it?
Doesn’t have to be a commercial solution to change the game. There’s a lot of room between the commercial product and ‘Our end users… current "system" is Excel.’ Especially if the market moves towards making useful APIs at the ERP and vendors endpoints.
And how would the outcome be different after a couple of years than the internally built Excel file with VBScript, Access and VB6 apps built by non developers back in the day?
> The bottleneck is still knowing what to build, not building.
shit, I'm stealing that quote! it's easier to seize an opportunity, (i.e. build a tool that fixes the problem X without causing annoying Y and Z side effects) but finding one is almost as hard as it was since the beginning of the world wide web.
I am the founder of a niche SaaS (https://partsbox.com/ — software for managing electronic parts inventory and production). While I am somewhat worried about AI capabilities, I'm not losing too much sleep over it.
The worry is that customers who do not realize the full depth of the problem will implement their own app using AI. But that happens today, too: people use spreadsheets to manage their electronic parts (please don't) and BOMs (bills of materials). The spreadsheet is my biggest competitor.
I've been designing and building the software for 10 years now and most of the difficulty and complexity is not in the code. Coding is the last part, and the easiest one. The real value is in understanding the world (the processes involved) and modeling it in a way that cuts a good compromise between ease of use and complexity.
Sadly, as I found out, once you spend a lot of time thinking and come up with a model, copycats will clone that (as well as they can, but superficially it will look similar).
> The real value is in understanding the world (the processes involved) and modeling it in a way that cuts a good compromise between ease of use and complexity.
Which I don't think can be replaced by AI in a lot of cases. I think in the software world we are used to things being shared, open and easily knowable, but a great deal of industry and enterprise domain knowledge is locked up inside in companies and will not be in the training data.
That's why it's such a big deal for an enterprise to have on prem tools, to avoid leaking industry processes and "secrets" (the secrets are boring, but still secrets).
A little career advice in there too I guess. At least for now, you're a bit more secure as a developer in industries that aren't themselves software, is my guess.
> Which I don't think can be replaced by AI in a lot of cases
Yes. I try to visit my customers as often as I can, to learn how they work and to see the production processes on site. I consider it to be one of the most valuable things I can do for the future of my business.
Not specific to PartsBox, but we use Inventree (open source similar to PartsBox) and self host it. Over the past few months we noticed certain pain points in our workflow. Rather than looking for a new tool, we used Claude Code to write some backend services and some frontend modifications. Took 2 days of tinkering. Has easily saved that much time since we implemented it.
While rolling the whole solution with an AI agent is not practical, taking a open source starting point and using AI to overcome specific workflow pain points as well as add features allows me to have a lower cost, specifically tailored solution to our needs.
I would include this in the "spreadsheet" metaphor. I do not know your use case, so please don't take this as addressed to you specifically, but I found that there is a learning/complexity problem: many people do not realize there is much more to inventory and production management than it seems. It might seem easy to AI-code something, only to find out later that things could have been done much better.
This is actually a serious problem for me: my SaaS has a lot of very complex functionality under the hood, but it is not easily visible, and importantly it isn't necessarily appreciated when making a buying decision. Lot control is a good example: most people think it is only needed for coding batches of expiring products. In reality, it's an essential feature that pretty much everyone needs, because it lets you treat some inventory of the same part (e.g. a reel) differently from other inventory of this part (e.g. cut tape) and track those separately.
AI-coding will help people get the features they know they need, but it won't guide them to the features they don't know they could use.
"AI-coding will help people get the features they know they need, but it won't guide them to the features they don't know they could use." Amen to this.
First, I'll second that I've applied agentic LLMs to an open source project to fix bugs and forcibly coerce it to act in ways that the maintainer may or may not approve of. It has been remarkablely effective, so long as I'm willing to apply patches or maintain a fork of the project (trivial, since this particular open-source project is abandoned anyway).
That said, the act of doing this- using LLMs to dominate somebody's legitimately intelligent and unique work- feels not only discourteous, but worse, like it's a short-term solution.
I'm convinced that it's a short-term solution NOT because I don't think that LLMs can continuously maintain these projects, but because open-source itself is going to be clawed back. The raison d'être of open-source is personal pride, hiring, collaboration, enjoyment, trust, etc. These motivations make less sense in an LLM-fueled world.
My prediction is that useful and well maintained open-source projects like we're hijacking will become fewer and far between.
I support Inventree. Even have raised PRs. Im specifically referring to things that are custom to our workflow.
That's great! I'm not accusing you or anything, or myself for that matter, I'm only lamenting that open source will likely decay due to LLMs. Or at the very least, open source will no longer be seen as the height of virtue in our industry.
Won't this breakdown if you need to pull new changes from the original project?
No. Written against the documented APIs and extension points.
"in ways that the maintainer may or may not approve of" does not sound like using the documented extension points.
> Coding is the last part, and the easiest one. The real value is in understanding the world (the processes involved) and modeling it in a way that cuts a good compromise between ease of use and complexity.
Coding and modeling are interleaved. Prototyping is basically thinking through the models you are considering. If you split the two, you'll end up with a bad model, bad software or both.
Coding agents like Claude are just one line of AI making inroads. There are lot of nearly tasks that can be almost, but not quite, implemented effectivly with existing tools like Excel and Word. As they seek a return on their investments, are MS likely to target those nearly cases with AI in their Access, Excel, Word etc product lines?
I have two tech q about partsbox. Why Clojure? Why not CL (lack of saas related-features)?
Clojure is just better than CL in pretty much every respect. Excellent and well designed standard library, great concurrency primitives, core.async, built-in transducers (CL has SERIES which does a kind-of similar thing, but isn't as well designed and integrated) and the dominant immutability all let me write more maintainable code. Also, I can re-use model code on the client side (ClojureScript), so there is lots of code sharing, and I don't have to serialize to a crippled format (JSON), my data can pass from server to client and back intact (with sets, keywords, and other rich data types).
I used to love CL and wrote quite a bit of code in it, but since Clojure came along I can't really see any reason to go back.
I did not try Clojure so I cannot comment on how well implemented the features you quote are, when compared to CL. All I can say is that CL also provides much of the same functionality with its standard, cl-async, lparallel, parenscript, while (im)mutability is a matter of preference (IMO correct decision by CL) rather than dominance. The way I see it, is that CL is superior (opinion) due to reader macros and native compilation, rather than bytecode JVM.
I used CL for many years before I switched to Clojure. And by "used" I mean really used it, not just for applications, but I also dove into CL implementations, for example I added return-from-frame (also known as debug-return) to CMUCL.
So, I kind of know what I'm talking about :-) And I don't miss anything from CL: I honestly can't find a single reason to switch back to CL.
The problem IMO is simpler.
You have a product, which sits between your users and what your users want. That product has an UI for users to operate. Many (most, I imagine) users would prefer to hire an assistant to operate that UI for them, since UI is not the actual value your service provides. Now, s/assistant/AI agent/ and you can see that your product turns into a tool call.
So the simpler problem is that your product now becomes merely a tool call for AI agents. That's what users want. Many SaaS companies won't like that, because it removes their advertising channel and commoditizes their product.
It's the same reason why API access to SaaS is usually restricted or not available for the users except biggest customers. LLMs defeat that by turning the entire human experience into an API, without explicit coding.
> So the simpler problem is that your product now becomes merely a tool call for AI agents. That's what users want.
This is a big assumption, and not one I've seen in product testing. Open-ended human language is not a good interface for highly detailed technical work, at least not with the current state of LLMs.
> It's the same reason why API access to SaaS is usually restricted or not available for the users except biggest customers.
I don't... think this is true? Of the top of my head, aside from cloud providers like AWS/GCP/Azure which obviously provide APIs: Salesforce, Hubspot, Jira all provide APIs either alongside basic plans or as a small upsell. Certainly not just for the biggest customers. You're probably thinking of social media where Twitter/Reddit/FB/etc don't really give API access, but those aren't really B2B SaaS products.
Hmm. I think none of what you wrote is applicable to my specific SaaS.
> Many (most, I imagine) users would prefer to hire an assistant to operate that UI for them, since UI is not the actual value your service provides
That's ridiculous. A good ui will improve on assistant in every way.
Do assistants have some use? Sure—querying.
> A good ui will improve on assistant in every way.
True.
"Good" UI seems to be in short supply these days, even from trillion dollar corporations.
But even with that, it is still not "ridiculous" for many to prefer to "hire an assistant to operate that UI for them". A lot of the complexity in UI is the balance between keeping common tasks highly visible without hiding the occasional-use stuff, allowing users to explore and learn more about what can be done without overwhelming them.
If I want a spaceship in Blender and don't care which one you get — right now the spaceship models that any GenAI would give you are "pick your poison" between Diffusion models' weirdness and the 3D equivalent of the pelican-on-a-bike weirdness — the easiest UI is to say (or type) "give me a spaceship", not doing all the steps by hand.
If you have some unformatted time series data and want to use it to forecast the next quarter, you could manually enter it into a spreadsheet, or you could say/type "here's a JPG of some time series data, use it to forecast the next quarter".
Again, just to be clear, I agree with everyone saying current AI is only mediocre in performance, it does make mistakes and shouldn't be relied upon yet. But the error rates are going down, the task horizons they don't suck at are going up. I expect the money to run out before they get good enough to take on all SaaS, but at the same time they're already good enough to be interesting.
I'm seeing the opposite. AI is actually increasing the demand for what would previously be too expensive, bespoke integrations and solutions. Those are now becoming more feasible and doable. There is also the notion that a lot of companies are actually very behind on embracing software or SAAS. Especially in manufacturing it's common to see operations that haven't materially changed anything in decades.
The fallacy here is believing we already had all the software we were going to use and that AI is now eliminating 90% of the work of creating that. The reality is inverted, we only had a fraction of the software that is now becoming possible and we'll be busy using our new AI tools to create absolutely massive amounts of it over the next years. The ambition level got raised quite a bit recently and that is starting to generate work that can only be done with the support of AI (or an absolutely massive old school development budget).
It's going to require different skills and probably involve a lot more domain experts picking up easy to use AI tools to do things themselves that they previously would have needed specialized programmers for. You get to skip that partially. But you still need to know what you are doing before you can ask for sensible things to get done. Especially when things are mission critical, you kind of want to know stuff works properly and that there's no million $ mistakes lurking anywhere.
Our typical customers would need help with all of that. The amount of times I've had to deal with a customer that had vibe coded anything by themselves remains zero. Just not a thing in the industry. Most of them are still juggling spreadsheets and ERP systems.
> Especially in manufacturing it's common to see operations that haven't materially changed anything in decades.
> Especially when things are mission critical, you kind of want to know stuff works properly and that there's no million $ mistakes lurking anywhere.
This is what I'm wondering about; things don't change because the company doesn't like change, and the risks of change are very real. So changes either have to be super incremental, or offer such a compelling advantage that they can't be ignored. And AI just doesn't offer the sort of reproducible, reliable results that manufacturing absolutely depends on.
I don't think that's entirely correct. You can do TDD style development with AI and it leads to better results.
It's just that messing with a company's core manufacturing is something they don't do lightly. They work with multiple shifts of staff that are supposed to work in these environments. People generally don't have a lot of computer skills, so things need to be simple, repeatable, and easy to explain. Any issues with production means cost increases, delays happen, and money is lost.
That being said, these companies are always looking for better ways to do stuff, to eliminate work that is not needed, etc. That's your way in. If there's a demonstrable ROI, most companies get a lot less risk averse.
That used to involve bespoke software integrations. Those are developed at great cost and with some non trivial risk by expensive software agencies. Some of these projects fail and failure is expensive. AI potentially reduces cost and risk here. E.g. a generic SAP integration isn't rocket science to vibe code. We're talking well documented and widely used APIs here. You'd want some oversight and testing here obviously. But it's the type of low level plumbing that traditionally gets outsourced to low wages countries. Using AI here is probably already happening at a large scale.
If you look at past automation efforts, the automation initially made workers more valuable. They could produce more, at lower cost, and there was plenty of demand. Eventually, you hit the realistic limits of demand though, and the number of workers started to drop.
If software gets cheaper, people will buy more of it, to a point.
This 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 a small monthly fee to a SaaS company.
Note that there is zero actual sales/renewal data quoted in the article so this is all the authors vibes based on how he has been able to vibe code a few things for a team of one person to use
> AI-generated code still requires software engineers to build, test, debug, deploy, ensure security, monitor, be on-call, handle incidents, and so on. That's very expensive. It is much cheaper to pay a small monthly fee to a SaaS company.
Yeah it's a fundamental misunderstanding of economies of scale. If you build an in-house app that does X, you incur 100% of the maintenance costs. If you're subscribed to a SaaS product, you're paying for 1/N % of the maintenance costs, where N is the number of customers.
I only see AI-generated code replacing things that never made sense as a SaaS anyway. It's telling the author's only concrete example of a replaced SaaS product is Retool, which is much less about SaaS and much more about a product that's been fundamentally deprecated.
Wake me up when we see swaths of companies AI-coding internal Jira ("just an issue tracker") and Github Enterprise ("just a browser-based wrapper over git") clones.
"Wake me up when we see swaths of companies AI-coding internal Jira".
This shouldnt be the goal. The goal should be to build an AI that can tell you what is done and what needs to be done i.e. replace jira with natural interactions. An AI that can "see" and "understand" your project. An AI that can see it, understand it, build it and modify it. I know this is not happening for the next few decades or so.
> This shouldnt be the goal. The goal should be to build an AI that can tell you what is done and what needs to be done i.e. replace jira with natural interactions. An AI that can "see" and "understand" your project. An AI that can see it, understand it, build it and modify it.
The difference is that an AI-coded internal Jira clone is something that could realistically happen today. Vague notions of AI "understanding" anything are not currently realistic and won't be for an indeterminate amount of time, which could mean next year, 30 years from now, or never. I don't consider that worth discussing.
You could have stopped at this article makes no sense - it couches and argues against itself to the point that it really says very little.
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?
Analytics like what?! Sentry? See, i'm the first one to waste 15+ hours of my own time claude vibing some barely working analytics in order to save 15 dollars for not paying a proven solution to professionals who really understand that problem domain - but we all agree how dumb this is. But if i really can vibe code that analytics in 5 minutes, that thing was never a proven SaaS business in the first place and my use case with certainty a toy app with zero users..
The value proposition of SaaS is ultimately just that it's not a hack.
Most SaaS products could be replaced by a form + spreadsheet + email workflow, and the reason they aren't is that people don't want to be dealing with a hacky solution. Devs can hack together a nice little webapp instead of a network of spreadsheets, but it's still a hack. Factoring in AI assistance, perhaps SaaS is now competing with "something I hacked together in a week" as opposed to "something I hacked together in a month," but it's a hack either way.
I am absolutely going to pay for analytics and dashboards, because I don't want the operational concerns of my Elasticsearch analytics cluster getting in the way of the alarm that goes off when my primary database catches fire. Ops visibility is too important to be a hack, regardless of how quickly I could implement that hack.
Yes, because then I know the code is properly engineering, tested, maintained and supported.
Generating code is one part of software engineering is a small part of SaaS.
How do you/I know that? I implemented OpenTelemetry in a project of mine recently and was shocked to see the number of AI authored commits in the git repository.
> How do you/I know that? I implemented OpenTelemetry in a project of mine recently and was shocked to see the number of AI authored commits
Do you pay for OpenTelemetry? How is this related?
If I did, I likely wouldn't have access to the source code and wouldn't be able to verify the degree of AI input.
So, I ask again - how do you know that the service you're paying for is all of those things?
> So, I ask again - how do you know that the service you're paying for is all of those things?
How do you know anything? How do you know the bank won't lose your money? How do you know the bank note you hold is worth what it says? How do you know?
I'd love for SaaS to stay thriving but the flip side is simply the harsh reality that my own second thought these days is immediately "how easily will an agent replace my idea? yea probably quite easily..."
Ideas were never worth much. Implementing a quick prototype was always pretty simple. How easy is it, with modern tooling, to build a collaborative web editor? Just slap together prosemirror and automerge and you're already there. Still, nobody has displaced Google Docs.
Before AI, people would search for a free or open source alternatives before using a saas
The bit about building an internal app for eg marketing or sales is super fun. Getting calls starting at 8am EST because they then (reasonably!) expect it to work less so. Software still has an enormous ktlo tax and until that changes, I'm skeptical about the entire thesis.
Not to mention the author appears to run a 1-2 person company, so ... yeah. AI thought leadership ahoy.
I’m currently working on an in house ERP and inventory system for a specific kind of business. With very few people you can now instead of paying loads of money for some off the shelf solution to your software needs get something completely bespoke to your business. I think AI enables the age of boutique software that works fantastically for businesses, agencies will need to dramatically reduce their price to compete with in house teams.
I’m pretty certain AI quadruples my output at least and facilitates fixing, improving and upgrading poor quality inherited software much better than in the past. Why pay for SaaS when you can build something “good enough” in a week or two? You also get exactly what you want rather than some £300k per year CRM that will double or treble in price and never quite be what you wanted.
> Why pay for SaaS when you can build something “good enough” in a week or two?
About a decade ago we worked with a partner company who was building their own in-house software for everything. They used it as one of their selling points and as a differentiator over competitors.
They could move fast and add little features quickly. It seemed cool at first.
The problems showed up later. Everything was a little bit fragile in subtle ways. New projects always worked well on the happy path, but then they’d change one thing and it would trigger a cascade of little unintended consequences that broke something else. No problem, they’d just have their in-house team work on it and push out a new deploy. That also seemed cool at first, until they accumulated a backlog of hard to diagnose issues. Then we were spending a lot of time trying to write up bug reports to describe the problem in enough detail for them to replicate, along with constant battles over tickets being closed with “works in the dev environment” or “cannot reproduce”.
> You also get exactly what you want rather than some £300k per year CRM
What’s the fully loaded (including taxes and benefits) cost of hiring enough extra developers and ops people to run and maintain the in house software, complete with someone to manage the project and enough people to handle ops coverage with room for rotations and allowing holidays off? It turns out the cost of running in-house software at scale is always a lot higher than 300K, unless the company can tolerate low ops coverage and gaps when people go on vacation.
In my experience, SaaS is also fragile. It's real software, with real bugs. Most complex solutions offer an extensible API/scripting support with tons of switchable/pluggable modules to integrate with your company's infra. This complexity most often means that your particulary combination of features is almost wholly unique, and chances are your SaaS has much less open mindshare/open source support than any free solution.
We often ended up discarding large chunks of these poorly tested features, instead of trying to get them to work, and wrote our own. This got to a point where only the core platform was used, and replacing that seemed to be totally feasible.
SaaS often doesn't solve issues but replaces them - you substitute general engineering knowledge and open-source knowhow with proprietary one, and end up with experts in configuring commercial software - a skill that has very little value on the market where said software is not used, and chains you to a given vendor.
SaaS software, by it's very nature, tends to gets tested tons more than your inhouse software. It also has more devs working on the software. It is almost certainly more stable and can handle more edge cases than anything developed inhouse. It's always a question of scale.
But what you're describing is the narrow but deep vs wide but shallow problem. Most SaaS software is narrow but deep. Their solution is always going to be better than yours. But some SaaS software is wide but shallow, it's meant to fit a wide range of business processes. Its USP is that it does 95% of what you want.
It sounds like you were using a "wide-shallow" SaaS in a "narrow-deep" way, only using a specific part of the functionality. And that's where you hit the problems you saw.
I am speaking from experience. We have a SaaS tool for example to to CI/CD. It's super expensive, has a number of questionable design choices.
It's full of features, half of which either do not work, or do not work as expected, or need some arcane domain knowledge to get them working. These features provide 'user-friendly' abstractions over raw stuff, like authing with various repos, downloading and publishing packages of different formats.
Underlying these tools are probably the same shell scripts and logic that we as devs are already familiar with. So often the exercise when forced to use these things is to get the underlying code to do what we want through this opaque intermediate layer.
Some people have resorted to fragile hacks, while others completely bypassed these proprietary mechanisms, and our build scripts are 'Run build.sh', with the logic being a shell or python script, which does all the requisite stuff.
And just like I mentioned in my prev post, SaaS software in this case might get tested more in general, but due to the sheer complexity it needs to support on the client side, testing every configuration at every client is not feasible.
At least the bugs we make, we can fix.
And while I'm sure some of this narrow-deep kinds of SaaS works well (I've had the pleasure to use Datadog, Tailscale, and some big cloud provider stuff tends to be great as well), that's not all there is that's out there and doesn't cover everything we need.
That's my point, "It's full of features". You said it yourself.
You have bought a shallow but wide SaaS product, one with tons of features that don't get much development or testing individually.
You're then trying to use it like a deep but narrow product and complaining that your complex use case doesn't fit their OK-ish feature.
MS do this in a lot of their products, which is why Slack is much better than Teams, but lots of companies feel Teams is "good enough" and then won't buy Slack.
I'm arguing this is an entirely flawed product category (which might have elements of fraud as well) - things that are easy to get started with, but as your skill level or the requirements complexity increases, you start to see the limitations, and get entangled in the 'ecosystem', so given a sufficiently knowledgeable workforce, you are at a net negative by year 2 or 3 compared to experts having built something bespoke, or going the open-source route.
I'm sure you have encountered the pattern where you write A that calls B that uses C as the underlying platform. You need something in A, and know C can do it, but you have to figure out how you can achieve it through B. For a highly skilled individual(or one armed with AI) , B might have a very different value proposition than one who has to learn stuff from scratch.
Js packages are perfect illustration of these issues - there are tons of browser APIs that are wrapped by easy-to-use 'wrapper' packages, that have unforeseen consequences down the road.
This is true when SaaS is a simple widget for everyone. The problem is that when SaaS becomes a hydra designed to do a million things for a million people, the extra eyeballs aren't helping you, they're creating more error surface.
On top of that, SaaS takes your power away. A bug could be quite small, but if a vendor doesn't bother to fix it, it can still ruin your life for a long time. I've seen small bugs get sandbagged by vendors for months. If you have the source code you can fix problems like these in a day or two, rather than waiting for some nebulous backlog to work down.
My experience with SaaS is that products start out fine, when the people building them are hungry and responsive and the products are slim and well priced. Then they get bloated trying to grow market share, they lose focus and the builders become unresponsive, while increasing prices.
At this point you wish you had just used open source, but now it's even harder to switch because you have to jump through a byzantine data exfiltration process.
> Everything was a little bit fragile in subtle ways.
Maybe write some tests and have great software development practices and most importantly people who care about getting the details right. Honestly there’s no reason for software to be like this is there? I don’t know how much off the shelf ERP software you have used but I wouldn’t exactly describe that as flawless and bug free either!
This is only true if you assume that you are producing the same amount of code as today. Though, AI ultimately will produce more code which will require higher maintenance. Your internal team will need to scale up due to the the amount of code they need to maintain. Your security team will have more work to do as well because they will need to review more code which will require scaling that team as well. Your infrastructure costs will start adding up and if you have any DevOps they will need scaling too.
Soon or later the CTO will be dictating which projects can be vibe coded which ones make sense to buy.
SaaS benefits from network effects - your internal tools don't. So overall SaaS is cheaper.
The reality is that software license costs is a tiny fraction of total business costs. Most of it is salaries. The situation you are describing the kind of dead spiral many companies will get into and that will be their downfall not salvation.
> The reality is that software license costs is a tiny fraction of total business costs
Yes and no. If someone is controlling the SaaS selection, then this is true.
But I've seen startup phase companies with multiple slightly overlapping SaaS subscriptions (Linear + Trello + Asana for example), just because one PM prefers one over the other.
Then people have bought full-ass SaaS costing 50-100€/month for a single task it does.
I'd describe the "Use AI to make bespoke software" as the solution you use to round out the sharp edges in software (and licensing).
The survey SaaS wants extra money to connect to service Y, but their API is free? Fire up Claude and write the connector ourselves. We don't want to build and support a full survey tool, but API glue is fine.
Or someone is doing manual work because vendor A wants their data in format X and vendor B only accepts format Y. Out comes Claude and we create a tool that provides both outputs at the same time. (This was actually written by a copywriter on their spare time, just because they got annoyed with extra busywork. Now it's used by a half-dozen people)
There is no yes and no. This is a fact. Even a small startup of 3-5 people will pay more in terms of salaries than the total license costs they consume. A larger enterprise will will spend 50 to 100 times more on salaries then software license fees.
The reason software licenses are easier to cut by the finance team when things are not going well is because software does not have feelings although we all know that this not making a dent. Ultimately software scales much better than people and if the software is "thinking" it will scale infinitely better.
Building it all in house will only happen for 2 reasons: 1. The problem is so specific that this is the only variable option and the quickest (fear enough). 2. Developers and management do not have real understanding of software costs.
Developers not understanding the real costs should be forgiven because most of them are never in position to make these type of decisions - i.e they are not trained. However a manager / executive not understanding this is sign of lack of experience. You really need to try to build a few medium-sized none essential software systems in-house to get an idea how bad this can get and what a waste of time and money it really is - resources you could have spent elsewhere to effect the bottom the real bottomline.
Also the lines of code that are written do not scale linearly with team sizes. The more code you produce the bigger the problem - even with AI.
Ultimately a company wants to write as few line of code as possible that extract as much value as feasibly possible.
> Soon or later the CTO will be dictating which projects can be vibe coded which ones make sense to buy.
A lot of the SaaS target companies won't even have a CTO
To me AI might have tilted the economic on doing in house a bit but it has been at least a decade or more that I find most enterprise SaaS, in the way they are used 80% of the time, could be recreated with a few developers in house. Instead of 10-20 developers maybe you only need 2-5 with AI, so for most big companies that doesn’t change much. A company that wants to build in house still has to hire a team. And in most non tech industries even if more expensive usually a service is preferred. SaaS was never (only) about costs, developers were already wondering why people would pay for an expensive CRM 10 years ago when it was only basic CRUD.
I work with both enterprise software and in house teams. Each path has its pro and cons. As you put it costly CRM might not be fulfilling its purpose. And the two biggest points in favour of in house are cost and bespoke nature of solution.
Building is only one part. Maintaining and using/running is another.
Onboarding for both technical and functional teams takes longer as the ERP is different from other company. Feature creep is an issue. After all who can say no to more bespoke features. Maybe roll CRM, Reporting and Analytics into one. Maintenance costs and priorities now become more important.
We have also explored AI agents in this area. People specific tasks are great use cases. Create mock up and wireframes? AI can do well and you still have human in the loop. Enterprise level tasks like say book closing for late company ERP? AI makes lot of mistakes.
>> I’m currently working on an in house ERP and inventory system for a specific kind of business
this means if I sell it to your business for the price of < your salary - you will get fired and business will use my version.
Why? because my will always be better as 10 people work on it vs you alone.
Internal versions will never be better or cheaper than saas (unless you are doing some tiny and very specific automation).
They can be better than current solution - but only a matter of time when someone makes a saas equal and better to what you do internally.
Sure almost anything will be better and cheaper that hubspot.
But with AI smaller CRMs that are hyper focused on businesses like yours will start popping up and eating its market.
Anything bigger than a toy project will always be cheaper/better to buy.
Interesting application. Can you share more about your stack and how you are approaching that build?
Its not that people will build their own saas, its that competitors will pop up at a rapid pace
You've just described the magic of spreadsheets.
I agree about boutique software, but see the development still being external -
To attempt to summarize the debate, there seems to be three prevailing schools of thought:
1. Status Quo + AI. SaaS companies will adopt AI and not lose share. Everyone keeps paying for the same SaaS plus a few bells and whistles. This seems unlikely given AI makes it dramatically cheaper to build and maintain SaaS. Incumbents will save on COGS, but have to cut their pricing (which is a hard sell to investors in the short term).
2. SaaS gets eaten by internal development (per OP). Unlikely in short/medium term (as most commenters highlight). See: complete cloud adoption will take 30+ years (shows that even obviously positive ROI development often does not happen). This view reminds me a bit of the (in)famous DropBox HN comment(1) - the average HN commenter is 100x more minded to hack and maintain their own tool than the market.
benzible (commenter) elsewhere said this well - "The bottleneck is still knowing what to build, not building. A lot of the value in our product is in decisions users don't even know we made for them. Domain expertise + tight feedback loop with users can't be replicated by an internal developer in an afternoon."
This same logic explains why external boutique beats internal builds --
3. AI helps boutique-software flourish because it changes vendor economics (not buyer economics). Whereas previously an ERP for a specific niche industry (e.g. wealth managers who only work with Canadian / US cross-border clients) would have had to make do with a non-specific ERP, there will now be a custom solution for them. Before AI, the $20MM TAM for this product would have made it a non-starter for VC backed startups. But now, a two person team can build and maintain a product that previously took ten devs. Distribution becomes the bottleneck.
This trend has been ongoing for a while -- Toast, Procore, Veeva -- AI just accelerates it.
If I had to guess, I expect some combination of all three - some incumbents will adapt well, cut pricing, and expand their offering. Some customers will move development in house (e.g. I have already seen several large private equity firms creating their own internal AI tooling teams rather than pay for expensive external vendors). And there will be a major flourishing of boutique tools.
(1) https://news.ycombinator.com/item?id=9224
Author here, really good comment and I agree with you.
What _has_ surprised me though is just how many companies are (or are considering) building 'internal' tooling to replace SaaS they are not happy with. These are not the classic HN types whatsoever. I think when non technical people get to play with AI software dev they go 'wow so why can't we do everything like this'.
I think your point 3 is really interesting too.
But yes the point of my article (hopefully) wasn't that SaaS is overnight dead, but some thin/lower "quality" products are potentially in real trouble.
People will still buy and use expertly designed products that are really nice to use. But a lot of b2b SaaS is not that, its a slow clunky mess that wants to make you scream!
Thanks!
I agree - it is surprising how many are looking at doing in house.
I think what they miss (and I say this as someone who spent the early part of his career outside of tech) is an understanding of what goes into maintaining software products - and this ignorance will be short lived. I was honestly shocked how complex it was to build and maintain my first web app. So business types (like I was) who are used to 'maintaining' an excel spreadsheet and powerpoint deck they update every quarter may think of SaaS like a software license they can build once and use forever. They have no appreciation of the depth of challenges that come with maintaining anything in production.
My working model is that of no-code - many non-tech types experimented with bubble etc, but quickly realize that tech products are far deeper than the (heavily curated) surface level experience that the user has. It is not like an excel model where the UI is codebase. I expect vibe-coders will find the same thing.
I have on several occasions built my own versions of tools, only to cave and buy a $99 a year off the shelf version because the maintenance time isn't worth it. Non-tech folks have no idea of the depth of pain of maintaining any system.
They will learn. Will be interesting to see how it plays out.
I like this thoughtful and nuanced response, I think you could be right. Makes me wonder if choosing an extremely boring niche and just making several million dollars could be a good move right now.
Thank you!
Quite honestly, this is exactly what I am currently doing - identified a market with probably $50mm global TAM. Bootstrapping with first design partners currently.
One thing I didn't mention is that there are often a few sleepy legacy SaaS players (often public) in these niche markets who don't have the chops to add AI to their product and may be a good takeout / exit down the line. Won't be for billions, but if you bootstrap, that doesn't really matter.
Jamin Ball had a better take on Clouded Judgement https://cloudedjudgement.substack.com/p/clouded-judgement-12... "Long Live Systems of Record"
This is the right take
Also maintaining a software is pain
Also for perpetually small companies, its now easy to build simple scripts to be achieve some productivity gains.
Yeah I think that is a much more accurate take on the same subject.
This was a good read.
Maybe someday we'll see job postings for maintaining these in-house SaaS tools. And someday someday, we'll see these in-house SaaS tools being consolidated as its own separate product. Wait what.
Hey lets hope maybe people will open source the product too :D
and around and around we'll go again!
The where this doesn’t work section is chefs kiss
- anything that requires very high uptime
-very high volume systems and data lakes
-software with significant network effects
-companies that have proprietary datasets
-regulation and compliance is still very important
Earlier this year I thought that rare proprietary knowledge and IP was a safe haven from AI, since LLMs can only scrub public data.
Then it dawned on me how many companies are deeply integrating Copilot into their everyday workflows. It's the perfect Trojan Horse.
providers' ToS explicitly states whether or not any data provided is used for training purposes. the usual that i've seen is that while they retain the right to use the data on free tiers, it's almost never the case for paid tiers
Right, so totally cool to ignore the law but our TOS is a binding contract.
Yes, they can be sued for breach of contract. And it’s not a regular ToS but a signed MSA and other legally binding documents.
the license on my open source code is a contract, and they ignored that
if they can get away with it (say by claiming it's "fair use"), they'll ignore corporate ones too
If I were to go out on a limb, those companies spend more on tech companies than you and they have larger legal teams than you. That is a carrot and a stick for AI companies to follow the contract.
no, it's not an incentive to follow the contract
it's an incentive to pretend as if you're following the contract, which is not the same thing
Where are they ignoring the law?
https://www.reuters.com/business/environment/musks-xai-opera...
Thats an allegation. Doesnt an allegation need to be tested?
people that say this tend to have a misinterpretation of copyright, and use all the court cases brought by large rights holders as validation
despite all 3 branches of the government disagreeing with them over and over again
[flagged]
I bet companies are circumventing this in a way that allows them to derive almost all the benefit from your data, yet makes it very hard to build a case against them.
For example, in RL, you have a train set, and a test set, which the model never sees, but is used to validate it - why not put proprietary data in the test set?
I'm pretty sure 99% of ML engineers would say this would constitute training on your data, but this is an argument you could drag out in courts forever.
Or alternatively - it's easier to ask for forgiveness than permission.
I've recently had an apocalyptic vision, that one day we'll wake up, an find that AI companies have produced an AI copy of every piece of software in existence - AI Windows, AI Office, AI Photoshop etc.
Given the conduct we've seen to date, I'd trust them to follow the letter - but not the spirit - of IP law.
There may very well be clever techniques that don't require directly training on the users' data. Perhaps generating a parallel paraphrased corpus as they serve user queries - one which they CAN train on legally.
The amount of value unlocked by stealing practically ~everyone's lunch makes me not want to put that past anyone who's capable of implementing such a technology.
it is amazing in almost 2026 there is anyone believing this… amazing
I wonder how much wiggle there is for collect now (to provide service, context history, etc), then later anonymise (some how, to some level) and then train on it?
Also I wonder if the ToS covers "queries & interaction" vs "uploaded data" - I could imagine some tricky language in there that says we wont use your word document, but we may at some time use the queries you put against it, not as raw corpus but as a second layer examining what tools/workflows to expand/exploit.
“We don’t train on your data” doesn’t exclude metadata, training on derived datasets via some anonymisation process, etc.
There’s a range of ways to lie by omission, here, and the major players have established a reputation for being willing to take an expansive view of their legal rights.
Ironically (for you), copilot is the one provider that is doing a good job of provably NOT training on user data. The rest are not up to speed on that compliance angle, so many companies ban them (of course, people still use them).
Do you have a source for this?
There are claims all through this thread that “AI companies” are probably doing bad things with enterprise customer data but nobody has provided a single source for the claim.
This has been a theme on HN. There was a thread a few weeks back where someone confidently claimed up and down the thread that Gemini’s terms of service allowed them to train on your company’s customer data, even though 30 seconds of searching leads to the exact docs that say otherwise. There is a lot of hearsay being spread as fact, but nobody actually linking to ToS or citing sections they’re talking about.
Sources aren't hard to find[1]. But getting software developers to look outside their idiot-savant caves and not dismiss the entire legal system as "unrealistic", is much harder to accomplish.
[1] - https://www.microsoft.com/en-us/trust-center/privacy/data-ma...
Even if they're were doing this (I highly doubt it) so much would be lost to distillation I'm not convinced there would be much that actually got in, apart from perhaps internal codenames or whatever which will be obvious.
Well, perhaps this is naive of me from the perspective of not fully understanding the training process. However, at some point, with all available training data having been exhausted, gains with synthetic data exhausted, and a large pool of publicly available AI generated code, at what point is it 'smart' to scrape codebases from what you identify as high quality code based, clean it up to remove identifiers, and use that for training a smaller model?
What kind of rare proprietary knowledge?
It could be a wide range of things depending on your field: highly particular materials, knowledge or processes that give your products or services a particular edge, and which a company has often incurred high R&D costs to discover.
Many businesses simply couldn't afford to operate without such an edge.
Using an LLM on data does not ingest that data into the training corpus. LLMs don’t “learn” from the information they operate on, contrary to what a lot of people assume.
None of the mainstream paid services ingest operating data into their training sets. You will find a lot of conspiracy theories claiming that companies are saying one thing but secretly stealing your data, of course.
Companies have already shifting from not using customer data to giving them an option to opt out ex:
“How can I control whether my data is used for model training?
If you are logged into Copilot with a Microsoft Account or other third-party authentication, you can control whether your conversations are used for training the generative AI models used in Copilot. Opting out will exclude your past, present, and future conversations from being used for training these AI models, unless you choose to opt back in. If you opt out, that change will be reflected throughout our systems within 30 days.” https://support.microsoft.com/en-us/topic/privacy-faq-for-mi...
At this point suggesting it has never and will her happen is wildly optimistic.
An enterprise Copilot contract will have already decided this for the organization.
That possibility in no way address the underlying concern here.
30 days to opt out? That's skeezy as fuck.
> LLMs don’t “learn” from the information they operate on, contrary to what a lot of people assume.
Nothing is really preventing this though. AI companies have already proven they will ignore copyright and any other legal nuisance so they can train models.
They're already using synthetic data generated by LLMs to further train LLMs. Of course they will not hesitate to feed "anonymized" data generated by user interactions. Who's going to stop them? Or even prove that it's happening. These companies have already been allowed to violate copyright and privacy on a historic global scale.
How should they dinstinguish between real and fake data? It would be far to easy to pollute their models with nonesense.
I have no doubt that Microsoft has already classified the nature of my work and quality of my code. Of course it's probably "anonymized". But there's no doubt in my mind that they are watching everything you give them access to, make no mistake.
I mean is it really ignoring copyright when copyright doesn't limit them in anyway on training?
Tell that to all the people suing them for using their copyrighted work. In some cases the data was even pirated.
> Nothing is really preventing this though
The enterprise user agreement is preventing this.
Suggesting that AI companies will uniquely ignore the law or contracts is conspiracy theory thinking.
It already happened.
"Meta Secretly Trained Its AI on a Notorious Piracy Database, Newly Unredacted Court Docs Reveal"
https://www.wired.com/story/new-documents-unredacted-meta-co...
They even admitted to using copyrighted material.
"‘Impossible’ to create AI tools like ChatGPT without copyrighted material, OpenAI says"
https://www.theguardian.com/technology/2024/jan/08/ai-tools-...
Though the porn they copied was just for personal use, because clearly that's an important perk of being employed there:
https://www.vice.com/en/article/meta-says-the-2400-adult-mov...
Information about the way we interact with the data (RLHF) can be used to refine agent behaviour.
While this isn't used specifically for LLM training, it can involve aggregating insights from customer behaviour.
That’s a training step. It requires explicitly collecting the data and using it in the training process.
Merely using an LLM for inference does not train it on the prompts and data, as many incorrectly assume. There is a surprising lack of understanding of this separation even on technical forums like HN.
That's definitely a fair point.
However, let's say I record human interactions with my app; for example when a user accepts or rejects an AI sythesised answer.
This data can be used by me, to influence the behaviour of an LLM via RAG or by altering application behaviour.
It's not going to change the weighting of the model, but it would influence its behaviour.
They are not directly ingesting the data into their trainning sets but they are in most cases collecting it and will be using it to train future models.
Do you have any source for this at all?
Its stated in the private policy.
If they weren't, then why would enterprise level subscriptions include specific terms stating that they don't train on user provided data? There's no reason to believe that they don't, and if they don't now then there's no reason to believe that they won't later whenever it suits them.
> then why would enterprise level subscriptions include specific terms stating that they don't train on user provided data?
What? That’s literally my point: Enterprise agreements aren’t training on the data of their enterprise customers like the parent commenter claimed.
Just read the ToS of the LLM products please
This is so naive. The ToS permits paraphrasing of user conversations, by not excluding it, and then training on THAT. You’d never be able to definitively connected paraphrased data to yours, especially if they only train on paraphrased data that covers frequent, as opposed to rare, topics.
Do it have a citation for this?
“Hey DoctorPangloss, how can we train on user data without training on user data?”
“You can use an LLM to paraphrase the incoming requests and save that. Never save the verbatim request. If they ask for all the request data we have, we tell them the truth, we don’t have it. If they ask for paraphrased data, we’d have no way of correlating it to their requests.”
“And what would you say, is this a 3 or a 5 or…”
Everything obvious happens. Look closely at the PII management agreements. Btw OpenAI won’t even sign them because they’re not sure if paraphrasing “counts.” Google will.
I have. Have you? Can you quote the sections you’re talking about?
https://www.anthropic.com/news/updates-to-our-consumer-terms
"We will train new models using data from Free, Pro, and Max accounts when this setting is on (including when you use Claude Code from these accounts)."
> You will find a lot of conspiracy theories claiming that companies are saying one thing but secretly stealing your data, of course.
It's not really a conspiracy when we have multiple examples of high profile companies doing exactly this. And it keeps happening. Granted I'm unaware of cases of this occuring currently with professional AI services but it's basic security 101 that you should never let anything even have the remote opportunity to ingest data unless you don't care about the data.
> never let anything even have the remote opportunity to ingest data unless you don't care about the data
This is objectively untrue? Giants swaths of enterprise software is based on establishing trust with approved vendors and systems.
> It's not really a conspiracy when we have multiple examples of high profile companies doing exactly this.
Do you have any citations or sources for this at all?
To be pedantic, it is still a conspiracy, just no longer a theory.
To be pedantic, a theory that has been proven correct is still a theory, right?
Wrong, buddy.
Many of the top AI services use human feedback to continuously apply "reinforcement learning" after the initial deployment of a pre-trained model.
https://en.wikipedia.org/wiki/Reinforcement_learning_from_hu...
RLHF is a training step.
Inference (what happens when you use an LLM as a customer) is separate from training.
Inference and training are separate processes. Using an LLM doesn’t train it. That’s not what RLHF means.
I am aware, I've trained my own models. You're being obtuse.
The big companies - take Midjourney, or OpenAI, for example - take the feedback that is generated by users, and then apply it as part of the RLHF pass on the next model release, which happens every few months. That's why they have the terms in their TOS that allow them to do that.
maybe prompts are enough to infer the rest ?
[flagged]
>Ah yes, blindly trusting the corpo fascists that stole the entire creative output of humanity to stop now.
Stealing implies the thing is gone, no longer accessible to the owner.
People aren't protected from copying in the same way. There are lots of valid exclusions, and building new non competing tools is a very common exclusion.
The big issue with the OpenAI case, is that they didn't pay for the books. Scanning them and using them for training is very much likely to be protected. Similar case with the old Nintendo bootloader.
The "Corpo Fascists" are buoyed by your support for the IP laws that have thus far supported them. If anything, to be less "Corpo Fascist" we would want more people to have more access to more data. Mankind collectively owns the creative output of Humanity, and should be able to use it to make derivative works.
> Stealing implies the thing is gone, no longer accessible to the owner.
Isn't this a little simplistic?
If the value of something lies in its scarcity, then making it widely available has robbed the owner of a scarcity value which cannot be retrieved.
A win for consumers, perhaps, but a loss for the owner nonetheless.
No calling every possible loss due to another persons actions "Stealing" is simplistic. We have terms for all these things, like "intellectual property infringement".
Trying to group (Thing I dont like) with (Thing everyone doesnt like) is an old semantic trick that needs to be abolished. Taxonomy is good, if your arguments are good, you dont need emotively charged imprecise language.
I literally reused the definition of stealing you gave in the post above.
> Stealing implies the thing is gone, no longer accessible to the owner.
You know a position is indefensible when you equivocation fallacy this hard.
> The "Corpo Fascists" are buoyed by your support for the IP laws
You know a position is indefensible when you strawman this hard.
> If anything, to be less "Corpo Fascist" we would want more people to have more access to more data. Mankind collectively owns the creative output of Humanity, and should be able to use it to make derivative works.
Sounds about right to me, but why you would state that when defending slop slingers is enough to give me whiplash.
> Scanning them and using them for training is very much likely to be protected.
Where can I find these totally legal, free, and open datasets all of these slop slingers are trained on?
>You know a position is indefensible when you equivocation fallacy this hard.
No its quite defensible. And if that was equivocation, you can simply outline that you didn't mean to invoke the specific definition of stealing, but were just using it for its emotive value.
>You know a position is indefensible when you strawman this hard.
Its accurate. No one wants thes LLM guys stopped more than other big fascistic corporations, plenty of oppositional noise out there for you to educate yourself with.
>Sounds about right to me, but why you would state that when defending slop slingers is enough to give me whiplash.
Cool, so if you agree all data should usable to create derivative works then I don't see what your complaint is.
>Where can I find these totally legal, free, and open datasets all of these slop slingers are trained on?
You invoked "strawman" and then hit me with this combo strawman/non sequitur? Cool move <1 day old account, really adds to your 0 credibility.
I literally pointed out they should have to pay the same access fee as anyone else for the data, but once obtained, should be able to use it any way. Reading the comment explains the comment.
Unless, charitably, you are suggesting that if a company is legally able to purchase content, and use it as training data, that somehow compels them to release that data for free themselves?
Weird take if true.
This resonates strongly, especially the shift in the build vs buy calculus happening almost invisibly. What feels under-discussed is that agents are not just reducing the cost of building software — they are collapsing the coordination and abstraction costs that SaaS historically justified. One emerging pattern I’m seeing is teams moving toward agent-orchestrated internal tooling rather than traditional “one-off” internal apps. Instead of rebuilding entire SaaS products, they compose narrow, task-specific agents that sit directly on top of their own data and workflows. This avoids both feature bloat and long-term roadmap dependency while keeping maintenance tractable. Platforms like Coldi AI, for instance, point toward this middle ground: not “replace all SaaS,” but replace the parts that are really just opinionated CRUD, dashboards, or glue code with agents that can evolve alongside the organization. That feels like the real threat surface for SaaS — not total displacement, but systematic erosion of NRR as customers internalize more of the value chain.
It was common in the early 2000s for big companies to have large internal IT teams to build "line of business" apps. Then SaaS came along and delivered LoB apps for a fraction of the price and with a monthly subscription.
Looks like we're headed back to the internal IT days of building customized LoB apps.
Or perhaps there will arise a new kind of external service provider that delivers customized SaaS services to those same users, using AI. There's no reason the work has to go back to the internal IT people who were fired long ago.
Note that the author does not mention a single specific SaaS subscription he’s cancelled or seen a team cancel.
The only named product was Retool.
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 more than 2 hours to put those together. We didn't renew our TeamRetro
> It took me no more than 2 hours to put those together. We didn't renew our TeamRetro
Okay, so two hours with an LLM vs maybe 2.5 days without an LLM in the best-case scenario (i.e. LLMs gave you a 10x boost. I would expect it to be less than that though, like maybe a 2x boost) - it sounds like it was always pretty cheap to replace the SaaS, but the business didn't do it.
TBH, the arguments were never "It would take too long to do ourselves", it was always "but then we'd have to maintain it ourselves".
The place I am consulting at now just moved (i.e. a month ago) from their in-house built ticketing system ($0/m as it had not needed maintenance for over a year) to Jira (~$2k/m).
In this specific case, it was literally 0 hours to avoid paying the SaaS, and they still moved, because they wanted some modern features (billing for time on support calls, etc) and figured that rather than update their in-house system to add support hours costing (a day, at most) they may as well move to a system that already had it.
(Joke's on them though - the Jira solution for support hours costing is not near the level of granularity they need, even with multiple paid plugins).
Once again, companies aren't using SaaS because it's cheaper or quicker; they could already quickly replace their SaaS with in-house.
>.e. LLMs gave you a 10x boost. I would expect it to be less than that though, like maybe a 2x boost
I'm not a frontend guy, I'm an operations guy that sometimes does some backends. So it's likely a solid 2.5 days for me to build the pair of these, probably more I haven't touched Javascript in over a decade.
> I'm not a frontend guy, I'm an operations guy that sometimes does some backends. So it's likely a solid 2.5 days for me to build the pair of these, probably more I haven't touched Javascript in over a decade.
Right, understood and agreed, but this was not about you and your specific skills or lack thereof; your anecdote was in support of an argument that companies would stop their SaaS because LLMs enable them to build in house.
That was your argument, right?
So in the absence of LLMs, if the company wanted to stop paying for the SaaS, would they have chosen you to do the replacement, or someone who had recent experience in the tech?
Look, we are interested in comparing the time taken to replace the SaaS with an LLM, and the time taken to replace the SaaS without LLM assistance.
That's really the only two scenarios under discussion, so lets explore those exhaustively:
1. Without LLMs: In the worst case scenario, the company had to pay for 2.5 days of employee time with the best case being 1 day of employee time. Lets go with something in-between like 1.5 days of dev time.
2. With LLMs: The company pays for 0.5 days of employee time (includes the overhead of token cost/subscription).
The difference between the only two scenarios that we have is literally a single day of employee costs!
I am skeptical that the company failed to leave the SaaS earlier because they didn't want to eat the cost of a 1.5 paid days for an employee, but a difference of a single day of cost was enough to tip the scales.
>That was your argument, right?
I wasn't intending to make an argument, I was specifically replying to:
>does not mention a single specific SaaS subscription he’s cancelled
I was imagining it could start a thread of examples where it's happened.
>would they have chosen you to do the replacement, or someone who had recent experience in the tech?
I get what you're saying, but those aren't the only two options; they very likely would have chosen neither of those options. The resources we had available was an ops guy who is pretty handy with the LLMs.
I get the point you're making, I really do. My counterpoint is that there are some SaaSes out there that people can build replacements for by using the LLMs at no incremental cost.
>I am skeptical that the company failed to leave the SaaS earlier because they didn't want to eat the cost of a 1.5 paid days for an employee
Sure, I'd be skeptical about it when put that way as well. That's not how it played out however: We were having a retro and the guy running it said that our subscription was expiring the end of the month and wanted discussion about whether we wanted to purchase it for another year. 2 weeks later, before our next retro, I threw a prompt at Claude Code and asked a couple people to try out the result, incorporated their feedback and we ran the retro on it. We aren't planning to renew.
This was not something "the company" had a big discussion about; my boss made an offhand comment about it, and I did it as a side project while I was doing something else.
How is teamretro a product to begin with? I feel like these SaaS’s exploded like js libraries.
It is fine. We already had a retro process we were using, and teamretro didn't really enable us to change or improve our process so much as just continue doing our existing process. It is a solid product, but honestly we just used a google sheet prior to it and that worked fine as well.
Or just don’t do retro and save even more time and money!
If you're a typical software engineer, that time probably cost your company more than $240.
I didn't look at the product. But $240/year is nothing for an org. Plus not only just the time to make it. What about the time fixing bugs? hosting costs? backups? I'm sure there will be products that can be replaced (possibly this one), but I'm not convinced the death of SaaS is here yet.
Good point! For me the only change that happened so far (because the agentic product was better) was switching from JetBrains to Cursor. I'm sure this will happen with more products I use in the future
I often give the follow analogy which I think is a good proxy to what is going on.
Spreadsheets! They are everywhere. In fact, they are so abundant these days that that many are spawned for a quick job and immediately discarded. In fact, the cost of having these spreadsheets is practically zero so in many cases one may find themselves having hundreds if not thousands of them sitting around with no indication to ever being deleted. Spreadsheets are also personal and annoying especially when forced upon you (since you did not make it yourself). Spreadsheets are also programming for non-programmers.
These new vibe-coded tools are essentially the new spreadsheets. They are useful,... for 5 minutes. They are also easily forgettable. They are also personal (for the person who made them) and hated (by everyone else). I have no doubt in my mind that organisation will start using more and more of these new types of software to automate repetitive tasks, improve existing processes and so on but ultimately, apart from perhaps just a few, none will replace existing, purpose-built systems.
Ultimately you can make your own pretty dashboard that nobody else will see or use because when the cost of production is so low your users will want to create their own version because they would think they could do better.
After all, how hard is to prompt harder then the previous person?
Also, do you really think that SaaS companies are not deploying AI themselves? It is practically an arms race: the non-expert plus some AI vs 10 specialist developers plus their AIs doing this all day long.
Who is going to have the upper-hand?
There are SO MANY Excel sheets someone automated a decade+ ago still used in essential parts of the government and big corporations.
Nobody knows how they work, very few have the skills or time to edit them or check them. People just use them for the convenience.
The magic sauce of Excel is that it's free an scriptable (programmable even). If you want a SaaS, you need to involve IT, Legal, your supervisors and it's a whole-ass thing of contracts and shit.
Excel? It's just there.
There are so many stories and anecdotes of people being in stupid data entry jobs, getting bored and finding out their whole job can be automated with a single smartly done Excel sheet. Then they press F9 once per day and do something else for the rest of the time =)
And just because, my main gripe about Excel: there are no unit tests or validators for it. There's no easy way to programmatically confirm that Cell C5 has the same formula as C875
If (when?) people start AI-coding the things they used to use Excel for, we might get some actual tests and validation to confirm what the code is supposed to actually happens.
I mostly agree. What it does do is raise the bar for a viable SaaS, and seeing some examples elsewhere in this thread, that’s a good thing.
I’d also add a number of the vibe tools tech adjacent people on my team have made are used and liked by the team. Even engineering likes them because it frees up their time to work on customer facing things.
AI coding IS SaaS. Claude Code is a subscription service I pay to create the exact, niche, I need you to build a form that submits a blog post to Wordpress here’s my api key, here’s the word doc format it comes in, I’ll paste it in the chat and you make a paste from word button so I don’t have to manually enter the form and it works first try. That is the definition of software as a service. And it’s mine and it’s exactly what I need. Tomorrow I’ll need something else…
You can already hire Indians to make your own HR system. People still choose SAAS, because the system already works.
You do not want to have to plan out a system with 800 unique requirements yourself. It takes a ridiculous amount of work, and you are then stuck maintaining it.
It’s never been about the difficulty of programming, it’s been about the pain of designing and maintaining.
This is why I started working on an open source, generic protobuf sqlite ORM + CRUD server (with search/filtering) + type/service registry + grpc mesh, recently: https://github.com/accretional/collector Note: collector's docs are mostly from LLMs, partially because it's more of a framework for tool-calling LLMs than humans
Then this project lets you generate static sites from svelte components (matches protobuf structures) and markdown (documentation) and global template variables: https://github.com/accretional/statue
A lot of the SaaS ecosystem actually has rather simple domain logic and oftentimes doesn't even model data very well, or at least not in a way that matches their clients/users mental models or application logic. A lot of the value is in integrations, or the data/scaling, or the marketing and developer experience, or some kind of expertise in actually properly providing a simple interface to a complex solution.
So why not just create a compact universal representation of that? Because it's not so big a leap to go beyond eating SaaS to eating integrations, migration costs/bad moats, and the marketing/documentation/wrapper.
I’m glad the author of the article mentions a lot of the limitations of this idea, but taking the final sentence:
> But my key takeaway would be that if your product is just a SQL wrapper on a billing system, you now have thousands of competitors: engineers at your customers with a spare Friday afternoon with an agent.
I think it’s pertinent to point out that a lot of SaaS products are aimed at businesses and individuals who don’t have engineers at all.
AI agents aren’t going to disrupt the SaaS market for software intended for businesses like small business retail where the owners and staff have minimal technical knowledge and zero extra time.
I also think that some SaaS products are so cheap that about an hour of effort is too much. Is it worth a month of effort to vibecode a Dropbox alternative? Even some pretty complicated software that is untouchable by agents and engineers’ side projects like the Microsoft 365 suite and Jira are priced at under $20/month/user.
On the other hand, some entrenched solutions that aren’t all that complicated could be finding themselves with new, smaller competitors.
The problem is that we are still talking only about software. If that is the only thing agents can do then they are just better IDE’s for programmers. This would be an enabler for building stuff faster. Think about it, there is already a huge market for SAAS, but most of the companies have contracts in place, so what we’ll have is just more competition which will drive prices down. Companies will not start changing internal tools, refactoring is a bad investment in general, if you choose that over some new features or products it signals larger issues, so nobody will replace existing cheap stuff that is working.
Going back to the beginning, I think we just lack good tools for other cases where agents could be used. Copilot is not great, chatgpt alone lacks some features to use it for business as is. I think what will happen is that we will see a lot more new tooling pop up that relies on agents in niche markets which will just amplify the power users. It will be another category of SAAS the companies will adopt.
Teams I've worked in choose SaaS offerings based on how little expertise we have in the given domain, and the price (which includes actual monies going to the SaaS, but also the expected time of integrating with them and an expectation cost of migrating away from them).
Experienced developers have the humility to understand that there are always roadbumps and risks in building a system in a domain we do not understand, and therefore paying another company with expertise can often be worth it. Obviously some SaaS companies are better than others, which is why there is an evaluation process.
It does not surprise me (unfortunately) that proponents of using AI agents for everything minimize the value of actual lived experience in working in a given domain.
Ah, yes. If the thing that is false is true, all kinds of interesting things happen! For example, if I became the queen of France, I could make people do silly dances! That is an interesting hypothesis that could play out in my imaginary world!
SaaS maintenance isn't about upgrading packages, it's about accountability and a point of contact when something breaks along with SLAs and contractual obligations. It isn't because building a kanban board app is hard. Someone else deals with provisioning, alerts, compliance, etc. and they are a real human who cannot hallucinate that the issue has been fixed when it hasn't. Depending on the contract and how it is breached, you can potentially take them to court and sue them to recover money lost as a result of their malpractice. None of that applies to a neural network that misreads the alert, does something completely wrong, then concludes the issue is fixed the way the latest models constantly do when I use them.
There are already plenty of SaaS that offer open source version as a way to push to the cloud and charge for hosting, maintenance, support and some extra features. In that way, a working code have already been commoditized and those companies didn't disappear.
I was looking for this comment (I was going to say the same) - I'm mostly on the backend services and infra side, and I have the option to host a lot of open-source tooling as opposed to paying for a service. I have to weigh up my options when deciding what to do, but a lot comes down to how much time I have and how much I'm willing to waste in time & hosting costs to keep the thing running. Also, do I need support, and ensure uptime and SLAs etc. Or what if I'm on holidays. I'm sure there are other things I'm not thinking of right now.
This is what I don't get with a lot of the AI based saas projects - what is your value add? If you can build it with AI then (in theory) your customer can also build it with ai, so why do they need you? In the SaaS world you don't because the cost of development and maintenance just doesn't scale well, but if you're 99% a wrapper around an AI, your 'business' feels easily replicable to me.
But that does leave a weird gap where SaaSes that took a lot of time to make but can now be handled by an Ai won't survive either. If the business stays hand-coded it costs too much to be viable, if it moves to Ai it looses any advantage over doing it youself.
I dont think any opinion right now is going to be definitive. This is like mixing paint, the edges are still white, while the centre is colored.
What Iam seeing is that customers are delaying purchases of large expensive software. Prime example; SAP. ECC migrations to SaaS model RISE/GROW-PublicCloud are stalling, same with onprem S4 to RISE. I see a whole bunch of my customers instead go with retaining the core but modernize surround apps with intelligent custom apps without feature bloat. For now, SAP/oracle/whatever remains the system of record, the edges are going away. I guess the same is likely happening in other spaces.
This change is coming. Definitely. The current moats around SaaS will fall and the alternate ecosystem might not have moats at all.
There is a significant risk of uncertainty in all of this, the most damaging aspect really. If AI improves, and it is threatening to, then growth in SaaS may decline to a point where investing in it needs to be reconsidered.
The problem is, nobody knows how much and how fast AI will improve or how much it will cost if it does.
That uncertainty alone is very problematic and I think is being underestimated in terms of its impact on everything it can potentially touch.
For now though, I've seen a wall form in benchmarks like swe-rebench and swebench pro. Greenfield is expanding, but maintenance is still a problem.
I think AI needs to get much better at maintenance before serious companies can choose build over buy for anything but the most trivial apps.
> If I want an internal dashboard, I don't even think that Retool or similar would make it easier. I just build the dashboard
Oh, child.... building is easy. Coordinating maintenance of the tool across a non-technical team is hell.
Indeed, wisdom is being able to see the lifecycle like a time knife and making favorable decisions based on past experiences (ie getting the most value from what may need to be built and operated for its lifetime). Writing code is easy, managing a living codebase with ever changing business requirements and stakeholders is hard.
Exactly.
Corporations think in terms of risk.
Second only to providing a useful function, a successful SaaS app will have been built to mitigate risk well.
It's not going to be easy to meet these requirements without prior knowledge and experience.
Many SaaS are not products, but 1-2 features. And an LLM can generate a single-purpose script to replace that one feature you're using. Opus 4.5 does that very well.
As for Retool, I see the several waves of low/no-code products, the current one being LLMs, as repeated attempts to get non technical idea-guys to build their ideas. Where they all fail, and this is fundamental to the problem they're trying to solve, is that idea-guys' ideas crack when meeting reality. And neither Retool nor LLM fix that.
> is that idea-guys' ideas crack when meeting reality.
This is definitely the hardest nut to crack. I worked on a product a while ago that needed to track maintenance periods on equipment quite carefully and then use that to filter data to provide insights about how it was performing. The 'user story' was light on detail. As we got into it, there were tons of questions about how to deal with source data that was often inconsistent or patchy, time zones became an issue because much of the data we received wasn't matched correctly to their local time (customers fault not ours) and our ideas guy just couldn't deal with it - "make it work" - when ultimately they were business questions that needed answering, not just pure software tasks. AI is so sycophantic it'd just go off and write something.
I think that there have always been a ton of SaaS things that are basically circular - startup company paying silly amounts per month to another startup company. I think the market for these things will drop as part of AI, but I think that was always going to be the case with higher interest rates as investors questioned the revenue/spend balance.
When it comes to SaaS that's industry specific, I just don't see it'll be that much of a change any time soon. I've worked heavily in the engineering industry and the security requirements that get put upon anything are nuts. It is difficult to enter this market, ISO compliance is important, even being in the cloud is a barrier for some customers, and often the type that you have no choice but to contract with if you want to make a profit because of their outsized importance in the market.
When I speak to customers, they actually quite often have tried to build something themselves. Usually it's been an intern or grad trying to make their life easier. Often it's spreadsheet based, but some go as far as knocking up little Python web apps. In one company I interned in they had a shadow PHP app. They often have a small 'data science' team that has struggled to get access to the data they need. While they can often get something that does the barebones of the tasks, and can do it well, where they fall down is that they're vulnerable to security issues and can't navigate their internal company politics to get permission to host things in the cloud and make their life easy, plus they don't have the experience to know what's good practice. I don't see AI changing things that much in that.
I'm building a vibe-coding platform that helps with building internal apps and dashboards, and this is exactly what I have seen with some of our clients.
A couple of them mentioned that they plan to cancel subscriptions totaling more than $100k/year for the apps they will replace with that SaaS. According to them, they have many subscriptions they keep only because of one feature. Another issue is that their workflows become a real mess when they need to copy and paste data into multiple tabs. Custom-built internal tools seem like an obvious solution. Those who migrate to custom-built tools, however, will face the challenge of orchestrating their lifecycle and creating a consistent deployment workflow, but this is one of the challenges we are trying to solve at UI Bakery.
In my understanding, SaaS products that provide customers access to proprietary data are in a much better position than other SaaS platforms. HubSpot’s acquisition of Clearbit a couple of years ago now makes even more sense because it will help them retain some of their clients.
> I'm starting to see is people really questioning renewal quotes from larger "enterprise" SaaS companies
This practice predates even SaaS.
I read this article expecting to see a specific SaaS that was at risk, and the most I saw was "dashboards." (Which: dashboards frequently aggregate data, while the ongoing work of collection/maintenance/etc. is done by more complex applications.)
The thesis seems to be that companies can use coding agents to build one-off internal versions of SaaS apps like e.g. Workday or Salesforce or Slack or Jira or MixPanel or HubSpot. Which, if one could make such a thing for free and maintain it for free, why not?
Fortunately/unfortunately depending on where you sit, magical thinking isn't going to get Claude Code to build Workday, regardless of the quality of your AGENTS.md. Sometimes I wonder if the people who write these takes have spent any real time using Claude Code. It's good, but please be realistic.
Author here. What I'm seeing in particular is CRM/ERP solutions at risk. I know of two people in my peer group who are actively trying to replace a 'niche' ERP/CRM (not salesforce) with a agent built alternative. These are both >$100k/yr contracts.
They've outgrown the current (industry specific) products, arguably a long time ago. The discussions started like this:
1) Started building custom dashboards on top of data exports of said product with various AI tooling. 2) This was extremely successful, as a non developer "business" person could specify, build and iterate on the exact analytics. Painful to work with a developer on this as you need to quickly iterate once you see the data and realise where your thinking was wrong. Non developers also really struggle to explain this in a way that makes sense from a developers PoV. 3) ERP system at play wanted a renewal price which was a big increase, and API deprecation. This would require a lot of existing (pre "AI") integrations to be rewrote/redone. 4) Now building an internal replacement. They would not have even considered this before AI Agents.
FWIW this tool is not super complex, but it is extremely expensive (for what it does). It already has a load of limitations which are being worked round with various levels of horrible hacks.
There are a _lot_ of these kind of SaaS products about, for each industry. You never really hear about them.
Btw I use claude code nearly every day for many hours. Opus 4.5 has been a huge leap forward, I am blown away with how it can do 10-30 minute sessions without going wrong (Sonnet definitely needed constant babysitting). And the models/agent harnesses are only getting better. Claude Code isn't even a year old yet!
Thanks for responding. This sounds like the type of thing companies have done in cycles over the years. Some % gets dissatisfied with their vendor, so they bring in-house. That predictably sucks (distraction, can't keep up with third-party tools, etc.) and so the companies go back into the marketplace. I've even been the one building some of those internal tools. :-)
Overall, that story sounds more like the niche is not well-served by software and perhaps there is an opening for a competitor to serve them well. Or perhaps the attrition will make the incumbents improve.
This article seems to suggest that businesses are going to swap domain-specific SaaS tools, written and tested by people knowledgable in the domain with specific SLAs for vibe coding everything. But your AI subscription is still a SaaS?
All you've done is swapped a SaaS built for your problem domain with another, more expensive SaaS that has no support at all for your actual problem. Why would anyone want that? People buy SaaS products because they don't want to solve the problem, they just want it fixed. AI changes nothing about that.
I’m always skeptical when I see (or say for that matter) phrases that start with “just”.
Some of the risk outlined here are real for SaaS businesses that rely on user licenses. Automation, APIs and AI are going to reduce the no of people needed which means businesses buying less licenses overall. That's why smarter SaaS solutions are moving towards pay per usage.
This is inevitable, you can't rely on user licenses as a growth metric
Vibe Coding is so easy nowadays, I coded an app almost by mistake. I put a short cryptic prompt into Kim2 to see how it would respond and it immediately (and very much to my surprise), coded an entire website with the functionality I was thinking about.
It wasn't even a coherent grammatically correct sentence that I entered and it busily went to work building the site I had in mind.
It's not hard to imagine that in the next 2-3 years, anyone will be able to build personalized apps on request.
Not for my company. In my research AI is just completely incapable of doing what we do in a cost effective way and our customers don’t have the technical know-how to vibe an alternative.
Our customers ask for about AI features and it’s a constant struggle to explain to them that they just aren’t there yet.
"It was always possible to clone software, but doing so was costly and time consuming, and the clone would need to be much cheaper, making any such venture financially non-viable.
With AI, that equation is now changing. I anticipate that within 5 years autonomous coding agents will be able to rapidly and cheaply clone almost any existing software, while also providing hosting, operations, and support, all for a small fraction of the cost.
This will inevitably destroy many existing businesses. In order to survive, businesses will require strong network effects (e.g. marketplaces) or extremely deep data/compute moats. There will also be many new opportunities created by the very low cost of software. What could you build if it were possible to create software 1000x faster and cheaper?"
Paul Bucheit
https://x.com/paultoo/status/1999245292294803914
SaaS was always just a transitional phase between desktop software and... this. We built entire businesses around being the interface layer, but if AI can interact with APIs directly, that whole layer gets compressed.
The optimistic angle nobody's exploring: maybe 'eating SaaS' means we finally escape the subscription hellscape where every basic function costs $29/month. If an AI agent can stitch together free/cheap APIs instead of forcing you into Notion/Airtable/Whatever, that's not destruction—that's evolution.
I worked at a couple of companies that tried to do internal LOB apps. Every single time, these projects have failed because the cost to maintain usually is more than just paying a subscription fee to a third party.
Related, Microsoft CEO said that soon the biggest client of Microsoft is going to be agents, not humans.
agent economy .. that's a fun thought
Saas is going to chipping away.
Agents offer a very attractive level of abstraction, and its customers, aren't necessarily human: it could be other agents. Many saas we have today would simply be unnecessary in the future.
If 90% of the actual work is waiting for Agent to get the work done, why would those companies keep paying those saas companies license fee per seat? It doesn't make sense.
Really interesting read, thank you! I'm currently working for a very traditional SaaS company (let's call us FooBar for the discussion), and I can say that this fear is very real. We talk a lot about the "FooBar killer" which is a theoretical startup company working right now on a better solution than ours. We know that there are a few of those and we even started working on one of our own exactly because of that. If you can't beat the "engineers with a spare Friday afternoon" you might as well join the attempt to replace you.
"I think we can start to see a world already where demand from new customers for certain segments of tooling and apps begins to decline. That's a problem, and will cause an increase in the sales and marketing expenditure of these companies."
I think this sort of ignores the fact that S&M agentic tools exist and the cost of those services is also dramatically decreasing, so does it net out and just become a more efficient model in general?
> most SaaS products contain many features that many customers don't need or use. A lot of the complexity in SaaS product engineering is managing that - which evaporates overnight when you have only one customer (your organisation).
This is the key point. Sure, you don't have the chops to be able to replicate the SaaS product locally with Claude/Gemini, but you don't have to, because you're no trying to make a product that can handle N+1 workflows.
If businesses are rational agents that seek to maximize profit then yes you would expect agentic AI to eat SaaS. But this is not the world we live in. So much of business could be automated with 1990s technology. A model that predicts societal change should also be able to explain why this time it's different. Historical precedent says we should expect:
- modest incremental gains in productivity
- society will remain mostly the same
- very few people will take advantage of the opportunities unlocked by AI
for back office software, I'm actually getting more interest in building weird back office stuff than before, because people know what's possible now.
I'm not a consultant anymore but my friend who owns a dental clinic asked me if I could build them a personalized system that checks in with the staff every week; a thing that helps analyze how they feel week to week and helps my friend update her management strategy and coaches her on how to talk with her staff / helps her figure out her staff's communication strategies and what work they prefer to do; and she'd like me to run and host it so she can't see the raw data from her staff so they'll trust it more as it's run by a third party.
She could probably figure out how to do this but she'd still rather pay me like $5k to do this than spend 100+ hours figuring this out herself. Even with AI it'd probably take me at least a couple of weeks to get it working 100% as intended, and I don't have a dentist business to run.
I think we'll see more back office SaaS, becuase the problems to solve are near infinite, and no one has time to build all these themselves.
Present day AI is a box that has these properties: a human has to create its inputs; a human has to verify its outputs; a human has to create the next input based on the last output. Extremely useful for sure, but this is not the kind of box you can use to scale a service delivered directly to end users who can't perform the activities labeled "human" in the sentence above.
> If anything, I think we'll see (another) splintering in the market. Companies with strong internal technical ability vs those that don't.
A tangent, I feel, again, unfortunately, the AI is going to divide society into people who can use the most powerful tools of AI vs those who will be only be using chatGPT at most (if at all).
I don't know why I keep worrying about these things. Is it pointless?
I do feel this divide, but from what I've read, and ehat I've observed, it's more a divide between people who understand the limited use-cases where machine learning is useful, and people who believe it should be used wherever possible.
For software engineering, it is useless unless you're writing snippets that already exist in the LLMs corpus.
> For software engineering, it is useless unless you're writing snippets that already exist in the LLMs corpus.
If I give something like Sonnet the docs for my JS framework, it can write code "in it" just fine. It makes the occasional mistake, but if I provide proper context and planning up front, it can knock out some fairly impressive stuff (e.g., helping me to wire up a shipping/logistics dashboard for a new ecom business).
That said, this requires me policing the chat (preferred) vs. letting an agent loose. I think the latter is just opening your wallet to model providers but shrug.
If you need a shipping dashboard, then yeah, that's a very common, very simple use-case. Just hook up an API to a UI. Even then I don't think you'll make a very maintainable app that way, especially if you have multiple views (because the LLMs are not consistent in how they use features, they're always generating from scratch and matching whatever's closest).
What I'm saying is that whenever you need to actually do some software design, i.e. tackle a novel problem, they are useless.
My understanding is that agents are:
1) helping to saturate traditional SaaS because code is being commoditized / the effort to build is dropping significantly.
2) defining an adjacent sub-category of SaaS: "Service-as-a-Software" where the SaaS provides _outcomes_ instead of _tools_; this couldn't really exist at scale before recently.
When you say agents, do you mean the workflow runners that can call APIs and automate the workflow steps?
Automation is not new. What's new is the capabilities of the models that can be assigned with some of the workflow steps. If these steps were served by SaaS companies so far, they will still serve it. Maybe they make it much cheaper and use a model themselves.
This is borderline schizophrenia. Firstly, nobody replaces something that works with something that might or might not work.
Secondly, the way this person describes "agents" is not rooted in reality:
>Agents don't leave. And with a well thought through AGENTS.md file, they can explain the codebase to anyone in the future.
>What's going to be difficult to predict is how quickly agents can move up the value chain. I'm assuming that agents can't manage complex database clusters - but I'm not sure that's going to be the case for much longer.
What in the world. And of course he's selling a course. This is the same business as those people sitting in Dubai selling $6000 options trading courses to anyone who believes their bullshit. The grifter economy around AI is in full swing like it was around blockchain/crypto in 2017-2020.
Hmm, suppose Claude Code can make a prototype.
But who's going to deploy it, make backups, integrate authentication, review security?..
Now, perhaps, it would be nice to have some kind of a ERP framework which would host AI-generated apps and connect them to each other. Is there anything like that?
I’ve been saying this for months:
https://efitz-thoughts.blogspot.com/2025/08/the-effect-of-ll...
The ffmpeg wrapper use case is interesting. Reusing some core software for speed and reliability but to get better usability by leveraging LLMs seems like the sweet spot for SaaS use cases. A lot of these CRM products are basically wrappers around DBs and sheets like core products with terrible UI. The new breed will solve the UI ease of use issues.
The real question isn’t whether we’ll run out of SaaS customers, it’s whether we’ll run out of new problems that can be solved by the current set of tools. I doubt it, it’d be a historical first in the modern era. But the solutions may move closer to the companies with the problems. More in-house, fewer intermediaries.
I think the biggest impact will be on SaaS products from startups and side projects. People will think, "I can build something myself with the help of AI, so why should I pay to try your unfinished product?" The barrier to entry has become higher, requiring a more complete product.
Yes when I need to convert music in one way or another I dont pay 0.1$ to do it and be over with it.
I run Cloude Code to build that SaaS for me locally over the span of few weeks, to get the same value.
This article makes no sense.
>SaaS valuations are built on two key assumptions: fast customer growth and high NRR (often exceeding 100%).
They are also on the basis of high gross margins of 80-90%. What happens to margins when you start including token variable costs?
The only SaaS that AI has eaten for us is Retool. It wasn't the cost (we were paying < $200 per month). Retool has become more clunky to use vs. writing code with AI to solve the problems we used Retool for.
Curious if you can share more about the types of things you were using retool for that you've migrated off?
This thread reeks of horse breeders saying cars won’t replace them.
Isn't plenty of space of efficiency value in SaaS over AIs? And depending on the use-case and what the optimization is, also performance?
I get and agree with a lot of skepticism (and I get where ad-hominem attacks come from:). I have AI shoved my throat at work and at home 24x7 and most of it not for my benefit, and the writer doesn't out as much rigor into writing as might be beneficial.
At the same time, to the core theme of the article - do any of us think a small sassy SaaS like Bingo card creator could take off now? :-)
https://training.kalzumeus.com/newsletters/archive/selling_s...
Waiting for each organization to write clone of jira for there own usage.
I have been the tech lead for two companies between 2015-2020.
The first company was a low margin business that sent home health care nurses to special needs kids and reimbursements came from Medicaid.
I was hired by the new director to modernize their aging in house Electronic Medical System built on FoxPro 1999 running on SQL Server 2000 - in 2016.
They had two “developers” who had been their for 10 and 20 years respectively who only knew Sql Server and FoxPro.
They also had some other software.
After doing some assessments of the situation, my report to the director and the CTO was that this company should not try to support a software development department and hire new people. Their margins are too small to be competitive or to keep people.
I suggested we outsource everything to other consulting companies - not staff augmentation. Let the consulting company do the entire implementation based on a Statement of Work.
The two “developers” role changed to “data analyst”. Even with AI I would have said the same thing today. Not every company needs to try to do software engineering. Every company does need to understand its data. [1]
The next company was a startup. I was adamant about blocking every developer who suggested any internal tool that we could get a well known SaaS to do or where AWS had a service that wasn’t firefly related to our product. To use the cliche - anything “that didn’t make the beer taste better”. My opinion wouldn’t have changed with AI.
The last thing I want is a bunch of bespoke internal vibe coded AI Slop that we have to support that is not in service to the product when we can find a reputable third party product.
And no that doesn’t mean I am going to trust some unknown one person SaaS company.
[1] 18 months into the job, I walked into the director’s office and told him, “let’s be honest, you all don’t need me anymore”. I purposefully put myself out of job. But boy did I have a story to tell during behavioral interviews at my next job at the startup and my interview for my job at BigTech after I left the startup.
You can already self-host a lot of open source software today, but people still buy subscriptions for SaaS-es
Yeah, when everyone can create a SaaS, noone will and will create the boutique thing you’re selling for their own purpose
Any SaaS consumable by AI probably deserves it, no?
In my experience, AI/Vibe-coded tools crumble under their own weight given enough iterations and even faster if there is no (real) developer in the loop overseeing/planning/reviewing.
I think that _developers_ might be reaching for more LLM-built tools instead of SaaS in some cases and I also can believe that plenty of people _think_ they are vibe-coding up alternatives to SaaSes they pay for but I think those people are going to have a bad time when it eventually collapses (the tool they made, not talking about the AI bubble).
I'm not anti-LLM (not in the slightest) and you can sometimes (it's not a given) get to 80-90% of an existing product/service with vibe-coding or LLM-assisted development but that last 10-20% (and especially that last 1-5%) are where it gets hard. Really hard.
It's the typical "you can already build such a system yourself quite trivially"-mentality IMHO. I feel this myself all the time, even before LLMs, "Oh, I could clone this easily!" and in many cases I could or even did... or at least I cloned the easy/basic/happy-path version that eschewed a whole slew of features I didn't need/care for. But then the complexity started to set in. [0]
I have the same feeling for things I'm not even trying to clone, just build from scratch. I put together a cookbook for friends and family recently and used LLMs to help write essentially a static site generator to read my JSON data I created (some with the help of LLMs) and render it out as HTML (which I then turned into a PDF). My mind started to run with "Hmm, could I create a product out of this? It was relatively easy to get started..." but then reality set in and I remembered all the little tweaks I had to do (shorten a title here, reduce padding there, etc to make everything fit and look good). Sure, I got 80% of the way there in the first or second iteration of it using LLMs but there was plenty of massaging that had to happen to turn it into something usable that I could send to a printer.
The author teaches workshops for "AI" development. Next commercial please.
Hackernews seems completely astroturfed in the last weeks.
It's not the hackernews i knew even 3 years ago anymore and i'm seriously close to just ditching the site after 15+ years of use.
I use AI heavily but everyday there's crazy optimistic almost manic posts about how AI is going to take over various sectors that are completely ludicrous - and they are all filled with comments from bizarrely optimistic people that have seemingly no knowledge of how software is actually run or built, ie. it's the human organisational, research and management elements that are the hard parts, something AI can't do in any shape or form at the moment for any complex or even small company.
[dead]
Man, AI tools are going to get so expensive, aren’t they.
Building any product requires endless highqu
I'm reading this thread's comments and a LOT of you are missing OP's point. OP is not describing the risk that your SaaS product is now easily cloned by your customers' internal devs (or startup competitors) armed with agents. The risk is that certain SaaS products (but not all) mostly exist to provide answers to end users' questions about data, answers that can now be obtained by providing the same raw data to an agent with a prompt.
Another video about this today: https://www.youtube.com/watch?v=4Bg0Q1enwS4
Summary is that for agents to work well they need clear vision into all things, and putting the data behind a gui or not well maintained CLI is a hinderance. Combined with how structured crud apps are an how the agents can for sure write good crud apps, no reason to not have your own. Wins all around with not paying for it, having a better understanding of processes, and letting agents handle workflows.
honestly, if you are bootstrapping anything, you don't need saas now for the start
SaaS are swiss-army knife tools and you don't need all of this.
do you want to have a contact form on your site? Don't but the whole WP plugin for forms, ask AI for tiny, well-aligned plugin which will display form fields and process the input.
Do you need to A/B test your landing page? Just ask for another plugin which will switch page versions and track impressions.
No need for Hubspot when you have google sheets + AI-made plugin for this.
Let me give you an example of my workflow from tonight:
1. I had two text documents containing plain text to compare. One with minor edits (done by AI).
2. I wanted to see what AI changed in my text.
3. I tried the usual diff tools. They diffed line by line and result was terrible. I searched google for "text comparison tool but not line-based"
4. As second search result it found me https://www.diffchecker.com/ (It's a SaaS, right?)
5. Initially it did equally bad job but I noticed it had a switch "Real-time diff" which did exactly what I wanted.
6. I got curious what is this algorithm. So I asked Gemini with "Deep Research" mode: "The website https://www.diffchecker.com/ uses a diff algorithm they call real-time diff. It works really good for reformatted and corrected text documents. I'd like to know what is this algorithm and if there's any other software, preferably open-source that uses it."
7. As a first suggestion it listed diff-match-patch from Google. It had Python package.
8. I started Antigravity in a new folder, ran uv init. Then I prompted the following:
"Write a commandline tool that uses https://github.com/google/diff-match-patch/wiki/Language:-Py... to generate diff of two files and presents it as side by side comparison in generated html file."
[...]
"I installed the missing dependance for you. Please continue." - I noticed it doesn't use uv for installing dependencies so I interrupted and did it myself.
[...]
"This project uses uv. To run python code use
uv run python test_diff.py" - I noticed it still doesn't use uv for running the code so its testing fails.
[...]
"Semantic cleanup is important, please use it." - Things started to show up but it looked like linear diff. I noticed it had a call to semantic cleanup method commented out so I thought it might help if I push it in that direction.
[...]
"also display the complete, raw diff object below the table" - the display of the diff still didn't seem good so I got curious if it's the problem with the diffing code or the display code
[...]
"I don't see the contents of the object, just text {diffs}" - it made a silly mistake by outputting template variable instead of actual object.
[...]
"While comparing larger files 1.txt and 2.txt I notice that the diff is not very granular. Text changed just slightly but the diff looks like deleting nearly all the lines of the document, and inserting completely fresh ones. Can you force diff library to be more granular?
You seem to be doing the right thing https://github.com/google/diff-match-patch/wiki/Line-or-Word... but the outcome is not good.
Maybe there's some better matching algoritm in the library?" - it seemed that while on small tests that Antigravity made itself it worked decently but on the texts that I actually wanted to compare was still terrible although I've seen glimpses of hope because some spots were diffed more granularly. I inspected the code and it seemed to be doing character level diffing as per diff-match-patch example. While it processed this prompt I was searching for solution myself by clicking around diff-match-patch repo and demos. I found a potential solution by adjusting cleanup, but it actually solved the problem by itself by ditching the character level diffing (which I'm not sure I would have come up with at this point). Diffed object looked great but as I compared the result to https://www.diffchecker.com/ output it seemed that they did one minor thing about formatting better.
[...]
"Could you use rowspan so that rows on one side that are equivalent to multiple rows on the other side would have same height as the rows on the other side they are equivalent to?" - I felt very clumsily trying to phrase it and I wasn't sure if Antigravity will understand. But it did and executed perfectly.
I didn't have to revert a single prompt and interrupted just two times at the beginning.
After a while I added watch functionality with a single prompt:
"I'd like to add a -w (--watch) flag that will cause the program to keep running and monitor source files to diff and update the output diff file whenever they change."
[...]
So I basically went from having two very similar text files and knowing very little about diffing to knowing a bit more and having my own local tool that let's me compare texts in satisfying manner, with beautiful highlighting and formatting, that I can extend or modify however I like, that mirrors interesting part of the functionality of the best tool I found online. And all of that in the time span shorter than it took me to write this comment (at least the coding part was, I followed few wrong paths during my search for a bit).
My experience tells me that even if I could replicate what I did today (keeping motivated is an issue for me), it would most likely be multi-day project full of frustration and hunting small errors and venturing into wrong paths. Python isn't even my strongest language. Instead it was a pleasant and fun evening with occasional jaw drops and feeling so blessed that I live in SciFi times I read about as a kid (and adult).
You could have also ran diff on both files and gotten a reasonable diff.
I ran kompare, kdiff3, meld, git diff --no-index (--patience, --word-diff, --histogram) and it was all useless.
> 3. I tried the usual diff tools. They diffed line by line and result was terrible.
Um. I don't want to be That Guy (shouting at clouds, or at kids to get off my lawn or whatever) but ... what "usual diff" tools did you use? Because comparing two text files with minor edits is exactly what diff-related tools have excelled at for decades.
There is word-level diff, for example. Was that not good enough? Or delta [0] perhaps?
[0] https://github.com/dandavison/delta
kompare, kdiff3, meld, git diff --no-index (--patience, --word-diff, --histogram)
All weren't remotely close to what I wanted.
On first glance delta is also doing completely standard thing. But I can't rule out that there are some flags to coerce it to do the thing I wanted. But searching for tools and flag combinations is not that fun and success is not guaranteed. Also I found a (SaaS) tool and a flag there that did exactly what I wanted. Just decided to make my own local tool afterwards for better control. With an agent.
> Because comparing two text files with minor edits is exactly what diff-related tools have excelled at for decades.
True. And I ended up using this excellent Google diff-match-patch library for diffing. AI didn't write me a diffing algorithm. Just everything around it to make a convenient tool for me. Most tools are for source code and treat end lines as a very strong structural feature of compared texts. I needed something that doesn't care about end lines all that much and can show me which characters changed between one line of one file and five lines it was split into in the second file.
that andressen horowitz article from 2011 is really beautiful
Another big long AI-generated article. Sheesh. Bonus points for replacing the emdashes with regular hyphens to try to cover it up.
Another post with no data, but plenty of personal vibes.
> The signals I'm seeing
Here are the signals:
> If I want an internal dashboard...
> If I need to re-encode videos...
> This is even more pronounced for less pure software development tasks. For example, I've had Gemini 3 produce really high quality UI/UX mockups and wireframes
> people really questioning renewal quotes from larger "enterprise" SaaS companies
Who are "people"?
Vibes can move billions of dollars from someone else's retirement money
> For example, I've had Gemini 3 produce really high quality UI/UX mockups and wireframes
Is the author a competent UX designer who can actually judge the quality of the UX and mockups?
> I write about web development, AI tooling, performance optimization, and building better software. I also teach workshops on AI development for engineering teams. I've worked on dozens of enterprise software projects and enjoy the intersection between commercial success and pragmatic technical excellence.
Nope.
> Agents don't leave
How wrong the author is about that! IMO As soon as the bubble bursts, which is already evident and imminent, these agents will raise their subscription fees to ridiculous amounts. And when that happens, entire organizations will abandon them and return to good ol' human engineering
But local agents will still keep working. Of course they're not as poweful as an acre of industrially cooled compute power, but still a massive improvement over "Intellisense" and code snippets.
You're 100% right though, you shouldn't build your business on top of an AI service and not have a plan what to do _when_ it either goes away or just prices itself out. It's a massive bubble where money is just moving in a circle.
> IMO As soon as the bubble bursts, which is already evident and imminent, these agents will raise their subscription fees to ridiculous amounts. And when that happens, entire organizations will abandon them and return to good ol' human engineering
It's worse than you state; a primary premise of the current AI expansion and investment, continuously repeated, is that computational resources are increasing for the same price-point.
So tell me, when we have these hardware gains in 5 years, why the fuck would I pay for fractionally better output on a cloud subscription when I could run on-prem GPUs for a fraction of what the actual subscription would be, giving me 24x7 agents working with no limit?
Current highly-invested AI providers are token providers - they are sitting at the bottom of the value-chain. They are trying to climb the value-chain, but the real value is in the models, and since all models have mostly converged on the same performance, running your own gives a very tiny drop in value.
Their problem is that, even at $200/m, it is not feasible to offer 24x7 access to the models - that max subscription has tiny limits: on that subscription you most definitely are not enabling even a single agent to run f/time.
You might get 3 hours per day, maybe. Best case, you get half a working day (4 hours), for five days. So double the subscription, and you're still looking at only a single simply agent that you can run f/time for $400/m.
For collaborating agents, you'll have, what, 4 - 5 diving into a large task in parallel? That's maybe $1600/m - $2000/m to solve tasks. You still have to pay the (increasingly incompetent) human operator to manage them.
That sort of workflow is what is being sold as the vision, and yet that will only be economically viable if you're self-hosting your own model.
The way things are going personal computing will be a thing of the past. It started with GPUs being too expensive but now it’s RAM and eventually SSDs.
We’ll need AI not because it is actually better but because future generations won’t have personal computing hardware to start learning when they are 7.
I stopped reading after too many references to tasks solvable by a 1-line invocation of a CLI tool like ffmpeg or pandoc.
Checked out as soon as I saw the word "moat".
Classic tell this is tech bro-ese.
[dead]
Oh no! Anyway.