8 ms·

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 th

by benzible 10mo 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.

Bombthecat 10mo ago
Yap. AI and agents help to centralise, not decentralise
- ben_w 10mo 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 10mo 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 10mo 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.
      - j45 10mo 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 10mo 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 10mo 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.
Crowberry 10mo 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.
- j45 10mo 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.
- agwp 10mo 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 10mo 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
MLgulabio 10mo 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 10mo 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.
jeswin 10mo 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 10mo 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 10mo ago
    Assuming this ever works, this is no threat to the SaaS industry. If anything it increases its importance.
    - TeMPOraL 10mo ago
      SaaS products rely on resisting commoditization. AI agents defeat that.
      - nprateem 10mo 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.
bob1029 10mo 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 10mo ago
  I might be missing something but live edits in production and banking? Doesn't that violate all kinds of compliance controls?
  - bob1029 10mo 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.
j45 10mo 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.
Havoc 10mo 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
- j45 10mo ago
  Deep domain expertise is not common enough.
- ethbr1 10mo 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 10mo 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.
cm277 10mo 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 10mo 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).
mikert89 10mo ago
A year or two from now it will be trivial to copy your product
- raw_anon_1111 10mo 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 10mo 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 10mo 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?
- f311a 10mo 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 10mo ago
  Did you claim the same a year or two ago? Why or why not?
- Bridged7756 10mo ago
  Yes friend. That's what people said 2 years ago. Next?
  - 10mo ago
igortg 10mo ago
The beauty of HN: frequently comments are way more valuable than the article being shared
- chrisweekly 10mo 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).
- pseudosavant 10mo ago
  There are plenty of HN posts where I only read the comments because the discussion around that topic is the most interesting part.
lwhi 10mo 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.
bpavuk 10mo 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.
lm28469 10mo 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.
CuriouslyC 10mo 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.
popcorncowboy 10mo 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.
testbjjl 10mo ago
Maybe expect more paragraph 2 for flat fees or cheaper as many people who know how to code find themselves without employment?
SkyPuncher 10mo 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 10mo 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 10mo ago
    If it is a credible bluff, does it work?
    - citizenpaul 10mo 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 10mo 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 10mo 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?
indymike 10mo 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 10mo 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.
  - deleted 10mo ago
    [deleted]
  - therealwhytry 10mo 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.
ChicagoBoy11 10mo 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"
wouldbecouldbe 10mo 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 10mo 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.
mbesto 10mo 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.
reactordev 10mo 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?
mlinhares 10mo 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 10mo 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.
baxtr 10mo 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.
CyanLite2 10mo 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.
btown 10mo 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.
- JaumeGreen 10mo 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 10mo ago
    Agree. Lack of something as accessible and useful as Access is a major hole. AppSheet comes close: https://about.appsheet.com/home/ https://about.appsheet.com/home/
  - mike_hearn 10mo ago
    The modern version of Access is something like APEX. https://www.oracle.com/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.
- nitwit005 10mo 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.
gwbas1c 10mo 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 10mo 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?
efitz 10mo 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 10mo 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).
rewgs 10mo ago
> 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>
sporkland 10mo ago
As told in Innovator's Dilemma mainframe companies would have told the exact same story right up until the cheaper alternative met all of their core needs. But in this case I don't think you get disrupted by copycats but instead by savvy business users building their own disposable alternatives which get just enough done. Though I think one thing that is being overlooked is that Platforms are the hidden hero under all of this. A lot of AI products are benefiting from various cloud platforms that have been created that make it easy to deploy and opperate these apps. So as long as you are providing a sufficiently general, high productivity platform that can't be emulated by one of the major vendors you'll likely become the new runtime.
conductr 10mo ago
Companies and hyper focused on integrating AI right now, which means they’re building this bench strength, and the obvious eventual question become what paid software can we bring “in house”. They will of course look at revenue growth opportunities and such first and how to improve known problem areas but cost reduction is an eventuality. I’m actively building products with AI that will replace millions of value in Enterprise software. I’m not even a programmer, I can do this as a CFO with an AI consultant (human consultant that specializes in AI that is)

