benzible
19 hours ago
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.
efitz
4 hours ago
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.
benzible
an hour ago
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).
efitz
38 minutes ago
> 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.
benzible
21 minutes ago
[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.
btown
9 hours ago
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.
nitwit005
6 hours ago
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.
btown
6 hours ago
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.
ImPleadThe5th
4 hours ago
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"
Figs
3 hours ago
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-...
JaumeGreen
9 hours ago
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.
xnx
8 hours ago
Agree. Lack of something as accessible and useful as Access is a major hole. AppSheet comes close: https://about.appsheet.com/home/
mike_hearn
6 hours ago
The modern version of Access is something like 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.
SkyPuncher
13 hours ago
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"
robofanatic
11 hours ago
> "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?
pseudosavant
10 hours ago
If it is a credible bluff, does it work?
citizenpaul
8 hours ago
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"
UltraSane
6 hours ago
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.
woah
10 hours ago
> (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?
bob1029
17 hours ago
> 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.
hvb2
7 hours ago
I might be missing something but live edits in production and banking? Doesn't that violate all kinds of compliance controls?
bob1029
7 hours ago
> 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.
jeswin
18 hours ago
> 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.
TeMPOraL
16 hours ago
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.
skywhopper
16 hours ago
Assuming this ever works, this is no threat to the SaaS industry. If anything it increases its importance.
TeMPOraL
16 hours ago
SaaS products rely on resisting commoditization. AI agents defeat that.
cpursley
13 hours ago
You're probably thinking "SaaS for other tech end users". Most SaaS is not that.
phkahler
10 hours ago
Isn't the majority of SaaS in ERP systems?
nprateem
15 hours ago
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.
TeMPOraL
7 hours ago
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.
ethbr1
14 hours ago
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.
testbjjl
13 hours ago
Will the SaaS also use LLMs? If so it opens the questions, why not and do we really need, as the article points out.
immibis
13 hours ago
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.
indymike
13 hours ago
> 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.
enraged_camel
12 hours ago
>> 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.
TeMPOraL
7 hours ago
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.
btbuildem
9 hours ago
Right -- and that's likely because search was completely broken, people always complained about it, and nothing was ever done to improve it.
adriand
15 hours ago
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.
William_BB
13 hours ago
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.
threetonesun
10 hours ago
We perpetually find worse and more expensive ways to reinvent Microsoft Access.
ogogmad
7 hours ago
Interesting comment. Which ways have people been doing this?
htrp
9 hours ago
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.
DrScientist
9 hours ago
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.
hrimfaxi
13 hours ago
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.
hobs
12 hours ago
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".
SoftTalker
8 hours ago
Most engineers like being mechanics though.
vlugovsky
13 hours ago
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.
ceejayoz
9 hours ago
> No updates yet, but I have every confidence he’ll figure it out.
"It" being "that it's harder than it looks"?
adriand
8 hours ago
> "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.
jimbokun
5 hours ago
Update us when you have an actual success story.
testbjjl
13 hours ago
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.
cdurth
12 hours ago
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.
SoftTalker
8 hours ago
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.
Crowberry
19 hours ago
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.
agwp
14 hours ago
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)
thorawaytrav
14 hours ago
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
jakeydus
10 hours ago
God I hope my bank isn't using agents to build things. "Sorry, Grok misplaced your retirement funds."
j45
15 hours ago
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.
igortg
14 hours ago
The beauty of HN: frequently comments are way more valuable than the article being shared
pseudosavant
10 hours ago
There are plenty of HN posts where I only read the comments because the discussion around that topic is the most interesting part.
chrisweekly
12 hours ago
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).
wouldbecouldbe
12 hours ago
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.
rapind
11 hours ago
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.
lm28469
13 hours ago
> 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.
popcorncowboy
13 hours ago
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.
gwbas1c
8 hours ago
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."
riantogo
6 hours ago
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?
baxtr
10 hours ago
> 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.
indymike
13 hours ago
> 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.
adventured
12 hours ago
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.
osn9363739
4 hours ago
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?
therealwhytry
11 hours ago
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.
indymike
10 hours ago
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.
MLgulabio
18 hours ago
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.
cpursley
16 hours ago
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.
CuriouslyC
13 hours ago
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.
reactordev
11 hours ago
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?
ChicagoBoy11
12 hours ago
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"
lwhi
14 hours ago
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.
Havoc
15 hours ago
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
ethbr1
14 hours ago
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.
martinald
11 hours ago
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.
j45
14 hours ago
Deep domain expertise is not common enough.
mlinhares
11 hours 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.
SoftTalker
8 hours ago
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.
mbesto
12 hours ago
> The bottleneck is still knowing what to build, not building.
My hot take - LLMs are exposing a whole bunch of developers to this reality.
CyanLite2
10 hours ago
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.
cm277
15 hours ago
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).
ethbr1
14 hours ago
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).
agentultra
12 hours ago
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.
ethbr1
12 hours ago
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.
agentultra
11 hours ago
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?
ethbr1
7 hours ago
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...
agentultra
2 hours ago
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.
sifar
7 hours ago
>> 2) expertise to develop code
This is wrong. Paradoxically, you need expertise to develop code with LLM.
ethbr1
7 hours ago
For LOB CRUD apps? We blew past that capability point months ago.
testbjjl
13 hours ago
Maybe expect more paragraph 2 for flat fees or cheaper as many people who know how to code find themselves without employment?
Bombthecat
18 hours ago
Yap. AI and agents help to centralise, not decentralise
ben_w
16 hours ago
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.
j45
15 hours ago
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.
ben_w
15 hours ago
> 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.
Bombthecat
11 hours ago
The big models will never run locally, and I doubt that titan and co will run locally, just way to much resources needed
ben_w
8 hours ago
"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.
somewhereoutth
8 hours ago
> 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.
j45
14 hours ago
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.
ben_w
14 hours ago
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.
j45
10 hours ago
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.
ben_w
8 hours ago
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.
j45
4 hours ago
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.
mikert89
14 hours ago
A year or two from now it will be trivial to copy your product
broast
9 hours ago
But what about their two year head start? If everyone is executing at the speed of light, there will still be winners and losers
f311a
14 hours ago
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.
William_BB
13 hours ago
Did you claim the same a year or two ago? Why or why not?
Bridged7756
12 hours ago
Yes friend. That's what people said 2 years ago. Next?
latentsea
12 hours ago
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.
raw_anon_1111
14 hours ago
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?
xtiansimon
14 hours ago
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.
raw_anon_1111
14 hours ago
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?
j45
15 hours ago
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.
bpavuk
14 hours ago
> 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.