Bombthecat 10mo ago

Yap. AI and agents help to centralise, not decentralise

ben_w 10mo 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 10mo 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 10mo 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.
    - j45 10mo 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 10mo 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 10mo 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.

Crowberry 10mo 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.

j45 10mo 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.
agwp 10mo 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 10mo 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

MLgulabio 10mo 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 10mo 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.

jeswin 10mo 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 10mo 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 10mo ago
  Assuming this ever works, this is no threat to the SaaS industry. If anything it increases its importance.
  - TeMPOraL 10mo ago
    SaaS products rely on resisting commoditization. AI agents defeat that.
    - nprateem 10mo 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.

bob1029 10mo 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 10mo ago
I might be missing something but live edits in production and banking? Doesn't that violate all kinds of compliance controls?
- bob1029 10mo 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.

j45 10mo 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.

Havoc 10mo 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

j45 10mo ago
Deep domain expertise is not common enough.
ethbr1 10mo 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 10mo 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.

cm277 10mo 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 10mo 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).

mikert89 10mo ago

A year or two from now it will be trivial to copy your product

raw_anon_1111 10mo 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 10mo 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 10mo 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?
f311a 10mo 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 10mo ago
Did you claim the same a year or two ago? Why or why not?
Bridged7756 10mo ago
Yes friend. That's what people said 2 years ago. Next?
- 10mo ago

igortg 10mo ago

The beauty of HN: frequently comments are way more valuable than the article being shared

chrisweekly 10mo 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).
pseudosavant 10mo ago
There are plenty of HN posts where I only read the comments because the discussion around that topic is the most interesting part.

lwhi 10mo 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.

bpavuk 10mo 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.

lm28469 10mo 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.

CuriouslyC 10mo 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.

popcorncowboy 10mo 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.

testbjjl 10mo ago

Maybe expect more paragraph 2 for flat fees or cheaper as many people who know how to code find themselves without employment?

SkyPuncher 10mo 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 10mo 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 10mo ago
  If it is a credible bluff, does it work?
  - citizenpaul 10mo 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 10mo 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 10mo 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?

indymike 10mo 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 10mo 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.
- deleted 10mo ago
  [deleted]
- therealwhytry 10mo 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.

ChicagoBoy11 10mo 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"

wouldbecouldbe 10mo 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 10mo 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.

mbesto 10mo 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.

reactordev 10mo 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?

mlinhares 10mo 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 10mo 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.

baxtr 10mo 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.

CyanLite2 10mo 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.

btown 10mo 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.

JaumeGreen 10mo 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 10mo ago
  Agree. Lack of something as accessible and useful as Access is a major hole. AppSheet comes close: https://about.appsheet.com/home/ https://about.appsheet.com/home/
- mike_hearn 10mo ago
  The modern version of Access is something like APEX. https://www.oracle.com/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.
nitwit005 10mo 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.

gwbas1c 10mo 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 10mo 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?

efitz 10mo 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 10mo 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).

rewgs 10mo ago

> 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>

sporkland 10mo ago

As told in Innovator's Dilemma mainframe companies would have told the exact same story right up until the cheaper alternative met all of their core needs. But in this case I don't think you get disrupted by copycats but instead by savvy business users building their own disposable alternatives which get just enough done. Though I think one thing that is being overlooked is that Platforms are the hidden hero under all of this. A lot of AI products are benefiting from various cloud platforms that have been created that make it easy to deploy and opperate these apps. So as long as you are providing a sufficiently general, high productivity platform that can't be emulated by one of the major vendors you'll likely become the new runtime.

conductr 10mo ago

Companies and hyper focused on integrating AI right now, which means they’re building this bench strength, and the obvious eventual question become what paid software can we bring “in house”. They will of course look at revenue growth opportunities and such first and how to improve known problem areas but cost reduction is an eventuality. I’m actively building products with AI that will replace millions of value in Enterprise software. I’m not even a programmer, I can do this as a CFO with an AI consultant (human consultant that specializes in AI that is)