It's a tale as old as time that developers, particularly junior developers, are convinced they could "slap together something in one weekend" that would replace expensive SAAS software and "just do the parts of it we actually use". Unfortunately, the same arguments against those devs regular-coding a bespoke replacement apply to them vibe-coding a bespoke replacement: management simply doesn't want to be responsible for it. I didn't understand it before I was in management either, but now that I'm in management I 100% get it.
OTOH, I was hired by an enterprise that was many months into a giant backend rewrite. After wrapping my head around the many plans, I realized they were rewriting Django, badly. One weekend I prototyped the whole thing… in Django. It worked. It met the specs. It was a CRUD app with a REST API.
I came in to work Monday morning, showed it off, and inadvertently triggered a firestorm. Later my boss told me not to do that again because it caused havoc with schedules and such.
So I quit and found a better job. Sometimes the new guy can make a better version themselves over the weekend, not because they’re a supergenius, but because they’re not hampered by 47 teams all trying to get their stamp on the project.
(In before “prime example of overconfidence!”: feel free to doubt. It was a CRUD app with a handful of models on a PostgreSQL backend. They were writing a new Python web framework to serve it, complete with their own ORM and forms library and validation library. Not because the existing ones wouldn’t work, mind you, but more out of not realizing that all these problems were already sufficiently solved for their requirements.)
This is the prime example of Law 1 of Robert Greene's "The 48 Laws of Power": "Never Outshine the Master."
The core principle is to always make those above you - your bosses, mentors, or superiors feel comfortably superior.
If you display your talents too aggressively, you risk triggering their deep-seated insecurities, which can lead them to sabotage your career or remove you from your position.
Galileo Galilei handled this really well. When he discovered the moons of Jupiter he strategically named them after the ruling Medici family.
By making the discovery about their greatness rather than his own intellect, he secured their lifelong patronage.
However, if your superior is a "fading star" or is clearly about to fall, you do not need to be merciful. In these cases, it may be strategic to outshine them to hasten their downfall and position yourself as the natural successor.
Sure it has been codified into a "law" but really this is just basic social skills / emotional intelligence which engineers on the spectrum struggle with.
If you've spent any time in a large enough organization you realize quickly that hierarchies form based on status, power and influence & not necessarily technical merit. No it's not "the best person for the job" that rises up and tells you what to do.
Casually solving a problem that required a lot of resources and personnel has big implications in the power dynamics of the org. This is like setting off a nuke. You don't just do this unless you are prepared for the blow back or can easily consolidate attention & influence in the immediate aftermath.
Take a look at OpenAI's corporate politics for an example of how this works in practice. All the key talent that defined the company has left or was forced out and will likely languish in whatever ventures they start next, all because they don't understand how humans operate & how to drive change by aligning incentives.
some people discuss these dynamics as sheep versus goats. Social stability was more precious due to scarcity, while goat behavior included 40 armed men killing their rivals with swords (and better if the rivals do not have their own swords). Many, many parallels exist in mammals that live in groups. You might be surprised at the details of how some mammals actually behave in real life!
"Look how clever we were to hire this person and put them in the right place at the right time! We are now ahead of schedule and are reallocating teams."
My rule had always been "hire people smarter than you and give them everything they need to succeed". Set a clearly defined goal, ensure understanding of the reasons behind it then provide the support the team needs to make it happen.
Ditto. And then celebrate them like crazy for every win and give them all the credit, even if you helped. Who wouldn't want to do their absolute best work in an environment like that?
doesn't even need to be "smarter than you", just realise that as a manager your job is not to build the product, it's to build the environment in which the people building the product can thrive and build the best product they are capable of.
It seems like you are suggesting it is lamentable that a group of people with the analytical intelligence to create a technology that has changed the world, don't have the social intelligence to be irrational when that is called for? Shouldn't we instead hate the game itself and lament that leaders can't behave rationally? In my more frustrated moments I wonder about a world following a disease that eliminated all neurotypical people.
Errr… Galileo was asked to write a book discussing both sides of the heliocentric / geocentric debate … and so wrote a book with two characters having a debate while walking in a garden - one named (I paraphrase for effect) “Galileo” and one named “Pope Simplehead”
Needless to say the next twenty years under house arrest gave him a lot of time to think about character names :-)
Sounds like when I was asked to give minimum hardware requirements for something doing backend processing (receive text submitted as print jobs, massage, send to printers).
The requirements as they went out were much higher than they needed to be, because I decided telling them that we weren't stressing anything on the obsolete NT desktop repurposed as the test system might not please everyone.
IMHO I think the best any engineer can do in an org is to ask "what is the highest value problem to solve for the business" and "can I solve it".
"I made this x times better" is not relevant to _most peoples in any org_.
That's the dark secret. Nobody cares how good of an engineer you are _unless there is a fire to put out_. After which you get pat on the back and back to usual business.
There are situations where years of impeccable, high value diligent work is rewarded.
But what is more common is that the rewards go to those who are in politically expedient position to get the rewards. Favourites, culturally aligned folk, etc. And sometimes it's not even about you or your boss, but the politics in the organization at large. "You are not allowed to promote anyone due to budget" is a very common thing.
So I guess what I mean to say is if as an egineer you want to retain your sanity, when at work focus on maximizing business value. If you know a kick-ass solution that is 10000x better than industry standard go with it but know this - nobody will care! Nobody believes _someone in their org_ could have beaten _industry standard_ unless the org is very unique. What you get is small increase in your reputation - and sadly nobody recognizes how hard that was. Maybe you will meet some other engineer at some point who has tackled that same issue - and then you can bond over the solution.
A large part of software ecosystems is about business, politics, and the large scale impact of technology.
Saying this as an IC whose previous tasks at previous employer could have employed _teams_ but since we were allowed to deal with them smartly it was just me.
So if you know a 10000x solution to a problem many people have - that's a good opportunity to consider can it be productized!
The sad corollary to "you will be noticed only if you put out fires" is nobody actually realizes the elegant solution you shipped will stop tons of these fires from happening. Rather the reaction will be "that looked simple and easy so probably is not important".
And on the other hand, the complexifier (you know the type) ships rude goldberg gizmos just waiting to go off-kilter - and then they come in and save the day - and get rewarded. This creates a very strong "emperor has no clothes" syndrome until reality hits the organization really hard in the face. More often than not these horrible solutions are "good enough" and the show just goes on.
Don't take it too seriously! That's what people are like!
> The sad corollary to "you will be noticed only if you put out fires" is nobody actually realizes the elegant solution you shipped will stop tons of these fires from happening. Rather the reaction will be "that looked simple and easy so probably is not important".
Or that reaction is really "that looked simple, easy and like the last 10 "elegant solutions" that caused fires".
Also make sure to brag using terms that non-technical people can understand and want to hear. Less "we stopped writing an in-house CRUD that was Django but worse" and more "we saved months and increased security by adopting a market leading solution and it works better with AI too".
While probably facetious, those with power (who you aim to smear and replace) will save themselves and work together to fire you ASAP. This is not a winnable battle nor strategy for success, unfortunately.
This 100%. I once got disciplined for insubordination for skip-leveling my "manager" and disregarding their instructions when she started telling people on the team to work on something totally non-critical, when the team had a demo in a few days that wasn't ready yet, with a client that was already unhappy, on an 8 million dollar contract.
Basically build vs buy. The problem is on the 'buy' portion of looking at things the company failed. So they took who they had on hand and built something. It took a fresh perspective to say 'hey have you tried this' and looks like they did not want to hear it. I would say the right choice was made to move on.
This is wildly common. At that point they were committed to the wrong path at 'above my pay grade levels'. Once you get that buy in you better do it that way. Most companies will not pivot unless the champion for whatever is going on is removed in some way.
At 'my paygrade' I can prototype tech but I better make a good case why I need everyone else to do it too. If I dont I will be summerly ignored at best, at worst 'the guy with the lets rewrite the system hahahaha' guy. I might even be right about it. But the probelm is a jr level guy is not going to have the political cover to make it happen. Even if they are right.
But if you can get 'the higher ups' to buy in. Then it is quite dramatic how much better somethings putting that sort of tech in. Then other times it can be a total disaster. So you have to pick your hill to die on.
I can relate to this so much. When I was a newly joined Google consultant at a partner firm, we went to their office - some 13 different types of cuisines, different types of game rooms, lounges and what not. A luxury star hotel experience. We were waiting for our meeting on behalf of this one particularly large media client who was bleeding money on Wordpress.
3 engineers arrived - fashionably late. We explained them the situation and all we wanted from them was some GCP offering that would cure our woes and one that would cut our bills. The senior consultant - and presumably the only tech guy (rest seemed to be salesy) wasted our time like a used car salesman - he didn't even understand Google's own product portfolio and recommended us to use something like Spanner - which was totally not the solution to the problem, not to mention, expensive.
My boss and I left the meeting pissed off and he told me - "Neya, you probably know more about the product portfolio than these guys. Let's leave". That weekend, I went with my tried and trusted favorite Db - PostgreSQL - CloudSQL with a custom Elixir middleware based an old CMS I wrote a decade ago. After some trial and error, the solution worked flawlessly (and still does till date on auto-pilot). My client still has the lowest cost in the region - 1/3rd the cost of their competitors...7 years later. Back then, there was no vibe-coding, no AI, no auto-completion. Just pure thinking and experimentation.
All this just to say I agree that the new guy sometimes can make the best solutions to a problem and not always screw up. I always listen to new hires these days (now I'm a fractional / CTO) because you never know who could pull off that 1/3rd cost cutting framework move.
Sometimes those complex solutions are the right tool for the job. And other times, you just need to glue some stuff together, call it good, and start making money.
Experience helps a good engineer know when each approach is appropriate.
One day I'm gonna build some sort of product in Elixir. I was super interested in LiveView when it was announced and I think the component story has gotten a lot better than when I tried back in pre-1.0 days.
Definitely give it a shot. It's a wonderful language and the rewards are immense for the little effort you put in. I promise you, you'll never look back once you fall in love with it!
Hey, really sorry, I'm genuinely not trying to sell anything (I don't have a product to sell...yet). I can see why you might have interpreted like that though.
And it's unfortunately too late to edit my comment. I'll try to think less sales-y next time.
> Later my boss told me not to do that again because it caused havoc with schedules and such.
Did you talk to anyone about your plans before you brought in the demo or let them know they were solved problems? Often these sorts of reactions come down to your boss not wanting their team to lose their jobs because of the perception that it can all be handled by one person who's happy to work weekends.
I wasn’t politically savvy enough to do that. Honestly, I don’t want to be. The reality was that the project really could have been done in a month by a couple of people. It got turned into an enterprise project with multiple unaligned teams with Gantt charts and milestones and everything.
Again, and I can’t emphasize this enough, for a Django CRUD app. It was a 4 person-week project turned into a major ordeal. No one should have lost their job; they should have been put to work doing the thousand other more productive things they could’ve been doing instead.
> No one should have lost their job; they should have been put to work doing the thousand other more productive things
I think that's exactly why you should have talked to your peers and let them know they were solved problems, unless the overengineering was intentional.
Sometimes you can explain things and not be heard until you demonstrate them. Then they have to accept that you’re not just BSing, that your idea does have at least some merit.
Also, never underestimate an enterprise’s ability to convince itself that it’s too big and complex for off the shelf tools. Sometimes that’s the case. Very often it’s not.
In this case, I’d also watched this all take shape over a couple of months. Being the new person, I assumed it was some necessarily complex beast that was beyond my scrappy experience and calling for Serious Engineering. Once I recognized it for what it was, I knocked out my weekend project shortly afterward because I couldn’t get it out of my head. As much as anything, I had the need to see if it really was as straightforward as I thought it could be. I didn’t sit on my idea for months while they toiled. I watched them toil for months before I understood the core of what they were making.
> Sometimes you can explain things and not be heard until you demonstrate them.
1000%. In my experience this isn't even a "sometimes". It's the opposite. Explaining/arguing in the abstract why a significant directional change is needed has little persuasive power. If you can demo something, you actually have a fighting chance, even if it barely works. It can be a working product, it can be charts, it can be a semi-functional mockup, whatever, but you have to show _something_ that isn't just talking about it. I learned this the hard way after advocating for things and getting shot down too many times.
> Also, never underestimate an enterprise’s ability to convince itself that it’s too big and complex for off the shelf tools. Sometimes that’s the case. Very often it’s not.
Couldn't agree more with this, also. I've seen an astonishing number of homemade job runner systems, homemade message queues, homemade databases, homemade web frameworks, homemade languages, etc.
One can make the argument that this is how technical progress happens, and in some sense, that's true (we wouldn't have a lot of nice things if this never happened), but it's rare. Like, really rare. Most shops would be better served with e.g. Django, Postgres, and HTML, deployed on Heroku (or your Heroku-equivalent of choice) rather than spending hundreds of human-months building "an ad hoc, informally-specified, bug-ridden, slow implementation of half of $COMMON_OFF_THE_SHELF_TECHNOLOGY".
Wow, that just gave me a PTSD shudder. I started at one shop and they had a small team continually fighting against their home rolled message queue and task runner. After joining in the fray, asking about a million questions about why this is done like that, etc., I talked them into replacing it with a stock Python Celery setup. The original author of the local version protested, understandably, explaining why it couldn't possibly work.
It worked. It didn't require handholding. It continued working after I left there.
My coworker was a smart guy, but he got it in his head that their specific use case was something that couldn't possibly be served by a COTS project. Turns out, it could, and easily.
This story is more common than any of us would like to admit, myself included.
I can say this with some confidence because as a junior developer, I was often that person, and I didn’t really understand the collective lessons contained within e.g., Rails, Celery, etc.
I was enamored with doing something “cool” and “interesting” and I didn’t realize that this was distinct from and not actually as cool as solving someone else’s problem on time and under budget.
Easier said than done. If a company is in that situation already it's due to a reason. A new middle-manager would have a hard time convincing anyone, let alone a new IC. IMO you just go down with the flow and enjoy your new salary (which should hopefully be higher than the previous one) or start looking for your next gig
And it’s possible that it wouldn’t have mattered anyway.
I got a green light to do an integration in a week alone, which was planned for a team of 5 for half a year. We knew that it cannot be that much. So I delivered…
It was never used. It was purely political. The integration didn’t happen because it was “half a year”, but because middle management didn’t like the idea of integration for political reasons.
In fairness to Salesforce, it was the garbage third party apps in their ecosystem which got compromised and did the leaking, not Salesforce themselves.
On the other hand, programmers are happy to work with AI, which is incredibly limited and a pale shadow compared to the real "I" in educated and experienced meat brains.
Also, networking - in both space and time (among the living, the latter with the dead, one way from them to us) - is THE gigantic advantage of humans. Not to want to bother with it is an equally gigantic mistake, if you want to use being human to more than a tiny fraction of its potential.
If you are interested in creating solutions and useful systems, "politics", human networking, should be THE number one priority. Long before anything technical.
Important scientists and engineers were great networkers and communicators. They also knew which connections where worth making. Just like in the brain, fewer good connections are better than wildly cross-connecting everything.
What you’re saying is true. Yet, I can only willingly go along with so much terribleness before it hurts my soul. We only have so many days to do things we care about. The thought of throwing away 6 months of them for no defensible reason horrifies me, and I can’t, won’t, participate.
Edit: for a compensating control, I pair with senior leadership I can directly ask about this things. “Hey CTO, is there a reason we’re doing this thing so ass-backward? No? Can I go fix it then? Thanks!” Or, “oh, because we’re stalling to avoid this horrible customer’s demand, and no one’s really going to be working on it as their day job? Sigh, alright, I’ll look the other way.”
I let them be political so that I don’t have to be.
I'm not good at office politics, but I got better at not caring. Understanding what is erroneous stimuli, as an employee you don't have to respond especially if you aren't noticed. This is fairly easy for engineers, even lead engineers. Anywhere there is a buffer between you and other stakeholders.
Occasionally though, I do get thrust into it, mostly during a company pivot about something I wasn't hired to do. All the personalities to manage, I 100% fumble, but still deliver.
Omg! Who the hell cares if the "boss" got a heads up. When I'm in engineering or you're in engineering with me, we party the same way: better is better.
The bosses - hell management's job leading into organizational culture - is to stop politics from derailing good engineering and customer satisfaction.
It's not too tough for me. Now that you know where I stand the other side better get it's act together.
Drowning in politics helps nobody including the boss. It's a net loser.
Now I'm practical and empathetic: a surprise can bring heat. But then you breath and get a grip. Cool. But thereafter the right things better get done. Politics for a day - np - politics sapping know how making cynical SE'S think twice? Never.
I learned a lot from that job, mostly how not to lead people. Subsequent jobs that I’ve been at for longer stints have placed much more emphasis on delivering good work than on building complicated plans to someday hopefully maybe consider delivering good work.
Oh I have seen this story and was the one who caused this story when I was younger.
In a lot of cases the "new guy" thinks its an easy software and does it on his free time and thinks he did a great job.
In reality the specs are never 100% done correctly. The "new guy" misses some edge cases everybody but him knew because its just company knowledge. A lot of info in the specs was missing since they are not complete and so on.
This over the weekend never works in the long run. The ORM worked for all the happy path and written down cases but then you have cases were the ORM just is not good enough or fast. So you start to add strange code to work around the ORM. The same for the web framework or the validation lib.
To me the author of this comment sounds like the typical "Freelancer" coming in into a company knowing everything better then all the people and then leaving after a few months and now everybody else has to deal with his code.
It swings both ways though. I've seen plenty of older engineers dismiss the "new guys" effort and claim that everything had to be custom written, because there's no way a common framework like Django could cover their use case. The same type of engineer has never once worked with a common framework though, so they don't know what's included nowadays.
Turns out it's a lot easier to build on top of a common framework than do everything from scratch.
I think it's safe to say that ORM in Django is, in fact, better in all possible ways than an ORM someone at some company just wrote. Including speed and handling edge cases.
We only know what OP wrote and he doesn't sell himself as a genius but as someone who was competing with really, really bad ideas.
> Sometimes the new guy can make a better version themselves over the weekend, not because they’re a supergenius, but because they’re not hampered by 47 teams all trying to get their stamp on the project.
In 99.9% of cases what seems to be "the better" version is better only for the "new guy" or rather his ego.
Those 47 teams hampering doesn't necessarily mean a bad thing, and more often than not actually well justified "stamps".
You only understand those things when you turn from the "supergenius" into an owner who have to take care not only of numbers on screen, but also security, interfacing, management and so on.
That is often the case, but far from all the time. Other times something is made so needlessly complicated by office politics that it may never get shipped.
Not saying it never happened in history, but most of those "complications" are justified. Being narrowsighted and overfocused does not help to assess it.
Conversely, sometimes when you have 23 people designing something, they can lose track of what they’re trying to accomplish and focus on how they’re trying to accomplish it. It can be an XY problem sort of thing. “How can we get the Redis queue to do an exactly-once insertion into Kafka, if we can’t guarantee exact ordering from the Paxos framework?” “Uh, guys, aren’t we trying to send out the weekly email newsletter to our estimated 500 subscribers?” “Oh, well, I guess we could just use Mailchimp…”
Like I said earlier, it’s ok not to believe me. I don’t particularly mind. But just between us, my solution met every one of the project requirements using COTS parts because they’d made it waaayyyy harder than it needed to me.
Nothing personal, but our conversation reminds me many similar convos I had with developers who thought their product was superiour - but they could see it only from their angle. And it was superiour - but again, only under narrow view.
Not saying you're wrong in all cases, but there are enough examples of hugely expensive megaprojects which totslly tanked, which would have definitely been much more successful with OPs approach if executed correctly. Not saying they would be done and done within a weekend, that's silly. But the alternative, poorly defined integration interfaces, multiple contractors, multiple stakeholders with conflicting requirements and zero (real) regard for the user is unfortunately fairly common, both in public (city/regional/government) and private bureaucracies.
The examples are legion, and they always seem to have NIH and baroque requirements, and be rather over- than underspecified. I would go so far as to say that these projects are almost never successful (and definitely never on time and budget).
Take this idea and bring your own validation library and forms and UI components to the next job, and you've described what I do. And then you have real lock-in.
Hahaha. I'm not above that kind of work. Sometimes having a consistent codebase for both things comes in pretty handy if you need to tie em together or just need to spruce up the CSS every few years.
I don't intentionally make my work hard for anyone else to maintain. I comment and write tests pretty thoroughly in case someone else comes along. Or in case I get woken up at 6am with a bad hangover.
But I don't think Claude Code is going to prevent an org that thinks they can prompt their way to a replacement for all their SaaS from having internal political bickering that makes them end up with a extra-shitty mega-compromise to try to make all the internal stakeholders happy.
If you've got no vision and no taste, you need to find a vendor who will protect you from screwing up your internal processes and tools.
Internal tools teams have rarely cared much about UX or the day-to-day experience of their poor users. The quick-and-dirty internal-prompt-based one is likely to similarly be unimaginative and unintuitive.
Isn't this agreeing with the parent? If Django were the B2B SaaS product, you didn't vibe-code Django, you just used Django. You aren't responsible for maintaining Django itself.
Django wasn’t the product here, though. I used it as part of the toolkit to “slap something together in one weekend”, and that something was the (actual real life) B2B SaaS product, or at least the user facing interface to it.
I once worked on a project that was a new sign-up process for a large retailer (~90k employees at the time, four figures worth of outlets, quite a few billions in turnover).
There were about 60 people across, I can't even remember, maybe 10 teams that I knew about. One of the managers there assured me that the true participant figure was closer to 160. I was agog.
This project took months, and it had been going for months before I joined. And, as you can imagine, with that many people involved over that sort of timescale, there was turnover: people, sometimes key people, would leave and be replaced - sometimes by others who'd already worked on the project, but sometimes by new people - with the expected disruption that causes.
It was two web pages, plus some back end plumbing across multiple systems.
But, in the grand scheme of things, nothing that complex. I reckon it was a handful of thousands lines of code total across the full stack. I was mostly on the database side and, IIRC, I wrote a few hundred lines of SQL in a couple of stored procedures (wouldn't have been my preferred solution building from scracth but, you know, we weren't, and we had to integrate with a legacy systems that had to keep working as expected).
Overall it took 8 or 9 months from kick off to shipping and I was involved for perhaps 3 months of that towards the end. I was on the call with dozens of other people whilst me and one of the other guys hooked the final pieces together and tested it end to end for the first time... and it worked. There was actual cheering.
I had a similar experience where someone that had prior experience with django while we were using sqlalchemy started to design a django-like ORM on top of sqlalchemy.
Of course it took him some time to get working, was a hell to understand and extend and most importantly lacked support for basic features.
Fortunately it was limited to a small isolated service but I can imagine the damage on the long term if you continue that route on what becomes a huge monolith after a few years.
I was complaining about SQLAlchemy's insane quirks to a group from my alma mater and one of the grad students said, "Well, the solution to your problem is clear: Write your own ORM." and I had to explain that this startup does not want to get into the ORM-writing business.
I freaking love SQLAlchemy. Those quirks once let me build a sane API on top of a legacy database (ported from Visual FoxPro hourly using a program I also wrote for the task). Some of the fields were values in an XML doc shoved into a DB column because the original programmer thought that was a good idea at the time. I wrote indexes and virtual columns that let other devs query those fields just like everything else.
It has its edge cases, but Alchemy is the greatest thing in the world when you need its exact features.
But yes, I’ve used that line plenty of times: “we’re not in the X-writing business”. I mean, sometimes you can’t help it, but those should be exceedingly rare cases.
Also, some people want to work on what's already familiar to them. If building a framework from scratch is what appeals to them, they'll do that even if a framework already exists. Busywork to look productive.
I resonate strongly with this story. I’ve seen three people teams get in one month where SAP could not in year, and also let and witnessed incredible number of total fakers in SaaS enterprises.
Big corpo may be too big to fail, not so sure about their whole cohort of partners and fakers.
We are certainly closer now to being able to prototype and go to market faster with a product. In one weekend is a little much but I think its hard to deny that building will continue to expedite. What most developers don't think about is that the marketing, sales, customer service are all non-trivial parts of the business/product and all require legwork that is more than just sitting at an IDE. The nail in the coffin is that the data is a large part of company moats, and new products need time in the market to get that. Migration is also a long process and risky...so to get customers, a newcomer needs to provide way more value than what the incumbent gives.
I imagine you're going to have people trying to automate the whole GTM lifecycle, but eventually the developer that thinks they can bootstrap a one man enterprise without actually doing any kind of social interaction will run into a wall.
The "service" part can still come from internal sources. Plenty of companies have internal support for internal tooling. With a good foundation of infrastructure and a lean team that knows how to build, not just vibe code, there is most definitely some ROI there.
But yes, this brings us back to the point that simply building the tool is only a small part of the process...and it has often been one of the most expensive parts of the process.
You build a Twitter. Profiles have posts, posts can have images, etc. It's very easy to model the database.
But then how do you make money with it? Now you need to build a separate system for advertising? Or do you want to sell subscriptions? Which means you need to build a separate system to handle payments. This is usually the big one, because when you handle money, what happens if there is a bug and you charge someone without delivering anything? How do you prevent fraud? How do you handle disputes?
Someone posted something illegal. What do you do in this situation? Do you call the police? The FBI? What kind of data do you give the authorities? How much data SHOULD you have been logging in the first place in case something like this happens?
One user doesn't like you so he bought a botnet to DDoS your website. How do you handle this? Are they mass posting? Mass creating accounts? Is it possible for them to exhaust all the usernames possible and then nobody can create an account anymore?
Your website is online but if the server blows up you'll lose all the data in the database. You need backups. You need a system to ensure the backups are actually working. But then some guy from the UK said he wants his posts all deleted. What are you going to do now, because his posts are also in the backups, and you don't want to touch those.
Trolls are posting things against the ToS. Who handles these things? Shadowban? So there needs to be a shadowban system? Moderators? So there needs to be a moderator-only section of the website? Should this be integrated with the main website or not?
Then you look at this horrendous mess of 6 paragraphs and you think back about the first paragraph that already did everything you wanted from Twitter. All these other systems, most of the work, and all you actually wanted was the first paragraph.
Startups have no users and no data to start with, and if they fuck up security, well, they just fail sooner than expected.
Once you get past a certain size, you have very different sorts of problems. Any idiot can vibe code a facebook lookalike, but the real one has to handle hundreds of millions of users and posts while being a target for state actors.
There's a difference between someone breaking into your house to steal your valuables, and you getting robbed after leaving your valuables on your lawn with a sign saying "Look At My Valuables"
Startups of the last decade were routinely doing this. Building their fresh ideas on the newfangled databse without bothering to investigste how to secure it in any way against malicious actors.
I think that just because anyone can do it, doesn't mean they will. Lots of people have really great ideas but very few actually commit to execution. Ultimately ROI will go down, deincentivizing the commercialization of that thing someone wanted to bang out in a weekend.
In the very long term, software will become a commodity, as you mentioned. Process and workflow may move into JIT delivery for the need at hand, in theory the data layer will be comprehensive and clean and the days of clicking around a bunch of stuff to fulfill process needs will move into a lower latency activity like...talking to your agent.
I saw a quote today by Brian Eno(1995) that said: "So the question becomes not whether you can do it or not, because any drudge can do it if they're prepared to sit in front of the computer for a few days; the question then is: of all the things you can now do, which do you choose to do?" and it resonated with me a lot.
> Lots of people have really great ideas but very few actually commit to execution.
This is true when you had to work hard for those ideas. Now you have LLMs. It means more people can sling a lot more crap at walls with fewer barriers to entry.
No, and I agree with the conservative sentiments here. However, putting together a SaaS alternative that frees up money during a crunch, and now with the pet features your boss has always wanted, is potent indeed.
You've hit the nail on the head. Immediate gratification.
AI is like sugar. It tastes nice, gives you energy quickly - what's not to like?
The gratification is immediate, and if "today is all that matters" it's brilliant.
The problem with sugar (and AI) is medium term. So sure, that junior dev whipped up the whole framework in ClaudeCode, and it's humming nicely. Junior dev gets credit, and after a couple years moves on somewhere else.
Then something changes. Windows. TLS. Code Signing, whatever. We need to update the program to the change. Just a small tweak. Junior Dev has gone (or is otherwise occupied) so we'll get new-Junior-dev to do it. Is he expected to do the change at the code level? Or at the prompt level? Will ClaudeCode in 2029 be able to maintain ClaudeCode Code from 2026? Or will it want to rewrite everything? Will new-junior-dev have the skillset to prompt as well as first-junior-dev? Was the code good enough that a dev could just "take it over"? Or was it "it works, let's use it" standard?
AI makes everyone look good in the short term. But it worries me for what happens in 5 years, 10 years, and so on.
Sugar is great, but you can't live (long term) on sugar. Sometimes you need a proper meal plan.
I think my point is that not everyone is suddenly going to go and start making stuff. There will definitely be an increase, which is a net positive because we can start exploring unknown areas of interest more rapidly, we can fail faster, etc. Fewer barriers to entry will increase competition, lower prices, increase efficiency, and theoretically benefit the consumer.
okay, what was the actual obstacle? it's really simple: in order to use something FREE, you had to touch GITHUB, which meant GIT. and people hate git.
today, with LLMs:
- "can i do this for free?"
- LLM dutifully does the needful, using projects it finds and code it learned from github, and doing the prosaic tasks of launching them for you, whatever that means.
people are getting way up into their heads about what matters, psychosocial and management and whatever bs. chatgpt is FREE. it will fix your problems for FREE. people will put up with ANYTHING for FREE.
the real innovation is laundering all that inaccessible, pre-existing solution space into a format that doesn't require transiting git and giving it away for free.
don't believe me? all of the most profitable SaaS businesses in technology are the packaging, deployment and customization of pre-existing open source free software, whether it is linux, kvm, postgres, etc. they are factories to turn stuff that is inaccessible because it is in GIT, which SUCKS - that is the hard part for people to wrap their minds around, that GIT sucks - into websites you can pay for. now LLMs do that.
Exactly. Once the market tastes like lemonade, everyone will be afraid of trying new apps in the way that they are afraid to accept phone calls from unknown numbers now.
You will trade initial development budget for advertising budget, trying to position your product in proximity with people who are known quantities.
Tbh I think you’re fundamentally misunderstanding the issue (or I am).
It’s not about some single dude disrupting the saas market. It’s about largish companies who already have internal dev teams, slowly weening their company off these ginormous one size fits all saas products and building local, tailored solutions.
It’s death by a thousand cuts from the erosion of their highest paying customers.
I feel the market forces kinda point the other way, though, since the customization of the SaaS is also cheapening, but faster and more targeted than these internal teams. Over time I believe that’ll lead to more, not less, SaaS consolidation.
Let’s put the cost of code production at 0: regulatory compliance with payment processing laws or industry oversight is a recurring job that’s common for the whole industry when it changes. SaaS companies have hundreds of customers to attend, these become first class business functions. New demands won’t be in training data for LLMs, so someone needs to be doing this. SaaS has the funds and customer base to have dedicated experts at these functions, but it’s dead capital and nigh-impossible hiring in a tiny talent pool for the rest of the market… the delta to get Salesforce or SharePoint not to be total ass and fully customized is orders of magnitude smaller than detailing those foundations, and as people who sharecrop on platforms like those know, the devil is always in the details. Those internal teams just aren’t positioned to juggle both sides of that coin, they can’t be experts, mistakes can be existential, and the liability picture is so very ugly… coding is the least of it.
Into this, MBAs are not static. It’s not gonna take more than a few “vibe coding ate our CRM data” high profile snafus, or industry think pieces to map out why customization is faster/better/smarter, to get clear business dogma around this. A witty turn of phrase about focusing on your actual business.
I think ‘no one ever got fired for hiring IBM’ x 5 is on the horizon, and the evil marketers at Salesforce, MS, and the rest are gonna work hard to grow their piece of the pie. They have LLMs too, only with better models and unlimited tokens. And our executives will be checking directly with their LLMs about how to invest (the consultants, journalists, fanboys, and social media bots too…).
in the 90-ies anyone could easily prototype with tools like Access (and all the other "4GL" tools which were similarly all the rage back then). That still didn't preclude companies from buying their major software from software vendors instead of doing it themselves.
In some sense having customer able to prototype what they want is a good thing. I did it myself as i was at the time on that side, and having a quick-whip-it tool was a good thing to quickly get some feature that was missing in the major software before that major software would add it (if at all).
(And if one remembers for example Crystal Reports - while for "reports", it and the likes were in many senses such quick-whip-it tools for a lot of such customization that was doable by the customer.)
So, after initial aftershock - "Ahhhh, we don't need software companies anymore!" - we'll get to the state with software companies still doing their thing just with a lot of AI as specialization is one of the main thing in modern economy and AI becomes most powerful tools of the trade. (and various AI components themselves will be part of software delivery, like say a very fine-tuned model (hosted or on-premise) specific to the customer and software - Clippy on steroids)
(Of course some companies wouldn't survive the transition just like some companies didn't survive the transitions to client/server, cloud, etc. while some new companies will emerge like Anthropic has today or Borland had at the time)
Access is not as dead as you might hope. The long tail of internal tools written with Access continues to shamble along. I had to figure out how to dump MDB files on Windows last year for just this reason. As an industry I think we often fail to grasp how much outsider art there is, in the form of internal departmental tools.
LLM coding is going to create a cambrian explosion of these tools. It’s going to be very interesting to see the remnants of this wave 30 years down the line.
One of the key questions here - will LLM coding decrease the proliferation of app-specific Excel files (by for example accelerating and simplifying Excel-to-webapp conversion) or would result in an opposite outcome by making feasible managing even orders of magnitude more of those disparate Excel files :)
I wouldn’t bet against cramming more and more business processes into Excel. The guy who was copying cells from one workbook to another yesterday, tomorrow can have a single mega-workbook with all the macros more or less deconflicted.
The history of software has been that once it becomes cheap enough for teams to flood the market with “existing product” + x feature for y users. The market consolidates around a leader who does all features for all customers.
I’d bet that we skip SaaS entirely and go to Anthropic directly. This means the ai has to understand that there are different users with conflicting requirements and that we all need the same exact copy of the burn rate report.
That might turn out to be less than reliable over time, as bots are already screwing up systems with fake information and it's probably going to get worse.
I don't disagree with that, but the market for lemons still doesn't really fit.
If I remember my econ class correctly it uses used cars as an example. If you're neighbor bought a used Toyota and tells you about it being a great purchase, you can't go out and buy another used Toyota and expect it to also be in great condition. Every car is a gamble.
But if you use something like Hubspot and tell your neighbor it's really good/bad you can expect to receive the same Hubspot service they did.
If you can gin these things up in a weekend then why would you bother with a monthly subscription model for software? The only valuable part is the specification and possibly the hardware to run it. If I were a CTO trying to save money I might pay for the labor to develop good specs, but I would prioritize getting out from under software companies with a rent seeking models and 80 to 90% margins
Even if AI were erased today, most SaaS companies wouldn’t exist in 5-10 years. Doing business with a small tech company that could run out of borrowed money or sell to someone who will destroy the product or just arbitrarily change the terms of service tomorrow is a liability. That’s assuming the hypothetical tech spend isn’t just eroding margin anyway.
On prudent choices: one thing I'm surprised about is that LLMs are showing me libraries and tools that I'd not found via search.
A boring one from today was about select, datalist or some custome element (which LLM can prototype) or some JS libs. Good breakdown; links to playgrounds, rough mocks so team could kick tires. It raises points the team had and had counterpoint to help drive decisions.
it depends a lot on the application, I think, though certainly you can point to cloud services like Cloudflare or whatever Burger King was using to track how many times a clerk said "You Rule" (while capturing all customer audio data, which was then stolen by low-effort attackers) as high-risk; just because you don't feel the safety risks of outsourcing data to a black box on the cloud doesn't mean they don't exist, it just means you get to neglect them. when I headed IT at an SMB, I was given a lot of leeway, and our department had its own budget, so cutting out SaaS was a high priority so we could do more. if I were heading today with LLMs' present competency, I would have replaced much more, up to and including Salesforce which was draining the heck out of our budget despite us not doing anything technically interesting with it.
$40/head/year (including employees no longer with company) for a call metrics suite is low-stakes and relatively easy to replace what we want out of it, and this is an example of something we did replace with a $0 solution with my own abysmal-at-the-time coding skills. ~nobody's about to replace Microsoft suite, though (a couple replacements before me, they earnestly tried; there were still some laptops with OpenOffice on it; I admire them, but I'm not dealing with our sales team trying to figure out what an ODF is).
I love this "petty kingdom" budget model, by the way, as someone whose work personality could be described as "cheap analyst." I'm paying $40/month per head for Software X in your department, and I have an inferior replacement for $0/month/head which meets specs and which you can't quantify productivity loss for (essentially, it just looks ugly and feels bad). I can therefor cut that out of my budget entirely while meeting my obligations, and if *you* really want the decadent solution, *your* department can bear that cost. Either way, I get plenty more money to basically not have to be a dick (like charging careless employees for broken/stolen equipment, or getting an above-expectations solution for ADA employees); and sometimes, maybe some antennas show up on the roof which would be difficult to justify cost for if asked, but I'm way under-budget so nobody would.
It means the same: random lottery of mass, with everuone else failing.
American capitalism hides the depressing fact that rarely does the best succees.
AAI momentum is parallel to just buying lottery tickets and doing so with the belief that you know the real odds, so one can overwhelm with quantity of tickets.
I sure hope I never have to hunt down any GTM options myself soon and I can tell the AI to do what it should be doing. However AI adoption may be getting slowed down by profit motives because what Google should have already been doing is letting me git clone the entirety of GTM with all its configs to a local folder so I can treat it like code because it is code. The difficulty with AI adoption will be to make all products be like this so they can interact on a code level instead of me having to press buttons in different UIs to make thing shappen. E.g cloudflare should be letting me git clone its entire config, everything I did in the dashboard, to my folder too.
It's shocking to me how prevalent this "who needs Salesforce when everyone can just vibe code their own CRM from scratch in a day" narrative has become in the business press. Like, what???
I've had a pleasure of using GIMP recently on Mac. One of the worst UX/UI experiences I've had in quite a while. If that's where vibe coding leads to, then Photoshop is very safe from disruption.
No, the equivalent question that people are seriously asking is "Who needs Photoshop [or graphic designers] when everyone can just vibe paint their graphics with AI?"
Yeah I know a friend (small business owner) vibe coding a feature as a addon for Odoo. He has dreams of selling it (he usually has wild plans), but for now it's just a feature they want and does seem to be good enough for their use.
And the Google AI subscription is cheaper than any of the SaaS offerings.
I don't think vibe-coding will replace anything. However, what if AI tools can make skilled developers more productive, particularly at simple tasks in unfamiliar environments? You could see that reducing the engineering costs of simple utility applications. There are tons of pitfalls that many here have pointed to but also maybe opportunities to do things that wouldn't have been cost effective.
Also: In my life the easier it has gotten to create and run software, the more software people have wanted and the more they have been willing to spend on it.
> I don't think vibe-coding will replace anything. However, what if AI tools can make skilled developers more productive, particularly at simple tasks in unfamiliar environments?
That's not good enough.
Now that the world has successfully laughed off the "our models are so good they're superintelligent" AGI claims, AI companies and investors have moved on to the "our models are so good they're going to do all your workers' jobs" angle.
The insane investment is for AGI/total job replacement, not developer productivity tools. We are going to be sold pie-in-the-sky claims for a long time until the world wisens up to this rhetoric the same way we did with AGI nonsense.
People really seem to believe that code is the only thing you need to make a SaaS company. It's like thinking a line cook is all you need to open a restaurant. There are so, so many other components to running a business.
I don't think it will replace SaaS but I do think it can replace the need for a lot of the consultant work that goes around configuring and integrating the SaaS. It will be much easier to have a spec that defines how things need to be configured and the machines can implement it (using the SaaS as tools). Frankly this is the most annoying part. It's not that the B2B stuff can't do whatever, it's that it never gets implemented in ways that aren't a pain in the ass because it's all handled by people who aren't actually using them.
I really don't think it's not going to become "these prompts are specs" and then you have processes of reviewing implementations. It's one thing when you have randos building stuff and they leave etc. Having stored prompts and managed code that uses tools is a different beast.
In my experience this isn’t the case. SaaS systems, at the least the ones that are embracing this sea change seem to recognize that connectivity is key. They are opening APIs and partnering like we’ve never seen. They lack the domain expertise and resources to plumb the last mile. Companies can finally customize and integrate there core SORs at a reasonable price point and if you hire the right people decent technology. It’s a golden era, I do wonder if you’re correct medium/long term but the lack of skill sets to build, deploy, and maintain these solutions is very real. Many can vibe code a great looking app, very few can support it day two even for just a few hundred users.
No serious programmer "vibe" codes. I admit creating SaaS may not be feasible with current infrastructure but you can't ignore the insane jump in productivity that these tools can offer with the right scaffolding.
What I struggle with is developers wanting to leave platforms like Datadog for open source equivalents that need to be self-hosted.
I hear all of the cost savings benefit, but I never see the team factoring in their own time (and others time) needed to set up and maintain these systems reliably long term.
Something IC’s at company often struggle to understand is the reason why companies often prefer to buy managed solutions even when “free” alternatives exist (read: the free alternatives are also expensive, just a different type of cost)
My log bill for Google cloud log would be like 30k. For splunk I like 80k. I self host for 1.5k per month. Spend maybe an hour a month? Easiest money I ever made.
When you’re in the middle of a production down event and your whole team is diagnosing the issue, and your log server is unresponsive, who do you contact for support?
No one, you pull an engineer off the production issue to debug the log server, because you need the log server to debug the production servers.
See the problem?
Edit: to be clear I’m no fan of Datadog and I wish self hosting were an option. I want this path for our company, but at least on our team we just don’t have enough (redundant) expertise to deploy and manage these systems. We’d have to hire an extra FTE.
If you’re having a correlated outage like that, then it’s likely you fix the prod issue before the cloud engineers at some giant cloud company even respond to an internal escalation much less fixes an issue. More than likely your prod issue is causing the logging problem.
If you mean you are experiencing two totally unrelated issues at the same time, then I don’t think that’s a reasonable thing to really assign much value to as it’s incredibly unlikely.
Half of $30k/mo trivially pays for an engineer you hire to only manage such a cluster for you and just works an hour a week unless a pager goes off if you truly need that level of peace of mind. If you’re hiring for such a position I have a few rock star level folks who would love such a job.
The hypothetical problems people imagine for on-prem infrastructure get really strange to me. I could come up with the same sort of scenarios for cloud based SaaS infrastructure just as easily.
> I don’t think that’s a reasonable thing to really assign much value to as it’s incredibly unlikely.
In my experience the systems/tools needed to debug production issues are often only used when they’re needed.
Which now means you need health and uptime monitoring on your log server since without that, it might break randomly and no one notices until you need it.
> The hypothetical problems people imagine for on-prem infrastructure get really strange to me
It really comes down to the people and whether you have the expertise on the team. And whether the team can realistically manage the system long term. It’s typically safer to spend more money for the managed service.
100% agree. If I am using a cloud log provider I wouldn't expect them to solve my logging issue(s) as fast as I need, more importantly I have no real way to put more resources on that fix.
More importantly, with a third party service I'd be very surprised if both went down at the same time and it wasn't a further upstream issue like AWS. If its my own logging service and it went down during a prod outage, I likely didn't properly isolate my logging service in the first place.
> Half of $30k/mo trivially pays for an engineer you hire to only manage such a cluster for you and just works an hour a week unless a pager goes off if you truly need that level of peace of mind. If you’re hiring for such a position I have a few rock star level folks who would love such a job.
Yep, absolutely. I’ve come up with the term “man on the mountain” for such positions.
It’s when one person is exceedingly talented at exactly one thing - but isn’t exactly a typical employee who is good or interested in doing much else other than keeping that one thing online and reliable.
Their job is to go live on their mountain for weeks or months at a time without so much as doing anything other than keeping their phone on and answering it within the first couple rings regardless of when called. If they are good at their job you likely don’t even need to call - they already know it’s broken before you do.
I’ve employed a few such folks over my career. They tend to be the “alternative” style candidate - exceptional people with exceptional flaws. They love the simple tradeoff.
That said of course this is ignoring bus factor and overly simplifying things. Typically this is one deep subject level matter expert who sits off on the side of a small team, so there is at least one “understudy” hanging around as well.
I still advocate for such positions when they make sense though. I would much rather in-house my own “insurance” vs overpay some giant company for each month only to find out the insurance didn’t exist when I needed to make a claim. It’s certainly more risk to my career - but I have very strong feelings that as a manager or executive my job is NOT to cover my own ass because it’s easier.
The old argument for being locked in to legacy software costing 6-8 figures a year was that you had no choice. Now you have a choice! Clearly that is better, and everyone should evaluate that choice on its merits, and the stock market sees that people are voting with their dollars. If your whole sales pitch is "good luck when it breaks!" you might want to reevaluate your business model.
The stock market is trying to predict that people will vote with their dollars in the future. I’m not quite sure people are really replacing enterprise Saas at large corporations yet. It’s more of a projection.
Fair, however at some point of a companies size/spending the complexity of integrating with a SaaS becomes as large as the one to run your own open source tool.
Beyond that, and Im aware this is very much application/company dependent, theres plenty of SaaS companies that offer horrendous or no support no matter what you pay. We used to use splunk for monitoring and logging. Paid a ton of money because we were handling financial data and needed tracibility and reliability. We constantly had to put out fires that were caused by their unreliable platform. It was not a good experience.
Ultimately, we jumped ship to Prometheus. We pay a fraction of the price and spent less time on it.
The problem is all these SaaS companies have cut costs so much that all their support has been reduced to useless offshore at best and at worst a chatbot. They do go down and don't work and often times there's simply nothing you can do. The worst offenders will seize upon the moment and force you to upgrade a support plan before they will even talk to you, even if the issue is their own making.
Unless you're a huge customer and already paying them tons of money, expect to receive no support. Your only line of defense if something happens and you're not a whale is that some whale is upset and they actually have their people working on the problem. If you're a small company, startup, or even mid-size, good luck on getting them to care. You'll probably be sent a survey when you don't renew and may eventually be a quotient in their risk calculus at some point in the distant future, but only if you represent a meaningful mass of customers they lost.
> The problem is all these SaaS companies have cut costs so much that all their support has been reduced to useless offshore at best and at worst a chatbot.
Tremendous opportunity announcement!
If you are building a dev-focused SaaS, treat your support team exactly as they are: a key part of the product. Just like docs or developer experience, the support experience is critical.
Trouble is, it's hard to quantify the negative experience, though tracking word of mouth referrals or NPS scores can try.
Do they actually not understand that? They might just be fine with a system that makes them more useful.
How do you calculate the time spent on an internal tool like this, actually? (I’ve never been in management). Realistically your team inevitably will have some downtime, maybe some internal tool maintenance can be fit in there? I mean it obviously isn’t fully “free” but is also shouldn’t be “billed” at their full salary, right?
> How do you calculate the time spent on an internal tool like this, actually?
In broad strokes there's two ways. You can count it as an operational expense, or you can count it as capital (this takes more work to do but can have some advantages). If you count it as operations, it's just a big red pit you're throwing money into that you hope is offsetting a larger operational cost somewhere (but this can be hard to quantify). If you count it as capital, you're basically storing all of those hours as an "asset" which then loses value over time (it's kind of like the charge in a battery). The problem is you have to be able to show that this internal tool would, in the case of an acquisition or liquidation, be valued by the new owner at the value you're setting it at.
The problem there being that people are even more hesitant to trust somebody else's internal tool than they are to trust their own internal tool, so I've seen multiple managers think "I sunk a million dollars into this so it must be worth something" but in fact they were just running a jobs program for their team.
> Realistically your team inevitably will have some downtime
What? My team wouldn't have any downtime even if we had 10x the amount of people.
If you work at a company where you have times where you don't have work to do, you should polish your resume because it means the company will go under.
Doing work is easy, not doing work is hard. It's trivial for any engineer to find stuff to do. The trick is doing the right stuff. Most software is bad and clunky, most requirements are wrong, and most of your customers, at best, tolerate your product.
I think most software companies need to be doing less. Deleting code, refining, and making their product genuinely useful as opposed to "able to technically contort to client needs".
>the free alternatives are also expensive, just a different type of cost
Not if you hire reasonably competent people. These days for vast majority of FOSS services all you need is an ability to spin up a VPS and run a number of simple Docker/Podman Compose commands, it can't be that hard.
Only if your company already is lacking in the domain of competence of your engineers. If that is the case, either you have bigger problems to worry about, or your product probably isn't impressive enough to begin with to warrant an addition of complex, enterprise-grade SaaS tooling.
I'm sorry but the amount of companies that need something like DataDog is quite small compared to their 30,000+ customer count. Maybe 5,000 companies on Earth truly need something like DataDog, 80% of their customers would be perfectly fine with a self hosted instance of grafana.
Using an open source self hosted solution should be the industry standard, encouraged position, by default. Our industry does not gain overall from using DataDog but only from truly open source solutions that utilized AGPL licenses that allows everyone to move forward together + share lessons together + contribute together toward a common goal of better observability.
Why are we acting like it's hard to set up? This isn't the 1990s, it's 2026. Tooling has gotten quite good over the last decade.
Also corporations stupidly spend money all the time, they over spend too. I recently left a company that was paying SalesForce $10mil a year in licenses when only 8 people in the entire 3,000 person company was using it. I doubt that was the only single instance across our industry too. There is a massive amount of waste and graft in enterprise sales.
I honestly doubt it if you replaced grafana for 10,000 DataDog customers they would notice the difference.
Because the current generation of “full stack” engineers are great at spinning up react apps, but struggle with infrastructure and systems management. It’s really not any more complicated than that.
On a typical 8 person engineering team, maybe 1 or 2 people will know how to deploy anything to the cloud if you’re lucky.
Expertise isn't there because people are outsourcing that sort of work to companies. I didn't know how to do much of anything, until I had to do it for work. Then learning everything became way easier.
Surely all the engineers that existed 20 years ago haven’t simply retired? At the time if you told someone you couldn’t set up your own server they’d ask you what kind of engineer you are then?
> Surely all the engineers that existed 20 years ago haven’t simply retired?
20 years ago we had 5 times fewer engineers. And most of those have moved into management, other fields, retired, work calm jobs for the government or boring companies, etc.
How many 40+ year old engineers do you see, especially when compared to 20-30 year old engineers?
My experience matches that of cj. In fact, if you do mention anything outside the walled garden, you'll get weird looks and someone will ask "Why?" like you are going down a dangerous path.
Come to think of it, they are right. Why take all this ownership when it's the company that is going to pay for all of this and you can push these responsibilities to some third-party overseas.
& the counter-argument is those SAAS apps being killed by A.I are growing revenue 20%+ YOY
people who write this BS - one never don't understand SAAS fundamentals, they only see what's on the screen and forget the complexity that lives on the backend - forget the costs of running such a SAAS
before it was low-code will kill SAAS, then Visual UI builders, now its A.I
just like it was before that crypto will kill Trad-Fi
people who say these things - have tied their identity into it so they whole-heartedly believe the bullshit they say even though reality doesn't match
to anyone curious read the 10k (Annual Report) of any public SAAS - Salesforce | Workday etc - people should admire these companies for the machines / ecosystem they built - and also learn the good & mistakes to avoid i.e the bad
those annual reports tell you how the revenue generation machine works, how much revenue is expected 2+ / 3+ years from now - their weaknesses | headwinds and also tailwinds - how those companies grow and continue to grow etc
SaaS companies are effectively both "software maintainers" and "price gouging middlemen" at the same time. The difference between the bid and the ask for SaaS is part of a simple math problem for whether the company should try to create their own version of the software they need. It may be the right decision, it may be the wrong decision, but it will be the right decision for a non-trivial number of firms. And that means SaaS businesses will both lose customers and have downward pressure on their margins. That means valuations of B2B SaaS firms go down.
My career occupies a weird middle ground where, for 20 years or so, I've catered to smaller businesses that need bespoke solutions (because the SaaS available doesn't conform well to their business logic), but don't have the scale or desire to build and maintain software in-house. Sometimes these are slapped together in a weekend, if that's all that's needed. But in most cases they still become ongoing improvement and maintenance projects for me.
This niche position has had some interesting ramifications for them and for me. They clearly incur a lot of technical debt once their business relies on bespoke software. On the other hand, they own the software and can get an immediate response or new feature or upgrade from me, limited only by my time. And in the end, this ends up saving them time and money. It gives me a permanent and unending flow of work. But if I die, they're pretty screwed.
One reason I don't vibe code things even now, even simple components that could easily be vibe coded, is that I remember and know where everything is, every function or line of code that might be causing issues, because I wrote it myself. I know right away where to look for a query that might be throwing errors after a database upgrade, for instance.
As a manager I assume you would probably not want to go down the road of hiring someone like that, but for companies of a certain size it's an acceptable compromise. However, I wouldn't want to hire someone like that myself unless they were extremely reliable and didn't rely on AI to write any of their code.
People sometimes fail to appreciate the value of KNOWING the system inside and out when it comes to diagnosis and troubleshooting.
Observability is great, dont get me wrong, but past 3 to 6 months of work on the same thing...I can almost beet the observability tools in timetoresolve.
This sounds great if you get on well with your clients. You must be an effective networker and at sales. How do you bill, and how do you price your services?
I bill quarter-hourly at $300/hr for actual time writing or evaluating code. Phone conversations are free, and I take time to evaluate and explain what I'm doing before clocking in. The downside to this is that I make myself available 24/7 should any issues arise. I also don't necessarily charge for hunting down network issues or bugs (because I also host some software for clients). It works out to a good income for 80 hours a month or so.
I'm terrible at sales. My clients have only come to me by rererral from other clients. More than half the time, I'll tell prospective clients that there are already SaaS solutions that would be better for them than building something bespoke, and help them find solutions, because I don't want to do work that's already been done.
It seems that current advantages would compound with AI. I.e., if I am making a SaaS for Popsicle stick makers today, why I am disadvantaged with AI vs a new competitor in the space? I guess the hypothesis is the Popsicle stick maker will vibe code all of the software that they need instead. For that, we need significantly better AI than we have today - perhaps something like a 1000X improvement. Basically, this is a world in which non-technical grandparents can vibe code anything that they want. This means, it understands what you want without you being able to articulate it well in the first place.
So, within months your prompt can simply be "increase NPV" and machines will do the rest? If not, what prompt will work perfectly in your estimation by the end of the year?
How detailed are the business requirements however? "Increase NPV" is certainly a business requirement, albeit a very abstract one. "Add a checkbox to this form" is another, far more concrete business requirement.
I suppose it is really only possible to know how close something is until it arrives. When I type in "Maximize NPV" into Codex / Claude Code, I feel like it is incredibly far away from full autonomous capability. I guess we will see.
"Maximize NPV" is exactly what shareholders prompt boards of directors with. Not all humans can do it, but some can. Perhaps your argument is that AGI isn't required to solve software. This would imply that human level intelligence isn't actually required today to build software.
I don't do tea leaves so I wouldn't commit to that, particularly because I think SAAS was oversold in general even before LLMs came out. But I think the idea that the industry as a whole will shrivel away just isn't feasible, even if there is a correction.
The B2B startup motto of "where someone is using Excel to do something other than accounting, there's a startup waiting to happen" has been shockingly resilient over the decades, and I suspect will continue to be.
We need a new one: "Where someone is using a vibe-coded internal tool made by the creative department that keeps needing bug fixes, there's a start up waiting to happen."
I dont even blame management. I believe most of them are well-aware that much of what is going on right now is pure hype.
However, they dont have a choice. The sentiment of shareholders is that they want their cash (yes it is their cash that managers re-invest on their behalf) to be invested in AI-related projects.
So...... you get what you get, and investors will get what they deserve. But they will still blame the management in the end ;)
All of the hype surrounding AI will subside when a SaaS company eventually deploys a moltbot version of their software and the company is driven out of existence due to the chaos that ensues.
I wish I knew:). I kind of think Palantir is particularly at risk here. Image a company with siloed data behind APIs and access to other external data APIs. Using something like Claude I could tie all the separate sources into an easily digestible dashboard without any help from Palantir.
I've seen some bad some SaaS that management insists is an integration they need and no one else provides. I can easily see some vibe coded projects replace them.
They will magically realize this when their huge bonuses will be tied to something longer lasting than last quarter/year performance on some very narrow metric (which has nothing to do with sane stuff like adding long term value to some part of the company).
They are not stupid, far from it, most are (very) high functioning sociopaths. And out and up there its everybody for themselves first.
In my career I've deployed close to 100 different saas products at enterprise level and can tell you that most of the current crop are slapped-together half-finished dross with a huge sales and marketing team.
In the time it takes to deploy semi-bespoke saas, or while waiting for the current licence term to expire it would be very easy to develop a more suitable and much cheaper product in-house, this was true before AI tools and doubly so now.
A huuuuuge part of why companies, especially public companies, especially those in regulated industries like healthcare and finance are willing to pay eye-watering sums of money for a SaaS app that you could get an MVP up in a few weeks time from a competent team with no AI is that they need a phone number to call when something shits the bed at 2 AM on a Wednesday. They need support SLAs without the payroll and headache associated with it. They need someone to sue if things truly go tits up.
Moving SaaS apps in house is a great way for a VP to get a fat bonus or a director to get a promotion but I have to imagine it keeps the CIO/CTO up at night unless they're fully asleep at the switch.
Yep! We sometimes have a choice between the gold-standard and commonly updated open source solution to X and a two-bit hacked together proprietary solution that has 24/7 support at high cost...and we choose the one with support, because that's what our audits basically require. Because then we can say "yes, it's still within the support contract, we have an escalation point".
The problem is right now management is not only insisting on their team vibe-coding bespoke replacements, they’re avoiding paying for other SaaS because they can vibe-code their own replacements, often themselves, and they’ve lost sight of that they probably don’t want to be responsible for it.
Besides rampant failures in communication and skills allocation, wild U turns of requirements were (sometimes, not even real business requirements) were holding back corporate environments doing a decent job.
With AI, I can only see the rate of such changes sky rocketing due to expectations wildly misaligned with reality. Hence we are unlikely to see any meaningful improvements.
This is an incredibly broad statement that just isn’t true in a million cases. Last co we migrated all of our observability from Datadog to Grafana/AMP because it’s much much cheaper. The vendor can charge some premium over the cost to build/maintain but not infinity. SaaS is going to have to get dramatically cheaper to compete with the lower cost of building your own.
You're not considering opportunity costs and buyers vs. users.
If your senior developers can slap together something better than an expensive SAAS offering you want them directing that energy at your core products/services rather than supporting tools.
And the people deciding to buy the expensive SAAS tools are often not the people using them, and typically don't care too much about how crappy the tool may or may not be for doing the job it's advertising as doing.
No matter what it's a tax on your engineering team to keep it together. But the most brittle parts are always right at the seams. It's not as hard to sew together components when you can cut the cloth down to fit together. Who knows how it'll shake out.
Clubbing all saas products together just means you can’t really have a productive discussion. Saas products are on a spectrum of quality, from amazing (stripe, datadog) to terrible (fivetran, github). Its upto you as a user to make a call as to which will serve you best, what you should focus your limited resources on etc.
> what if this time it's senior developers and they actually can slap something together better then the expensive SAAS offerings
A typical SaaS customer will use many pieces of software (we mostly call them SaaS now) across its various functions: HR, accounting, CRM, etc. Each one of those will have access to the same pool of senior devs and AI tools, but they will pour more resources into each area and theoretically deliver better software.
The bigger issue here is the economics of the C-suite have not changed here. Assume a 100 CPG company uses 10-20 SaaS apps. Salesforce might be $100k/year or whatever. 1Password is $10k. Asana $10k. etc. They add up, but on the other hand it is not productive to task a $150k employee with rebuilding a $10k tool. And even with AI, it would take a lot of effort to make something that will satisfy a team accustomed to any modern SaaS tool like Salesforce or Atlassian. (Engineers will not even move off Github, and it's literally built on free software.)
That's before I get to sensitive areas. Do you want to use a vibe-coded accounting system? Inventory system? Payroll? You can lose money, employees, and customer perception very rapidly due to some bugs. Who wants to be responsible for all their employee passwords are compromised because they wanted to save $800/mo?
Then, the gains from cutting SaaS are capped. You can only cut your SaaS spend to zero. On the other hand, if you have those engineers you can point them at niche problems in your business niche (which you know better than anyone) and create conditions for your business to grow faster. The returns from this are uncapped.
TL;DR; it's generally not a great idea to build in-house unless your requirements are essentially bespoke.
As my manager said to a young me when I offered to replace our CMS, and promised I could do a good job at it, "you could probably assemble our office furniture too, but I don't want to pay you to do that either"
We have replaced many SaaS with inhouse solutions, but most of these where lacking in quality and where part of our existing core business model which we where not "owning" prior. We can flip the argument where we have lost customers and revenue due to SaaS not delivering
The gains is generally more seen outside of monetary as these SaaS solutions where holding us back for achieving our goals and improving our services to our customers. As in the end of the day our customers do not care if "insert SaaS" is having issues, it will always be our problem to own.
To the first question, if your senior devs can do that there's almost certainly something more directly valuable to your business they could be doing than solving a problem your vendor has already solved
The second question is a valid one, and I think it will somewhat raise the bar of what successful SAAS vendors will have to offer in coming years
Nice what ifs, but not valid so far. I get the motivation to think/hope so, but thats not the proper business world right now where big money are. Maybe next year it could start becoming true but then market will be a bit different too
There are of course exceptions to every rule, and I'm sure some companies have been successful in building their own in-house tooling.
At the end of the day these decisions are all series of trade-offs, and the trick is understanding your requirements and capabilities well enough to make the right trade-offs.
This is because what management wants and what builders want are not aligned, not because the quality of JIRA is so amazing that no other alternative could ever be created. JIRA is fine but many people I know that use have some qualms with it because the bloat is pretty crazy.
As Spolsky said a quarter century ago, "bloat" is just "bugs somebody already fixed". (He may have actually said that about "cruft", but the idea still applies.)
I think there’s also the classic “I can build zoom in a day” - they get video working between two machines. But it’s the last 80% of the app that takes 99% of the time. Nerds don’t see the whole product, just the happy path of a wee technical challenge.
This may be true pre-LLMs, but I think you need to account for the baseline build-vs-buy tradeoff shifting.
Companies in most cases don’t want to build SaaS because it is expensive to hire engineers to do it, not because they are allergic to owning teams.
If in-housing becomes substantially cheaper than the alternatives then companies will adapt.
But even if the new equilibrium is to hire a contract dev shop to build something custom to keep avoiding responsibility, this would have the same impact on SaaS.
So I’m pretty skeptical of this first-principles prediction expressing right level of uncertainty.
Possibly, but I don’t think it’s certain. For a SaaS to capture, you’d need a forward deployed engineer model. And then I would have ten different FDEs to liaise with, none of whom know my domain.
Vs if I contract a shop, then I have a dedicated team ramped up on my domain who then can vet infra providers and choose the best tech. So potentially still some SaaS, but probably shifting more to PaaS.
Similar to how you don’t hire your Salesforce or SAP contractors from these companies, I would predict this model spreads to other platforms too, and may make OSS viable in more places.
I think with a SaaS you're trading user research and workflow design for a certain lack of customization, and that for 90% of businesses that will remain the right call. (And for the ones where it's not the right call, I think the contractor model also makes more sense than in-house LLM-generated-user-tool teams. That's a lot of code to pile up under a very small team for long-term maintenance. Yeah, "the agents can do it," but you're making ever-more balls that the people overseeing the agents will have to juggle over time.)
If you're selling honey online, say, how bespoke does your inventory management tool really need to be? And are there no lessons you'd learn from a SaaS tool that you'd not have thought of on your own?
I totally agree about the management reluctance to just own everything in house.
But I think it’s plausible that SaaS companies will be easier to start with AI coding, and with lower costs (thanks to AI) they will be able to get into the black with a smaller addressable market. So each one can have a different mix of fewer features, for different segments of customers, at lower prices.
The result would be a loss of pricing power by the incumbent do-everything big guys: no more baked-in 10% annual increases. Which is still a pretty big change in their economics. And therefore valuations.
The companies that already have a strong in-house team will greatly benefit from AI. Many of those who don't are in that situation because managers have PTSD from so many failed projects.
Half of all projects fail. That's a lot of emotional trauma.
This was all possible pre-AI. The reasons that some Saas companies win have nothing to do with how quickly or cheaply code can be written for the Saas.
I can't count the times I've told clients and prospects to _not_ hire us to build something they wanted. Because they could just use off the shelf solutions that were cheaper financially, at least in the short to mid term, and much, much cheaper in terms of opportunity costs. I struggle to put even billed hours into something that doesn't make sense to me.
Of course some overdo it. I've seen companies with more random SaaS tools than staff, connected with shaky Zapier workflows, manual processes, or not at all. No backups, no sense of risks, just YOLOing. That's OK in some cases, in others really not.
I suppose it does need some engineering thinking to find the right things and employ them in a good way. Unfortunately even developers commonly lack that.
I'm a manager too, but I'm also the new guy pushing the solution to a human problem: work management. SMAR, ASAN, MNDY, etc. Not only do people not want to be responsible for it (and in some cases simply be "not responsible"), not only is the internal solution "too time consuming", the only answer thus lands on hiring external consultants to implement and maintain massively-overkill-$olution$ in $aa$ like CRM, NOW, etc. which as you know, do not solve the same problems as the aforementioned SaaS.
"Now that I'm in management, I 100% get it."
100% and win or lose I am still going to fight it...
But this time management has to justify its AI spend.
We've been through cycles of outsourcing and in-housing skill before. This seems similar but for tools and services. Maybe we'll see internal teams taking the reigns back to replace bad-fit SaaS products.
There's still a lot of risk associated with in-housing though (perhaps more than before). That means the real opportunity is for new, leaner B2B SaaS businesses to step in, especially if there's a displacement effect from seeing internally built prototypes of expensive subscription software.
There's that and then there are companies spending 100k on a software suite just to use that 2 features. So now one of their junior dev solves it and becomes a hero. The truth it always somewhere in the middle.
I think the pressure on SaaS margins won't be from customers vibing their way to Figma or DataDog but because gen AI will bring a lot more credible competition in many segments. DD and Figma are probably awful examples because those companies are constantly pushing the envelope, but there are a lot of rent seeking SaaS providers that are going to be in for a rude awaking.
The difference between a vibe-coded prototype product, even a good one, and an enterprise SaaS platform is the difference between a Lightning bug and a Lightning Bolt.
To be fair, re-creating the SaaS solution that simply replicates the features they see can often be done fairly simply. However, there are generally a whole lot of things under the surface. Then there is the whole hosting and maintaining the system, which is its own problem.
I've seen this happen with both juniors and seniors. They do come back with a working solution /for the happy path/. Because the happy path is easy. It turns out that most of the complexity sits in the unhappy paths.
I still don’t agree. The trick to good design is getting more things on the happy path. Most of the software I use is small and constructed in this manner.
"They only coded the happy path" is software engineer for "they coded it as if nothing would ever go wrong". It is definitely not good design to do that.
There's an engineering trap/fallacy I like to call "how hard could it be". How hard could it be to build a [whatever] clone? If you find yourself thinking that, stop what you're doing, because the answer is almost always "at least an order of magnitude harder than you think."
What I meant is that most commercial software has a large number of code paths. Because it’s built incrementally, not holistically. This creates complexity and cost.
If you’ve only worked on that kind of software it’s hard to know the alternative which is to aggressively prune code paths and rework your main code.
And open source example is Quake. I rarely come across software whose inherent complexity is more than quake.
Yeah, that's not what the person you were replying to is talking about. I was explaining the jargon.
Complexity and LoC has nothing to do with "only coding for the happy path". Both complex and simple software can be written this way.
A great example is the moltbook hilarity. They slapped together something that looked good and did function -- in the happy case only. They put together an "authorization" flow but exposed their entire database because they didn't know how to secure Supabase. They had no rate limiting on account creation -- so one dude created 1M in an hour.
Even putting aside adversarial usage, you have to code for, like, normal stuff going wrong or your app will lose data, crash, leak information, fall over, etc, etc.
I agree. Just because you can buy some piece of software doesn't mean you should -- there is a lot of software that exists just to sell more consulting hours and will never fit the business. It's actually not hard at all to code and maintain much simpler alternatives.
Actually having to support multiple businesses with commercial software is hard. I've written a ton of custom software that far surpasses the capabilities of commercial offerings but if were to turn that into it's own commercial offering it would be large undertaking.
1. No. The point of having engineers is to build product and make you money. They cannot make you money if you waste their time on building internal apps that do not make you money.
There's no point in saving $20K on an SaaS app if you use $100K in developer time and miss out on $1M of potential revenue. We get paid the big bucks because we can make companies a lot of money.
2. Haaaa no, that's 100% not how that works. If you buy a SaaS product, the company made that product. They have documentation. They have training. You can hire people who have worked on that system before. If it goes down, they get paged.
If you write the tool, all of that is on you to do. If it goes down, you have to fix it. If it screwed up data, you have to fix it. Any time anyone has any questions? Guess what, you're the one they'll ask. All of that costs the company money, because you don't work for free. When you quit, the app is now useless and can't be fixed unless you did a lot of work beforehand.
It's best to think of DIY apps like those really really sticky noxious tarpits. It might look safe or easy to get into, but good luck getting out of them. You might end up at the bottom with the bones of everyone else who thought that DIYing it was a good idea.
> The point of having engineers is to build product and make you money.
You're making the assumption that all software development is for software products. My work supports a non-software industry. Every minute that I save of user's time translates into more time they can use to make money.
> There's no point in saving $20K on an SaaS app if you use $100K in developer time and miss out on $1M of potential revenue.
If the SaaS app is $20K, I would agree. Probably the cheapest we have is $30K per year, most are an order of magnitude more than that. And it doesn't take a $100K of developer time to replace some of them.
> Haaaa no, that's 100% not how that works. If you buy a SaaS product, the company made that product. They have documentation. They have training. You can hire people who have worked on that system before. If it goes down, they get paged.
Haaaa no, that's 100% not how that works. You buy a SaaS product then you pay them to install, configure, customize it. That can a small amount or a large amount. That can take a small amount of time or years. You can maybe hire people who have worked on that system, but probably not, and it's mostly bespoke knowledge that only a small amount of people have. They aren't cheap. But you might be entirely dependent on the vendor.
If it goes down, you have to put in a support ticket. You wait. Everyone is still on your case but you can't do anything about that. If you have access, sometimes you can fix it yourself -- and you do -- because waiting for support to do it properly is awful. If it's screwed data, good luck, they're not good at fixing that. Anytime anyone has any questions? Another support ticket. None of these people work for free; expensive support contracts. The level of support you get is completely divorced from that cost. You can't pay less if the support is terrible, you can't pay more to get better support (not that you would want to).
If I write the tool and it goes down, I can fix it. Awesome. If it screwed up the data, I'm more than capable of fixing that. If anyone has any questions, guess what, I actually know the answers. The company pays me for these services. When I quit, the app can be easily fixed because it's all standard technologies that lots of people know. Those SaaS tools? They're the black box that nobody knows how to configure, customize, or fix. The vendor isn't interested in doing anything more than the minimum needed to close the ticket.
> It might look safe or easy to get into, but good luck getting out of them.
Just try and switch away from your cloud SaaS product. You might not even be able to get your data out.
> You buy a SaaS product then you pay them to install, configure, customize it.
Ok, hold up. That is not a SaaS app lol. That is an on-prem installation. Very very very very much not the same thing.
The entire point of SaaS is you don't install it on prem. SaaS directly competes with what you're talking about.
Before you go declaring an industry is dead, at least understand what it is.
> My work supports a non-software industry. Every minute that I save of user's time translates into more time they can use to make money.
Sure. The corollary to that is every minute your app doesn't work you cost them money. If you fuck up and store protected data the wrong way or lose data because it tipped over, you're also costing them money.
Replacing some tinkertoy nobody relies on is easy. If your app is in the hot path, congrats, you're now critical infrastructure lol. This is the Bad Place.
> When I quit, the app can be easily fixed because it's all standard technologies that lots of people know.
I can tell you have never had to clean up one of these apps. Knowing the technology is not the issue. It's figuring out all the random decisions and details and load-bearing parts and reverse engineering someone's weird tooling without breaking things. It sucks real bad because you don't know what you don't know.
> Just try and switch away from your cloud SaaS product. You might not even be able to get your data out
Sure you can. Getting the data is the easy part. In the very worst case, you might have to pay them or get someone in management to scream at them, but it's the easiest part of that kind of project.
It's the rest of that kind of project that's tricky. Replacing a critical live system without downtime is Srs Bizness.
> Ok, hold up. That is not a SaaS app lol. That is an on-prem installation. Very very very very much not the same thing.
I didn't mean to imply on-prem. "Install" was the wrong word; call that "onboarding" instead. There is always some integration component as well because nothing lives entirely on it's own. Some SaaS providers are really good; no complaints on this part. Some are terrible. I believe one new vendor is going to try and charge us almost $100,000 to integrate their product with our other products. The entire purpose of this product is the integration. This is one I'm pushing to do internally because it's so fiddly.
> The corollary to that is every minute your app doesn't work you cost them money. If you fuck up and store protected data the wrong way or lose data because it tipped over, you're also costing them money.
So? You seem to think SaaS software doesn't go down, break it weird ways, get slow for no reason, etc. Across everything we probably had half a dozen small outages last month. But none of our internal (also cloud) products went down at all. Hell, one of the biggest most common SaaS products in our industry released an undocumented change last month to their API that subtly returned incorrect results. As far as I can tell, they still haven't acknowledged it.
I'm not saying we don't have bugs or bad things don't happen but I don't see why you think that externally purchased software is automatically better.
> I can tell you have never had to clean up one of these apps. Knowing the technology is not the issue.
Good developers produce good results. I have a new intern on my team who's currently still in school and she's absolutely killing it working on our apps. So maybe the problem isn't internal development, it's just shitty developers. Those exist in SaaS products as well; I look at some of their shit and I wonder what we are paying for. It can be well hidden behind nice marketing and big brands but it's still crap.
One vendor tried to sell us a product that was actually sneakily split into two pieces -- one developed in North American in .NET and the other half in India in PHP! They nightly sync the data between them. At the time, we had multiple products for this job and we were looking for one integrated product to replace them. I just happened to notice when looking at the URLs during the sale pitch and that's what caused them to spill the beans. We didn't buy that product.
While a lot of our internal development is complete products, a good chunk is actually filling out the functionality holes or working around bugs in our SaaS products.
> Sure you can. Getting the data is the easy part.
The last one we dropped, we definitely didn't get our data out. In fact, as soon as we cancelled the contract (3 month lead time) we were basically dead to them.
> I'm not saying we don't have bugs or bad things don't happen but I don't see why you think that externally purchased software is automatically better
If you staff an entire team to build apps, update, maintain and deploy changes to them, and run a call rotation, and that's all you do, there's no problem. You just have an internal development team. That's completely fine.
What's not fine is the people going "how hard could it be to replace Y" and slapping something together. Those sort of skunkworks projects have a couple common common failure modes:
1. the project fails after a lot of wasted effort
2. the project succeeds...but is never productionized. The person who wrote it is now stuck writing it forever. Which they might like, but it's miserable if they quit or retired or get hit by a bus aka the bus factor.
If the bus factor is one, that is pretty much always pain.
The point of SaaS and service-contract type enterprise software is not that they are perfect and great and not buggy. Enterprise software sucks a lot. SaaS is usually "you get what you get".
The point is you can't halfass it. Either you go whole ass and staff out a big enough development team (with all the expense and difficulties implied) or you go none ass and buy.
If the management is the one actually paying for the software from their own pocket (founder), the tables turn. There are millions of SME owners who are forced to pay for B2B software just out of necessity and not having resources to build it in-house.
I work at a smallish public tech company and while this may be true at some companies, it's not true at all of them. We have almost no SaaS vendors. If we do have to buy software, we're almost only interested in On-Prem.
It almost always devolves into some all encompassing ERP that is meant to solve the needs of all parts of the business and save millions in licensing costs, and we all know how well that plan goes.
Software without support is useless. In the business world, what's being bought isn't code—it's a solution to a business problem, with a throat to choke if things go wrong.
management simply doesn't want to be responsible for it
That sounds dysfunctional. The purpose of management is to manage risk, not to avoid it. A proper manager would be able to quantify both the risks and the costs, present those figures in an easy overview, and then be able to defend their decision (or advise higher management) using that.
My firm has partially transitioned through this curve. We went went from "fully externally supplied" systems, to an architecture that combines "externally supplied" (core functionality) with "low code" about 6 years ago. I would argue (as a financial manager) that that lead to a more flexible and more affordable architecture. A funny mixed bag problem arose though: the curve of business demands grew harder than that of IT-delivery. So IT delivered more value, but business keeps demanding a faster pace. If I project this line to the future AI will most certainly harm our external suppliers. We keep getting better at DIY development and "low code" will transition towards "no code". Not really "no code" of course, but DIY IT developed tooling.
The age of the business developer has re-arrived.
For the first time in my career, I can point to multi million euro external suppliers, tell my environment "that's basicly an API + authentication from X to Z, let's develop that ourselves" and get a response of "When" instead of "No". B2B SaaS is toast in my perspective, as are boutique firms delivering solutions + consulting. I can create a million euro team easily (that's like five developer years), if they deliver a successful insourcing. And now I feel like writing MBA-slop, but's it's all about growing your IT maturity. All insourced code is future maintenance expenditure. You need to balance that to the benefits.
> All insourced code is future maintenance expenditure. You need to balance that to the benefits.
I love this perspective. I feel like the pendulum has swung too far back to "it's easy to build, it'll be easy to support". But to be fair, it was probably too far the other way a few years ago: "it was easy to buy, it'll be easy to have them support it".
Other than trial and error, how do you think about pricing out maintenance costs for insourced code vs purchased functionality?
> management simply doesn't want to be responsible for it
The problem with this kind of thinking is that it strips away all nuance. At some point you have to be responsible for something ... otherwise you don't have a business. You are simply a wrapper around your SaaS providers and tightly coupled to their success. The key is knowing when to offload and when to keep it in house. Quite frankly, your average weekend MBA VP simply doesn't have the expertise to make these kinds of decisions. This is why so many VPs exit before things get bad.
Think about it differently - let's say a free OSS product can be installed and you can use ALL features except for LDAP (because that's the paywalled portion that requires you to buy it for $25k / month.)
Well, with claude, you can download the code, tell it to implement LDAP authentication, and smile all the way to the bank. And for said fortune 500 company, employing an employee to spend 100% of their time maintaining the app at 10k per month is a 15k savings! And because it _doesn't really take 100% of their time_ it's really only like $500 per month? And to be completely honest, how man times did you get Jira to fast-track your issue?
I get it however, the manager angle. It's still a distraction. But the article being referenced still shows revenue going down.
There's definitely a lot of cope in here, mostly because SaaS is keeping them employed... be ready, the crush is "almosthere".
And don't forget the safety in getting to say "our systems are down because of [X TRUSTED SOFTWARE FROM LARGE KNOWN BRAND] and we're just waiting for them to fix it" instead of "our shitty internal tooling is broken and no one knows how to fix it"
This feels like it goes along the lines of "people's vibe code is cluttering up our PR's, people still need to review" -- it misses the boat: models are already capable of getting you up to speed on how the code is organized and works, in as much as you want to or need to be up to speed. They are already helping me cut down review time because I don't need to aimlessly hop around, I have a good starting point that I can scrutinize and dialogue about. Same thing here: employee leaves company -- about 3 years ago you would be right, now the company is left with an unmaintainable mess of legacy code and tech debt. TODAY this just doesn't matter. No one really needs to read that code too closely, it's already easy for agents to digest and explain and modify.
Doing this today, in production, with full trust, is clearly not wise, but the writing is clearly on the wall that this is going to be the norm more and more over the coming years. The times they are a-changin.
Can you be clear what you mean? What are you saying has not worked once?
And "it will be the norm" is a clear corollary of, absent any significant and unforeseen roadblock, even with the current highly imperfect agentic sausage-making factories we have today, what capabilities will be in like 6-12 months time.
When the effectiveness of vibe coding an internal workflow was measured, only 5% of efforts worked. That's pretty rare and bad. And those are the early adopters who tend to be more adaptable and effective with new technology. That's a big part of why people don't believe the (your) hype. Its great at simple things with a low cost of failure. Problem is, its rare to pay a good wage for simple things with a low cost of failure. Also, writing new code isn't a big part of most engineers jobs. To put it more simply, vibe coding optimizes the wrong things about engineering.
I think you can avoid the pain by thoughtfully designing it to avoid lock-in. You want it so that if needed, a dev can vibe-code a migration tool to the equivalent SaaS offering. AI lowers the barrier for creating these in-house replacements, but it also lowers the barrier for scrapping them too.
The thing about lower barriers is that it makes it easier for e.g. Salesforce to raise the level of expectations. And that's the moving target. New employees will come from elsewhere and wonder how a company is operating using tools from 2020 when X, Y, Z are becoming industry standard.
The key here is that the moving target will _never_ be "what can 1-2 people vibe code without any expectation of being the best at what it does?"
(Also: training people on bespoke tools takes much longer than training on configurations of standard tools. Imagine if you had to learn a new source control system at every job, like in the '80s.)
4. Employee continue in the company and request help (or the managers see the need):
4.1 They hire more, but if all are vibe-coders too
4.1.1 The product gets more complicated (no more complex, that good developers can manage!)
4.1.2 Bugs creep in, feature request pile up.
4.1.3 People start to get desperate, not worries! now:
4.1.3.1 Somebody vibe-code a new alternative that solves
the immediate problem
4.1.3.2 Bugs creep in, feature request pile up.
4.1.3.3 Needs to sync with the other tools
4.1.3.3.1 Somebody vibe-code the sync that solves the immediate problem
(the saga continue)
In parallel:
4.2 Eventually is obvious that need external help
THEN:
4.2.1 They ask for consultors for build tool, of course, from a company that has embraced the IA!
4.2.2 They build new shinny tool!
4.2.3 Bugs creep in, feature request pile up.
4.2.4 Needs to sync with the other tools
....
AND:
4.3.1 They ask for consultors, to teach them what to do, of course, from a company that has embraced the IA!
4.3.2 New shinny theory of how do the thing with IA is now being implemented!
4.3.3 It require a rewrite of not only past solutions but, a change of how the company behave!
4.3.3.1 Needs to sync with the other tools
.......
4.3.4 And it spark beautiful office/political debates around some philosophical whatever that also trigger changes in the structure, hiring or whatever, alienating the people that has been working there, that after months, has started getting the handle of it!
4.3.5 Employees either leaves the company or moves on to another project.
4.3.6 New employees arrive, with a wild new IA tool and different vibes that vibe-coding!
... the saga continues
5. Is now clear that it need to buy a product form a well stablished software provider
If I understand correctly many organizations will not develop original stuff internally, because nobody internally wants to be the one is shouted at if something goes wrong.
That's a huge part of it. But also you presumably hired a full-time programmer for a reason, and in almost every case that reason was not to have somebody to write and maintain your CRM system. So any system they build and maintain is not just another thing for you to worry about, it's a huge chunk of time that the developer isn't doing what you hired them for.
They're in series A right now, so most likely yes they will fail like most new businesses do. Internal chat is a hugely competitive field with multiple large players (and Teams has had Copilot for a while now). So, I wish them the best, but this is pretty much exactly the kind of "existing product + AI" mashups that will have a tendency to burn out over the next couple of years, just like "our old business but with .com at the end" did back in 1999-2000.
I like to bring up JIRA example. You could replace it in-house yeah it is just tickets with statuses. /s
But then keep in mind one who built the replacement will become the owner of an application that business doesn’t want to pay for and that person will be cost center for the company.
That person better get marketing and negotiating skills that Atlassian has on board because that person will be responsible for the app and will not be getting salary increases for working on something that is not core business of the company.
You guys keep using services like Jira, Salesforce, Stripe, Datadog, etc. While those are definitely the biggest names, I don't think people are referring to those SaaS platforms as the ones they will replace or try to build an inhouse version of. It will be things like ETL pipeline services, data scraping services, maybe some internal analytics SaaS. The niche things that cost a lot because they’re in a sweet spot where only a few people need them, but no one used to have the resources to build them in-house. So, when the salesperson called and offered a perfect solution to their problem, they bought the service. Those are the ones that will be more targeted for in-house solutions.
I'd actually say the opposite is the case. B2B (even SaaS) is probably the most robust when it comes to AI resistance. The described "in house vibe coded SaaS replacement" does not mirror my experience in B2B at all. The B2B software mindset I've encountered the most is "We'll pay you so we don't have to wrestle with this and can focus on what we do. We'll pay you even more if we worry even less." which is basically the opposite of...let's have someone inhouse vibe code and push to production. B2B is usually fairly conservative.
There was no chance that everyone would be running their own email server, but if it wasn't for the lack of IPv6 adaptation a plug and go home email server solution would probably see a decent amount of use. I'd bet we'd already be seeing it as a feature in most mid-ranged home routers by now.
The mail server in a router is easy to host, the problem is:
1) Uptime (though this could be partially alleviated by retries)
and most of all:
2) "Trust"/"Spam score"
It's the main reason to use Sendgrid, AWS, Google, etc. Their "value" is not the email service, it's that their SMTP servers are trusted.
If tomorrow I can just send from localhost instead of going through Google it's fine for me, but in reality, my emails won't arrive due to these filters.
I use a small local provider (posteo) and have 0 problems with spam.
So a 20 pound monkey can also throw around some weight. To be fair I only use it for personal stuff its probably different if you need enterprise scale l.
I've seen plenty of Gmail accounts over the years and they pretty much look the same.
The only Gmail accounts that are "overrun by spam" are those of people subscribing to lots of spammy newsletters and then not knowing how to unsubscribe from them (or figuring they'd stay subscribed in case the next newsletter is the Magical One™). But that's 100% self inflicted and you can't save those people with any technical solution.
Email spam isn't a day to day problem for Gmail (at least) since Bayesian email filtering was first implemented.
The specific concern around uptime & reliability was baked into email systems from almost the start - undeliverable notifications (for the sender) and retries.
But yes, the “trust / spam score” is a legit challenge. If only device manufacturers were held liable for security flaws, but we sadly don’t live in that timeline.
Its not a device/MTA issue, SMTP just is not a secure protocol and there is not much you can do in order to 'secure' human communication. Things like spoofing or social engineering are near impossible to address within SMTP without external systems doing some sort of analysis on the messages or in combination with other protocols like DNS.
SMTP isn't at fault, the social ecosystem is at fault. Every system where identities are cheap has a spam problem. If you think a system has cheap identities and no spam, it probably doesn't have cheap identities — examples are HN or Reddit.
Trust / spam score is the largest one I think, second to consumer ISPs blocking the necessary ports for receiving mail.
Even if your "self hosting" is renting a $5/month VPS, some spam lists (e.g. UCEPROTECT) proactively mark any IP ranges owned by consumer ISPs and VPS hosting as potential spam. I figured paying fastmail $30/yr was worth never having to worry about it.
For "Trust", I believe patio11 described this system as the "Taxi Medallion of Email".
e.g. you spend a lot of money to show that you are a legitimate entity or you pay less money to rent something that shows you are connected to said entity.
Without some kind of federation or centralization, it seems hard to distinguish a hobbyist from a spammer if both of them are using a plug-and-go. Forcing that responsibility into the hands of Google, Zoho, and Microsoft seems like the best compromise, unfortunately.
For one, if my power goes out for an extended period of time I'd still like to be able to access my email. Communications really can't be hosted locally.
What a weird take. I was running my own email server 25 years ago on a 512 kbit ADSL line. No problem at all, would even be enough bandwidth today for most messages.
(Back then email still worked from residential IP addresses, and wasn't blocked by default)
I agree with you. In B2B SaaS you don't sell the software, you sell your expertise in a specific domain and the responsability you take for owning that expertise. The fact that the development costs are nearly zero will make them more valuable and more protifable
My experience is that SMBs are generally not run by people who feel confident doing any kind of self managed IT.
No amount of LLM usage is going to change them into full stack vibe coders who moonlight as sysadmins. I just don't see it happening.
Not until, that is, a new generation, that has grown accustomed to the tech, takes over.
Until then the current SMBs will for the most part fulfill their IT needs from SaaS businesses (of which I think there will be more due to LLMs lowering the barrier for those of us who feel confident in our coding and sysadmin skills already).
Having seen how clueless the new generation is and the amount of brain rot they get from using LLMs over honing their own skills, I'd say it's the opposite...
I'm considering SaaS replacements with in house code in situations where my general thoughts are "how can this possibly be the pricing for this?" which is not uncommon.
Well before vibe coding, tons of open source software existed (and exists) to replace SaaS. With lots of features and knobs and real communities. But I still often pay for SaaS because managing it is a headache. Some human has to do it. I can pay the human or I can pay the company. I really don’t see how vibe coded toys can replace real battle tested SaaS products. A better explanation is the bubble in PE ratio is deflating and it’s happening all over, regressing to the mean. AI is a convenient explanation for everything
How many SaaS companies are public? How is that bubble deflating?
These are real risks to these companies.
Your in-house teams can build replacements, it's just a matter of headcount. With Claude, you can build it and staff it and have time left over. Then your investment pays dividends instead of being a subscription straight jacket you have to keep renting.
I think there's an even faster middle ground: open source AI-assisted replacements for SaaS are probably coming. Some of these companies might offer managed versions, which will speed up adoption.
> Your in-house teams can build replacements, it's just a matter of headcount. With Claude, you can build it and staff it and have time left over. Then your investment pays dividends instead of being a subscription straight jacket you have to keep renting.
Lets take Figma as an example, Imagine you have 1000 employees, 300 of them need Figma, so you are paying 120k per year in Figma licenses. You can afford 1 employee working on your own internal Figma. you are paying the same but getting 100x worst experience, unless your 1 employee with CC can somehow find and copy important parts of Figma on his own, deploy and keep it running through the year without issues, which sounds ludicrous.
If you have less than 1000 employees it wouldnt even make sense to have 1 employee doing Figma
>Lets take Figma as an example, Imagine you have 1000 employees, 300 of them need Figma, so you are paying 120k per year in Figma licenses.
I mean in an example that almost happened... "you are paying 120k per year in Figma licenses, Adobe buys it, you are paying 500k per year in Figma licenses"
At least up until the point of vibe coding it was still worth the SaaS provider charging at least as much if not slightly more than you doing it yourself because most businesses weren't going to anyway.
By that logic, people should never use any Saas products because someday the price will increase. Then why even use Claude Code, someday they will get sick of losing money and increase the price to $1000/month.
> you just put your employees directly on Nano Banana or one of the simple Nano Banana wrappers.
So you end up spending the money elsewhere? with exploratory design you can easily spend 10k a month on these models as a company of 1000, thus completely losing any monetary savings. Anyway you look at it, Saas worked because costs were spread out and low enough to not optimize it too much.
Now you have an entire in-house product to manage and build features on. It could potentially work but so much of what my company pays for is about much more than the software itself. One example would be BrowserStack for very specific browser and mobile app testing edge cases. Can’t vibe code this. Another would be a VPN service with the maximum number of locations to test how our system behaves when accessing from those locations. Another would be hosted git. Another is google suite and all of its apps. How can we vibe code Google Docs and Sheets and Drive and all of the integrations and tooling? It simply isn’t going to happen.
Maybe you are right and the companies do want to pay and not worry about these problems. But now they have a lot more SaaS options to chose from. The incumbent companies like Salesforce and Atlassian have less of a moat. Maybe they'll keep the power users but if a customer is only using 80% of the feature set there is new competition.
Competition might come in the form of a startup but it can also come from existing SaaS companies expanding into adjacent domains. Canva now does docs. Notion does email. etc
Also, it is my experience that exec and boards favour safe and well known B2B partners over in house. It's a more publicly defensible approach that gives them an out if things go wrong and shareholders get upset.
For big corporations at least prices of SaaS are rarely an issue. Issues are: we don’t have the time to introduce a new tool, what about our processes, we don’t have the right people.
> we want recent examples just look at tailwindui since it's technically a SaaS.
This is a terrible example. Show me someone ripping out their SAP ERP or SalesForce CRM system where they're paying $100k+ for a vibe coded alternative and I'll believe this overall sentiment.
I have heard this from execs at public companies as well. I think a HUGE part of this appetite is that today no one has yet been subjected to doing business on a bunch of apps cobbled together by vibe coders.
They are just hearing the promise that AI will allow them to build custom software that perfectly melds to their needs in no time at all, and think it sounds great.
I suspect the early adopters who go this route are going to be in for a rude awakening that AI hasn’t actually solved a lot of hard problems in custom software development.
In the world of B2B software many of the 'hard problems in custom software development' have not been solved by human coders either - it can be an extremely grim market for anyone who cares about software quality. I'm completely unconvinced that on average a vibe-coded app is worse than the typical B2B slop.
I too have an appetite for magic beans, but unfortunately, I'll be unable to eat them until they exist. As it stands now, it doesn't seem like AI stuff can produce anything with this large a scope.
So, do their AI devs have deep knowledge of the business processes, regulations/legal (of course in all kinds of regions), scaling, security, ... ? Because the LLMs sure as hell are lacking that knowledge (again, in depth).
Of course, once AGI is available (if it is ever) everything changes. But for now someone needs to have the deep expertise.
>> This is a terrible example. Show me someone ripping out their SAP ERP or SalesForce CRM system where they're paying $100k+ for a vibe coded alternative and I'll believe this overall sentiment.
I cannot imagine an SMB or fortune 500 ripping out Salesforce or SAP. However, I can see a point-tool going away (e.g., those $50/mo contracts which do something tiny like connect one tool to another.)
TailwindUI isn't really what I'd consider SaaS -- it was a buy once and download software product.
That means to keep making money they need keep selling new people. According to them, their only marketing channel was the Tailwind docs, AI made it so not nearly as many people needed to visit the tailwind docs.
If they had gone with the subscription SaaS model, they'd probably be a little better off, as they would have still had revenue coming in from their existing users.
> I mean if we want recent examples just look at tailwindui since it's technically a SaaS.
How is it in any way B2B? At most B2C + freelancers / individuals / really small SME.
It didn't have any clues a med/large B2B would look for e.g. SSO, SOC2 and other security measures. It doesn't target reusability that I as a B would want. The provided blocks never work together. There aren't reusable components.
Tailwind UI or now Tailwind Plus is more like vibe coding pre-AI.
Sorry but tailwindui is not a SAAS. There is no service or hosting. You buy a coded template once and then receive updates. It is totally not the same as a critical B2B SAAS that is running 24-7 on the vendor's servers providing real support and service.
TailwindUI unfortunately sits in a position of being an easy to disrupt business with current AI.
Now attempt the same with Zoom, I suspect vibe coding will fall down on a project that complex to fit the mental model of a single engineer maintained a widely used tool
Perhaps the case for premium CSS SaaS businesses, I guess (which seems particularly primed for disruption even pre-AI), but there are many more robust B2B categories out there that aren't literal code + docs as a service.
how dont people understand? if you have a VC funded b2b saas, you need to charge huge margins for the investors to get a return. now, small teams can vibe code a replacement and charge 90% less money. AI is going to kill saas margins.
i literally cannot understand why people keep repeating that non tech companies will build their own software, thats not the bear case for saas
Did vanilla Jira for a while, battled with a web app that is actively trying to make you hate it—switched our team to Linear, couldn't be happier ever since.
Well for marketing and sales your bigger competitor is already doing the work of showing companies that they want the functionality at all, and the cheaper competitor's sales and marketing pitch can be: we are much cheaper.
This is pretty much what blacksmith.sh does -- GitHub Actions but it's on faster and cheaper hardware. I'm sure they spend non-trivial amounts on marketing but "X but much cheaper" doesn't sound like a difficult sale.
(edit) And the design, sadly, can be as simple as "rip-off bigger competitor" -- of course if one day you are the big competitor because you "won" in the market, you'll need to invest in design, but by then I guess you'll have the money?
they dont, which is why these companies are going to get smoked. a small team of people will compete with atlassian head on. the whole saas business model is under threat
Yeah.... The code isn't the hard part. That's not where the value is.
This hard part when you're doing in house stuff is getting a good spec, ongoing support, and long term maintenance.
I've gone trough development of a module with a stakeholder, got a whole spec, confirmed it, coded it, launched it, and was then told it didn't work at all like what they needed. It was literally what they told me... I've said 'yes we can make that report, what specific fields do you need' and gotten blank stares.
Even if you're lucky and the original stakeholder and the code are on the same page, as soon as you get a coworkers 'wouldnt it be nice if...' you're going to have a bad day if it's hand coded, vibecoded, or outsourced...
This has always been the problem, it's why no-code never _really_ worked, even if the tech was perfectly functional.
The accounting saas dores presumably uses doesn't "automate spreadsheets" as its core value prop.
related: i'm thinking these vibe coded solutions are revealing to everyone how important and under appreciated good UX is when it comes to implicit education of any given thing. Like given this complex process, the UX is holding your hand while educating you through a workflow. this stuff is part of software engineering yet it isn't "code".
I, on the other hand, can't wait to fire every single B2B subscription we've got.
B2B SaaS is a VULN. They get bought out, raise prices, fail. And then you have extremely large amounts of unplanned spend and engineering to get around them.
I remember when we replaced the feature flags and metrics dashboards with SignalFX and LaunchDarkly. Both of those went sour. SignalFx got bought out and quadrupled their insane prices. LaunchDarkly promised the moon, but their product worked worse than our in-house system and we spent nearly a year with a couple of dedicated headcount engineering workarounds.
Atlassian, you name it - it's all got to go.
I just wish I could include AWS in this list. Compute and infra needs to be as generic as water.
If you're working at SaaS, find an exit. AI is coming for you. Now's a great time to work on the AI replacement of your product.
> And then you have extremely large amounts of unplanned spend and engineering to get around them.
I have no idea how you are spending "large amounts" of unplanned spend on Saas products. Every company I worked for had Saas subscription costs being under 1% of capex. Unless you add AWS, which is actually "large amounts" but good luck vibe coding that.
Metrics at a fintech processing billions of dollars of daily GPV, plus the signals from every microservice in the constellation are enormous. Huge scale time series data.
We had an in-house system that worked, but it was a two pizza team split between time series and logging. "Internal weirdware" got thrown around a lot, so we outsourced to SignalFx for a few years. It was bumpy. I liked our in-house system better, and I didn't build it.
Splunk then buys SignalFx and immediately multiplies the pricing at a conveniently timed contract renewal. Suddenly every team in the company has to plan an emergency migration.
What agents are you using? If you stick to opentelemetry and open source agents and develop a collector infrastructure -
You can switch across different vendors with lower impact and ramp off time.
Your supply chain is messed up. You need sign longer contracts with price guarantees.
1. This isn't rooted in data but anecdotes "One Series E CEO told me that they’re re-evaluating the quarterly renewal of their engineering productivity software because they along with an engineer reimplemented something using Github and Notion APIs. They were paying $30,000 to a popular tool3 and they were not going to renew anymore."
2. These anecdotes are about tech startups spend, not your <insert average manufacturing business>. Nor or they grounded in data that says "we interviewed 150 SMB companies and 40% of them have cancelled their SaaS subscriptions and replaced it with vibe coded tools"
- If our customers vibe coded better integration points for us, it probably improves our overall value to our customers.
- The software industry, especially startups, is such an insignificant portion of the market, its not really worth worrying about. But, I can tell you from experience, that even large software companies don't want their own developers spending much time on accounting, ERP, or HRIS systems and they "outsource" this to SaaS companies.
Yeah, this is just long-form linkedin slop. He's thought-leadering to get you to get his (no-doubt slop-written) guides and do leadgen for his forthcoming saas.
Yeah, also if a SaaS costs, 10k a year, I promise its not not more cost effecient to pull your 10k a month engineer off their usual work to build and then maintain some vibe coded slope everytime an edge case occurs.
Also many customers of SaaS have little to zero engineering staff, they are in construction, resturaunts, law offices ect. These takes are so assanine.
Is there a place on the internet where folks like yourself, who seemingly have a way to think economically congregate? I personally dont know of one, for which if I did, I wouldnt visit here anymore.
So many takes on here are so lazy and simpleton that when you go a few levels deeper all the flaws get exposed.
Its funny you mention this, I was going to say that the only communities I've found online where +EV thinking is the norm is in professional gambling circles. However, those exist basically only in closed off discord and telegram chats, where we are actively manipulating polymarket/kalshi markets && comment sections :)
Even in companies that have SWE, do you really want to divert in-house SWE time to something as exciting as ... accounting rules and making sure your inventory is auditable? Or any number of the weird compliance things associated with most B2B software for a medium-size business?
I have few sticks in the sand in my thinking framework:
* writing code has always been the easiest part of building software, deciding what to do and what not to do is something else that takes forever sometimes
* there are several open source projects that can replace commercial SaaS and still people prefer to purchase commercial SaaS. These are available immediately, deployed immediately etc etc.
* along the same line, some of those open source projects offer self-hosting and cloud version: I would always personally go for the cloud version because in a small team I don't want to operate something that other people built and I don't know how to operate. That's not my job not my team job
* people are underestimating how draining is operating and maintaining software, which is something that goes beyond the adrenaline rush you get after "building" something with Lovable or similar tools. Also, I find it extremely easy to get 80% done quickly but excruciatingly slow to get things done right.
* I still see huge value in using tools like Lovable to build a working prototype and validate assumptions so that you get quickly build the right thing right solving the right problem in the right away avoiding waste
* camcorders have been around for ages but you don't have millions of directors around just because you make a tool more accessible
* same can be said for other things like restaurants, where sometimes it's more convenient (although expensive) to buy vs build.
>people are underestimating how draining is operating and maintaining software
Yep. Many SaaS have an edge because they factorize the struggle of many customers, if a SaaS has 1000 customers, each customer vibing their way into a home-built solution will require dedicated efforts at maintaining it. Even with AI, those efforts aren't negligible.
Many companies don't even operate any IT infrastructure, cloud or otherwise, themselves, beyond office connectivity, AI replacing SaaS will require someone in charge of that at the very least.
> camcorders have been around for ages but you don't have millions of directors around just because you make a tool more accessible
tiktok alone has 1.5 million directors! it's just that we call them creators now.
the meaning of the word director has changed, that's all. but professional roles shift in meaning all the time. a computer used to be a literal human doing arithmetic. an engineer was someone who designed war machinery. being a doctor used to mean teaching at an university.
human beings are natural tool makers. we always have been. the frontier material to manipulate where the most advanced engineering happens constantly changes: stone -> bronze -> iron -> ink (descartes) -> steel -> silicon -> javascript (YOU ARE HERE).
notice how each step is an improvement/abstraction on top of the steps that came before it. some say english is next in that chain. i honestly have no idea. all i know is there will always be The Next Thing and it'll be much nicer to work with.
> camcorders have been around for ages but you don't have millions of directors around just because you make a tool more accessible
That’s exactly what happened. There are more filmmakers than ever now due to the accessibility of cheap cameras, then digital tools, including affordable HD cameras. Especially once the DSLR revolution took off circa 2011, which enabled budget-constrained aspiring filmmakers to use prime lens sets rather than fixed/built in zooms on cheap camcorders. With proper lighting they could actually make something look pretty damn cinematic. The entire industry has radically shifted in the last 15 years in particular due to these changes, but it started to shift around 2000 if I have to assign a particular year to it.
When you had to shoot on film stock, which was expensive and had a whole processing pipeline that one couldn’t reasonably do at home, there was a much thicker barrier to entry. You basically had to go to film school or get into the industry before you could start making your own stuff. Hell the Duplass brothers started out on crappy camcorders. Now? A smartphone, some cheap LED’s, a basic computer, you can really make something.
My point was along this line: writing code is different than building a product as much as recording a video is different than telling a story with a movie (long and short that you want).
Do everyone has the capability to build a comprehensive set of features that we call a product to solve problems that people or business have in their life?
That’s why I’m always skeptical about measuring AI impact based solely on quantitative metrics.
Like I said I agree with your larger point. But it’s actually not a great example, because lowering the barrier to entry, particularly the hardware side, led to a massive increase in the number of filmmakers and films in the world. People telling full stories from start to finish included. The reason it doesn’t graft well onto the AI discussion is that the process and output are controlled and measurable. There’s no real black box element. What you see is what you get and the output of the camera is fully controlled by the user.
Let me provide some possible evidence against this: so many teams are desperate to rewrite their codebase but struggle to actually do so. And when they finally make the leap, it takes them 5x as long as they had hoped. Then sometimes the new code isn't even any easier than the old code.
I personally find writing code to be a huge time suck and I'm very happy that AI helps me save that time.
But again, how much of that time is spent writing code?
I've done rewrites, replatforms, a bunch of times. The actual programming is not the tricky part, but instead (1) picking apart the legacy system, understanding what to build, (2) orchestrating the work to shift transactions from service A to service B without breaking anything.
Teams and especially developers love to think they can skip that phase and just crack on with the programming, invariably what happens is the same as described above: intoxicating velocity followed by a hard stop when you realise you haven't solved problems (1) or (2) above
Most of a software project's lifetime will be spent as a maintenance challenge. i.e. How do we add the 237th feature without adding to the performance problems that already exist. Hence, the desire to rewrite the codebase to incorporate the abstractions of all 236 features.
I don't see AI helping with this. From my experience, it seems like the opposite. It can help you write the code after you've deconstructed the problem yourself and know how to keep it in check.
I reckon a lot of re-writes tend to take "them 5x as long as they had hoped" and "isn't even any easier than the old code" exactly because writing the code wasn't the problem in the first place.
It's business logic, edge cases and other small necessary details that accumulated over time which make the code 'messy'. Once you've integrated all those in the new system, it likely looks equally messy. And discovering and implementing all those extra requirements is probably what took you the longest.
Not to say this applies to all re-writes or that AI tools can't help the process
> “…deciding what to do and what not to do is something else that takes forever…”
If that’s the case, then I should think business owners and office workers should be able to sort that out, lestwise on the “how to automate the boring stuff” front. That repetitive, boring, time consuming, error prone work. Incremental, least work for greatest impact.
The danger is they pull a 1999 Mars Climate Orbiter —level mistake. Or their solution suite grows to big to manage with mounting tech debt.
Also, if you’re software also required some custom domain hardware, then there’s your bottleneck for protectionist business practices.
I see that Software as a Service banked too much on the first S, Software. But really customers want the second S, the Service.
When you sell a service, it's opaque, customer don't really care how it is produced. They want things done for them.
AI isn't killing SaaS, it's shifting it to second S.
Customers don't care how the service is implemented, they care about it's quality, availability, price, etc.
Service providers do care about the first S, software makes servicing so much more scalable. You define the service once and then enable it to happen again and again.
They didnt, dont make the mistake of thinking Saas companies are just software companies. They are Sales companies who happen to sell software. Companies like Dropbox & Atlassian have long been surpassed in Tech but they live only because they continue selling even when demand was hard to get. Their moat is sales & networking and software has to be just good enough. And other part is service, these companies still have one of best costumer service since the start of early 2010s. You can still get refund on Uber quite easily, but if you try doing that at a regular old school company you would require a prayer and couple of business weeks.
Yes, many don't like Sharepoint, but still they use it. It's the tool they can use.
Customers don't care if Sharepoint uses LLM, they just want to share ideas, files, reports, pages, etc. If LLM makes it easier, great! If some other product makes it easier, great!
It's not about the product it's about the results.
You're proving the point? Sharepoint, teams: availability + price. Every company has microflows, sharepoint and teams are automatically available and part of the price or lower priced than the competition.
Nah it's not that at all. Most of the services are totally fungible and everyone has a short attention span. You need to be in a market which is extremely difficult to disrupt and have a product which people are totally dependent on. And those tend to have a rather large cost to enter unless you were in early.
I just don't want to pay $50/user/month for an initially open source product that was relicensed and then crippled that the initial group giving something away decided they wanted to make a business of it.
I think one of the interesting things here is that AI doesn't need to be able build B2B SaaS to kill it. So much of the overhead of B2B SaaS companies is thinking about multitenancy, intergrating with many auth providers and mapping those concepts to the program's user system, juggling 100 features when any given customer only needs 10 of them, creating PLG upsell flows to optimize conversions, instrumenting A/B tests etc...
A given company or enterprise does not have to vibe code all this, they just need to make the 10 features with the SLA they actually care about, directly driven off the systems they care about integrating with. And that new, tight, piece of software ends up being much more fit for purpose with full control of new features given to company deploying it. While this was always the case (buy vs build), AI changes the CapEx/OpEX for the build case.
And in many cases, it's 12 features, with 2 of the features not even existing in the big SaaS.
I'm pretty sure every developer who has dealt with janky workflows in products like Jira has planned out their own version that fits like a glove, "if only I had more time".
If companies wanted to build thier own simple-JIRA they could have built themselves before. I dont think making a kanban board was hard even before AI.
JIRA especially, and I'm always shaking my fist at Atlassian that simple APIs or workflows or reports aren't already included in the tool. I have to pay some other company $10/user/month to get this dumb report your tool should already be able to do?? Insane.
Jira has had free competitors that do at least 75% of what it does since it's inception. You could find a dozen on github that actually look good right now.
Until a given company decides they need access control for their contractors that's different from their employees, etc. etc. etc. - seen it all before with internal often data scientist written applications that they then try to scale out and run into the security nightmare and lack of support internally for developing and taking forward. Usually these things fizzle out when someone leaves and it stops working.
Pretty much. My employer was looking to cut costs and they were spending ~500k a year on a product that does little more than map entra roles/groups to datasets and integrated with a federated query engine through a plugin. Took a couple days to build a replacement. The product had only a few features we needed.
I've found in the embedded space that people sell lots and lots of products that do everything you could ever want, and the most efficient thing to do is not buy those things and instead find a way to do just the subset of things you care about with your own back-end systems. The upshot of that is that because you're in total control if something goes wrong you can fix it without getting 6 people on a phone call to point fingers at each other.
As niche SaaS provider, I'm trying to avoid succumbing to the same fate. The product I built carefully for years would now be within the reach of a senior dev with a couple focused weeks -- if they knew all the requirements. To avoid being overtaken, I'm working to increase my customer's requirements -- getting them hooked on new reports and features I never had time to build before LLMs could do it for me. This makes it less likely for a competitor to be able to afford to quickly replace me.
At the same time, I have no idea what the cost of LLMs usage will be in the future. So I'm working to ensure the architecture stays clean and maintainable for humans in case this kind of tooling becomes untenable.
That sounds like a good strategy to me. We have a couple other products we're looking to knock out to reduce costs, and the decision comes down to me and another colleague. The thing these businesses have in common - difficult to partner with, rough edges for the use cases we need, and no appetite on their end to shore them up. We're paying premium prices for a subpar experience. If instead they adopted your thinking, perhaps we would've looked for savings elsewhere.
there's no shortage of software engineers, if it was so easy for an organization to replace a saas with something built in-house they'd be doing it all the time. In my experience in enterprise consulting implementing a well defined requirement is the easiest part. Getting everyone to agree on the requirement, getting it defined, and stopping it from changing after every demo is the hard part.
I don't think it is killing SaaS. I have definitely had to extend my sales cycle when a potential customer vibe-coded a quick fix for a pain point that might have triggered a sale a few weeks earlier, but eventually the benefit delivered by someone else caring about the software as their entire mission really wins out over a feature here and there.
If you are selling SaaS consider that a vibe-coding customer is validating your feature roadmap with their own time and sweat. It's actually a very positive signal because it demonstrates how badly that product is needed. If they could vibe code a "good enough" version of something to get themselves unstuck for a week, you should be able to iterate on those features and build something even better in short order, except deployed securely and professionally.
Everyone's going to talk about how cool their custom vibe-coded CRM is until they get stuck in a failed migration.
Yeah I have been saying this since the start of vibe coding, Saas companies rely on their sales, who are good enough to sell ther products even in tougher conditions. Software costs for the companies is 100% tax deductible, and they spend a very little on it (Most of times its less than 1% of CapEx). Only reason to optimize this cost is if the Execs of those companies think you can sell the same product.
> Everyone's going to talk about how cool their custom vibe-coded CRM is until they get stuck in a failed migration.
Failed/partial/expensive migrations is the name of the game with SaaS as well. Lock-in is the bottom line.
Migrations become much less scary when you truly own your data and can express it in any format you like. SaaS will keep sticking around, especially those that act like white-hat ransomware.
The other thing is bringing in the knowledge about what other customers in the same field want. For business-focused software this can be a boon, customers often can't really envision the solution to their problem, it's like the Henry Ford attributed "If I had asked people what they wanted, they would have said faster horses"
> What they don’t know, though, is that a poorly architected system will fail, eventually. As every senior programmer (eventually) understands, our job is complex because we have to understand the relationships in the real world, the processes involved, and the workflows needed, and representing it in a robust way to create a stable system. AI can’t do that.
I have a strong feeling the future's going to look like this:
Company vibe codes to replace a SaaS.
Little do they know this creates a time bomb: fragile systems where fundamental architectural defects are papered over by humans who knew the underlying dynamics but didn't articulate them well enough during the initial "vibe-architecture," so they're forced to patching the "impedance mismatches" with data entry or with even more vibe coding.
Those humans are eventually laid off, because of course they are. Data quality rapidly deteriorates. Operational mishaps deteriorate relationships with human counterparties. Defects begin to cost thousands to millions.
Suddenly, there's demand: not for SaaS, but for actual service businesses. Consultancies that can parachute in, do actual domain-driven design, and un-vibe that code. They do have a stronger-than-ever pool of out-of-work engineers (many from the failed SaaS companies).
The SaaS companies that survive understand that the first S no longer stands for Software; it stands for Solutions.
You're assuming that code in the future will need to be unvibed. Either the code will be good, or AI will be good enough to unvibe it. That might be awhile in the future but it will happen.
just point Claude Code at a Claude Code codebase you forgot about for a few weeks with no plan.md or agents.md or memory.md implemented
configure the session correctly this time and put it in plan mode, it will deal with your whole database schemas, migrate, tie everything to the new models correctly, make a backend deployment script, and fix your UI/UX
The panic over SaaS vs AI is simpler than people think. For years, we’ve been paying "Enterprise" prices for tools that are essentially just a UI on top of a database.
I'm a solution architect, and we recently looked at the $30/user/mo price tag for legacy test management tools. It’s insane. Why am I paying a "per user per month tax" for a glorified spreadsheet when I can pay $20 for an AI agent that can build me a custom version in a week?
So, we did exactly that. We used Claude and Cursor to "vibe-code" EZTest. A 100% open source, self hosted alternative that does 90% of what the expensive SaaS tools do, but with zero recurring fees and total data ownership.
The market is crashing because the "Application Layer" has been commoditized. If you can build and own your infrastructure for the cost of a few API calls, the era of renting basic software is over.
We aren't just building a tool; we're proving that the "SaaS Tax" is now optional.
Literally everything is a UI atop a database. Writing the data models, crafting the right uI and the right flows is non trivial. It requires iteration and that refinement is what customers pay for. The reality with SaaS stocks is they dont make anything critical. eg Take any large consumer tech company and they dont use Klaviyo. These companies build their own stack and one thats intimately connected with the data lake. It works for tech companies since they hve good data and it doesng work for non-tech companies because a good fraction of their data is trash.
> How to keep asking customers for renewal, when every customer feels they can get something better built with vibe-coded AI products?
Wrong take. You don't need to build something better, you only need something good enough that matches what you actually need. Whether you build it or not and ditch the SaaS is more of an economic calculus.
Also, this isn't much about ditching the likes of Jira not even mentioning open source jira clones exists from decades.
This is more of ditching the kind of extremely-expensive-license that traps your own company and raises the price 5/10% every year. Like industrial ERP or CRM products that also require dedicated developers anyway and you spend hundreds of thousands if not millions for them. Very common, e.g. for inventory or warehouse management.
For this kind of software, and more, it makes sense to consider in-housing, especially when building prototypes with a handful of capable developers with AI can let you experiment.
I think that in the next decade the SaaS that will survive will be the evergreen office suite/teams, because you just won't get people out of powerpoint/excel/outlook, and it's cheap enough and products for which the moat is mostly tied to bureaucratic/legal issues (e.g. payrolls) and you just can't keep up with it.
Having participated in the build of an inventory system / system of record for a large national retail company, I can't see vibe coding helping anything more than the prototyping in the discovery / requirements gathering parts of the process.
The sheer volume of data, the need for real time consistency in store locations, yada yada means that bad early decisions bite hard down the road.
Lots of drudge work can be assisted by AI, especially if you need to do things like in ingest excel sheets or spit out reports, but I would run far away from anything vibe coded as hard as possible.
One of my clients spends 500k+ on XXX licensing per year (for a 200M revenue company that's not peanuts), and on top of that has to employ 12 full time XXX developers (that command high figures just for their expertise on that software while providing very little productivity) and every single feature takes months to develop anyway. Talking about stuff like adding few fields to a csv output.
So the total cost of XXX is in the 2M/year range, and it keeps ballooning.
My (4 men) team already takes care of the entire warehouse management process except inventory, the only thing that XXX provides, we literally handle everything: picking, manufacturing, packaging, shipping phase and many others.
In any case, nobody has mentioned vibe coding.
I stated that a handful of good engineers with the aid of AI in a couple of months can provide a working prototype to evaluate. In our case it's about extending our software that already does everything, except inventory management.
When you spend 2M/year on a software (1% of your revenue), growing every year by 100/150k it makes sense to experiment building a solution in house.
That situation makes sense but then i have to ask why hasn't it been done already? Software developers are not rare and if the use case is so isolated and discreet then surely it would have been tried by now. Even without genAI, CRUD, RDBMS record management, SSO, row level security... none of those things are new or out of reach until now. I think what you'll find is when you sit down with the users and start asking about the parts of the exiting system they actually need you'll never get agreement nor a clear answer. When/if you finally get a set of requirements and after UAT sign-off and then after go-live the users will say "this isn't what i meant" and you're back to square one. Rinse/repeat for years and then one day an exec will say "why are we wasting all this time, let's just subscribe to an OTS saas and make them configure it to meet our needs".
Nobody gets fired for choosing SAP, Salesforce etc.
Spending tons of money to get a janky, unreliable system of record, or finding out too late it is missing crucial auditing capabilities, or that it has Big Money bugs, on the other hand, is far worse, especially if you have investors asking what the hell you were thinking.
Your point about users not knowing what they wanted until after the fact is also painfully true. The hardest part about these systems is the people most likely to buy are the ones who have been doing it with a lot of human processes for years. Buying a SaaS or other third party product means having leverage to force them to change to more standard practices. Building in-house means that everyone will fight to high hell to make sure that their special snowflake way of doing things is accounted for and you end up in a worse spot as a result.
Its funny you mention excel, I see vibe coding in the business sense right now being a gateway to replace all of the ad hoc uses of excel. We've basically leveled up the quality of the software you can build before buying a SaaS product or a hiring an in house engineer.
It was 2020 and they were using a format that was replaced in 2007.
It. says more about their issues than Excel. I doubt paper forms would have saved them. Maybe they'll run out of paper and just ignore new entries too.
The moment vibecoded excel has a bug that regular Excel doesn't and a user has to wait on you to re-vibecode it's over. They'll just use Excel while you're trying to get the llm to find and fix the bug.
"For example, to create a data visualization I won’t seek any SaaS. I’ll just code one myself using many of the popular vibe coding tools (my team actually did that and it’s vastly more flexible than what we’d get off-the-shelf)."
That maybe doable in your 10-people startup, Namanyay. Try doing it in a larger organisation with layers upon layers of firewalls, databases, authentication systems and not the least importantly - management. Not to mention the vastly different audience, both in size and interest. Your own experience is not the experience of everyone else.
I guess they mean BI, but for a company of any scale, they aren't paying for a chart, they're paying for a permissions system, query caching, a modeling layer, scheduling, export to excel, etc.
Stand alone BI tools are going to struggle, but not because they can easily be vibe coded. It'll be because data platforms have BI built-in. Snowflake is starting down this direction and we're (https://www.definite.app/) trying to beat them to it.
The term "B2B SaaS" is doing a lot of heavy lifting here and I think conflates two different things:
(1) Business model: hosted software you pay monthly for (vs self-hosted/one-time purchase)
(2) "Glue" products: tools like Monday.com that primarily provide synergy between data sources and workflows
The article is really about (2) - and yes, those are vulnerable to vibe-coding. If your product's core value is "we connect X to Y and show you a dashboard," that's now a weekend project.
But there's a huge category of SaaS where the value is in the product itself, not the integration layer. Take Excalidraw - fits the SaaS model, but try vibe-coding a collaborative whiteboard with real-time sync, proper data persistence, conflict resolution, export formats, etc. The hard problems aren't "connect API A to API B."
Or PostHog - sure you could vibe-code some analytics tracking, but building reliable event ingestion at scale, session replay, feature flags with proper rollout controls? That's years of engineering.
The "vibecodeable" SaaS products were always somewhat commoditized - AI just accelerated the timeline. The ones solving genuinely hard technical problems seem a lot safer to me.
Simple CRUD app sure, but we're nowhere near being able to vibe code even a relatively low-complexity enterprise SaaS product.
If it's got customer data in it and/or you're making important business decisions based on it, you really need your system to be accurate and secure. My experience is the people who procure enterprise software know this and tend to care a lot about it. They often have legal and contractual obligations around that.
In the 1990s there were people who thought OOP with point and click tools like FoxPro and Delphi would make it so easy to create software that everything could be built in-house without expert programmers. The invention of SQL was supposed to eliminate roles like Report Writer and Data Analyst because now business people could just write their own queries "in English" and get back answers.
> In the 1990s there were people who thought OOP with point and click tools like FoxPro and Delphi would make it so easy to create software that everything could be built in-house without expert programmers. The invention of SQL was supposed to eliminate roles like Report Writer and Data Analyst because now business people could just write their own queries "in English" and get back answers.
And yet, precisely that happened in the end, just not with the tools envisioned. Excel, VBA and, where you had one knowledgeable employee, MS Access makes for incredibly powerful and incredibly hard to maintain "shadow IT" - and made even more difficult when someone sneaked in a password, because that takes a bit of an effort to remove [1], knowledge that is easy for us today to find, but not when I was young.
Also, back in the IE6 era, there was a lot of point-and-click created web interfaces... just that it wasn't HTML5 or even HTML. It was an <object> tag loading some ActiveX written by some intern in VB6, or Java, or Flash. I sort of miss that era but also, it was a damn security nightmare. Flash with its constant stream of security vulnerabilities was ripe for exploits, but at least it didn't run native code with full user privileges by design. I'm not kidding, theoretically you could go and import/use functions from any system DLL up to and including Kernel32. OLE/OCX, ActiveX... a design way ahead of its time.
It's an interesting time for sure and I'm not clairvoyant but I really don't think "we won't need developers because business people will just vibe code their own apps" is coming any time soon (or possibly ever)
I think opensource is a good analogue here. For many SaaS products, you don't even need to vibecode anything - there is already a reasonable OSS alternative. Yet people still pay for the SaaS. They want support, maintainability, security, edemifcation, a throat to choke, regulation and domain expertise, etc.
I do think like this HN post (https://news.ycombinator.com/item?id=46847690) is a good example of where a custom more domain specific solution makes a lot more sense that dropping in an off-the-shelf ERP. Still though, I think the bakery would prefer to buy the bakery-ERP than build it but vibecoding does reduce the barrier to entry so we might see more competition and share taking from incumbents by domain-specialized new entrants.
Lots of companies buy saas, and then spend years customizing and effectively building what they thought they bought. And for big companies, it is costly - a few tens of millions for saas licenses, and maybe around 50-100m for system integrators leaching on the enterprise, and doing the integrations and customizations, usually dancing around the data model, api surface limitations of each of the saas tools they want to wire together.
I dont think going back to having own developers, owning the code is going to be a bad financial propositions for such companies. My company is now one month into trying this out and so far, so good. We kicked our outsystems addiction and are just went live with a react rewrite - and are well into rewriting an expensive to run document management system which we were at the same time under-utilizing and abusing. Our product people are loving it since for the first time in ages we dont need to tell them "well that would be real hard, considering we have salesforce crap underneath and it just doesnt do this or that well".
My thoughts are sort of similar. AI/LLMs have allowed many of the typical SaaS customers to think that maybe they could do at least some of this work themselves, and get better results.
For most companies this was always true, but LLMs have given them the confidence to actual start writing more software in house. The SAPs of the world have nothing to fear, companies aren't going to vibe code a CRM, but they are going to be able to more easily write integrations. At a previous job we frequently had bills for €10.000 for small integrations into our ERP, but once we figured out the API and gained more confidence in our abilities, all those integrations got pulled in house.
If your SaaS platform provides actual benefits, then you don't need to worry. If your business in writing integrations for other companies into platforms you don't own, yes, AI is going to hurt your business.
This should have happened regardless of AI though. The idea that companies (over a certain size, e.g. ~20 people) doesn't have a least on developer employed, regardless of industry always seemed like a missed business opportunity. We wrote so many tools for sales, warehousing, customer service and accounting and it's hard to imagine the business functioning without those tools. I might have spend two weeks writing a tool, but if it saves sales 20 hours a week punching in orders, we get a positive return in a month.
I'd rather not name names - but one of the major, popular ones.
We contracted a lot of usage, and are using it literally like a S3 bucket with a malware scanner attached to it, and ignoring the dozens and dozens of document management capabilities it has - that we don't need. (Because really, we only ever needed a S3 bucket with a virus scanner...). This alone will allow us not to renew that contract, and save, maybe, around 2M per year.
Sure, we will have to have our own API that will require support and what not, but... we already HAD to have our own API that requires support and what not, since we have a bunch of legacy document management platforms running in various countries, and we anyway have to operate an abstraction and a router.
I am sure ours might not be the most typical case, but there will be savings, and since the economy is what it is, my bosses are telling me to go for every saving I can find, and thats one of them.
(I'd not try to re-write an ERP system, for instance, or a CRM. But a lot of smaller things where we pay a substantial premium? Sure - we will try.).
Maybe it's mostly from AI, maybe it's mostly general economic cutbacks. I also feel like these "wrapper" style SaaS products are the first ones companies are dropping when they are looking to cut costs, and I think a lot of companies are looking to cut costs. I do agree with the overall conclusion either way, that System of Record products/companies are the most likely to survive. There are a lot of SaaS companies with questionable long-term businesses who are getting hit, but that was bound to happen.
The stocks of a lot of these SaaS companies were priced on the expectation that they could become the next IBM: become entrenched with the customer and then hike prices until their eyes bleed.
A lot of companies have been too smart for that, and a lot of SaaS offerings are too small to be truly entrenched. Arguably the investment horizon is too short (IBM took decades getting to that point).
The only real vendors who managed to become the next IBM are the cloud providers.
I think it's a combination of budgeting, upward price pressure from the SaaS companies themselves, plus bringing things in-house through vibe coding, but there's another factor that I think is harming existing SaaS products. Many of them are becoming legacy solutions with AI bolted on top so they don't really feel that effective or next-level. The underlying tech might even be a generation older too - but the SaaS value-add is providing support, scaling, etc to maintain whatever some old tech that's still a requirement. At some point someone looks at all of these interconnected systems and just says 'start over'.
Vibe coding might not be supplanting all SaaS solutions but it's definitely shaking out "last-gen" solutions.
Analytical systems. I see a lot of add-on services that will add intelligence/analytics/etc and companies try them out to solve some issue they have and bounce off them frequently due to growing costs. I can only assume as mentioned that over time these are also easier for companies to in-house vibe-code as well, I just haven't seen a ton of that yet, but people are definitely trying which still shrinks the available pie.
This isn't happening. The past six months has been rough on public B2B SaaS valuations, but the impact is a lot wider than just B2B SaaS (its all non-S&P10 software), and valuations are just vibes in the end. Most of these companies are, financially, doing pretty well; seeing key metric growth, including revenue and profit. This makes sense: AI does not fundamentally change the bargain SaaS brought to the table, that companies would rather pay someone to solve their problems than solve them themselves. However, the stock market doesn't care about this. The stock market doesn't care about anything; it behaves irrationally and non-sensically, and trying to derive any sense of how stable, strong, or successful a company is from stock market valuation is like using lines of code to claim that a software project is really good.
>that companies would rather pay someone to solve their problems than solve them themselves.
Are they not able to just engage AI to solve those problems now? E.g. this morning I saw an app that did something interesting to me for $20 a month. 20 minutes in Gemini and I had a functional app that replicated the behavior. SaaS are more complex but give me a small team and a couple months and we could replicate most any of them.
This feels a lot like the old RPA hype cycle to me — more sales narrative than structural change.
Most companies are not going to replace stable SaaS with a pile of AI-generated internal tools. They don’t want the maintenance or the risk.
If there’s a real B2B game changer, it’s Microsoft.
The day Excel gets a serious, domain-aware AI that can actually model workflows, clean data, and automate logic properly, half of these “build vs buy” debates disappear. People will just solve problems where they already work.
Excel has always been the real business platform. AI will just double down on that, not kill SaaS.
> The day Excel gets a serious, domain-aware AI that can actually model workflows, clean data, and automate logic properly, half of these “build vs buy” debates disappear. People will just solve problems where they already work
Best they can do is more adware in windows. Sorry.
"The SaaS model was built on a simple premise: we build it once, you pay forever."
I've never seen a SaaS product that fits this description. There are always things to do. Libraries to upgrade, performance bottlenecks to diddle around with, an endless stream of nonsense feature requests from people at the customer who never actually use the product, fun experiments your developers want to try out, and so on.
The hard part in SaaS is to delete code, and that's what you should do, at least some of the time. Either through simplifications, or just outright erasing functionality that very few if any of your customers rely on.
What you should not do is let your customers grow the liability that is code in your production environment, unless your entire product set is designed to handle things like this, e.g. the business models of Salesforce and SAP.
It's not and I really doubt it will, for true SaaS platforms. A desktop .gif recorder (frequent example I've read about) is not a SaaS, even if you charge monthly for it.
Let's put an example an exception-tracking SaaS (Sentry, Rollbar). How do the economics of paying a few hundred bucks per month compare vs. allocating engineering resources to an in-house tracker? Think development time, infra investment, tokens, iteration, uptime, etc. And the opportunity cost of focusing on your original business instead.
One would quickly find out that the domain being replaced is far more complex and data-intensive than estimated.
There are many cases where the company might only use a fraction of the features (and therefore complexity) of the SaaS and so only need to develop and maintain those features they actually need. That's when ditching the SaaS can make sense if you can easily develop/maintain what you specifically need on your own with AI assistance.
Even if they use it less, if you combine all of the Saas products used by a company, thats a tiny fraction of the overall CapEx. And this cost is tax deductible, so there is no reason to optimise it unless Execs are really penny pinching, but at that point that company isn't worth selling to anyway.
What the authors of this kind of doomer-type articles do not realize is that B2B software companies have the data that their customers pay for, and they also have access to the AI tools themselves, meaning they can accelerate in adding new features to their products, making them more competitive.
It's a fallacy to consider the bad performance of software stocks as a definite sign that AI is going to replace them. One needs to factor financials into the equation to explain a downtrend. Take Figma for example, spending 109 mil on AWS bills, cutting through their margins. Investors know that such costs do not simply go down due to the vendor lock-in companies experience when using cloud services.
Claude Code is good, but definitely far away from being able to vibe code Figma.
I think the corrective to this is that many of these incumbents will fail to re-conceive their product stack from a user-centric perspective, and as a result they will be reduce to just a dumb data layer which is easily swappable.
Sure, they could do that, but the cultural change required is an order of magnitude harder than just sticking an agent on top of their source-of-truth and believing that the problem is solved.
Maybe it works for areas where the application is a relatively self-contained island of productivity. Figma is somewhere that a designer spends a lot of their day, so it's going to be less vulnerable, but most pieces of softare fit into broader workflows. So for Figma the disruptor is less likely to be "AI-powered designer" and more "AI-powered web builder" - e.g. Lovable or even Claude Code itself that just generates great designs.
> can accelerate in adding new features to their products
If anything AI helps companies escape the "feature wheel" that is used to justify exorbitant costs, while providing debatable (and often even negative) utility to the end user.
Keep in mind, Excel '98 would still probably be overkill for 85% of people's needs in 2025.
What companies thought was adding more utility, was actually just continually stacking costs in front of getting to that core functionality.
AI replaces the core functionality, and the "feature" scheme collapses...
“Overkill for 85% of people” is a vibes statistic, not an argument.
Also you're generalizing some things to the whole sector like every software provider now is useless and the new features they add are not bringing any values. How can you make such generic statements about a sector that is so diverse?
I start to suspect some of you are just private-equity-sponsored accounts trying to push Anthropic propaganda over the Internet.
Claude Code doesn’t need to vibe code Figma. It _is_ Figma.
Take a couple screenshots of your legacy app, write a short paragraph describing it, and the web tool will give you a self-contained HTML file that’s a fully interactive mock-up.
But it’s still a mock-up. So software dev in general will be fine, it will evolve. But unless the AI companies run out of money and it turns out the $20/mo plan actually costs $1000/mo without VC subsidies, Figma is cooked.
so many conditions need to be met to have Figma "cooked". Plus you forgot that the underlying LLMs need to get exponentially better, hard to do that without infinite VC money.
You need to have tremendous agency/will to start competing with a public company. Plus, you need to have a lot of distribution channels, competing with sales people that do this for a living since ages, and marketing budgets that are higher than your annual Claude spending.
Regular people do not press 10 clicks daily to track their calories, and you're saying that they will start competing with Salesforce and the like?
Focus is a currency and you have a limited amount of it, if all SaaS is built internally, teams would go bankrupt. There's likely always going to be a band of experts focused on solving a problem and everyone pays them to solve it for them, because they do it better and can handle the hassle of maintaining it.
AI isn't killing SaaS exactly, but instead of selling UIs, SaaS companies are going to have to focus on infrastructure and data. You have to host stuff somewhere, so there's an inescapable cost and transaction that has to take place. If businesses can pay one bill for infra + data management and get nice apps and stuff on top of that (without being locked in), that makes more sense than trying to roll stuff together even if you have a platform team.
Anecdata sample size of one, but this is not my experience at all. My business has only continued to grow over the past couple years, and I don't think I've had a single customer mention AI to me at all (over the phone or email).
It's the opposite IMHO. AI is enabling a lot more B2B SaaS. There are a lot of companies that are running on outdated software. Especially in manufacturing and industry. They've had decades of experience with very expensive IT projects where cost got out of hand because things just are very complicated in the real world.
There are many millions of companies that are going to be re-examining if they can do better in the next years. The work will still be very complicated but with the help of AI, small IT shops might just deliver enough value to be worth the trouble.
The notion of e.g. busy floor plant/logistics managers vibe coding this themselves is silly. 1) they don't have the time; these people are super busy 2) they lack the ability. 3) they'll want it done properly 4) their employers won't skip all the certifications, iso stuff, and what not.
Companies invest in SAAS software if it delivers some kind of revenue/profit benefits. If it's too expensive/complex, it can't do that. AI tools lower the cost of SAAS solutions. So the totally addressable market grows. Companies will want to maximize their ROI though. So, they'll do the usual and engage software companies and integrators to help them do this. They'll expect to pay less for more. And there will be lots of haggling around that topic. But there's an enormous amount of companies that are quite far behind on getting their operations into this century in terms of IT already. There are going to be early adopters looking for early successes here that will put pressure on their competitors if they are successful.
I'm running a small company in this space. We're seeing a lot of opportunities right now. And AI is making my work massively easier already. All those complex ERP integrations just became an order of magnitude easier to do with a small team. They are still hard though. Forget about vibe coding that. You need a plan.
The framing is a bit dramatic but the underlying shift is real. What AI actually kills is the "wrap an API in a UI" SaaS model. If the value is just presenting data nicely or doing simple transformations, an agent can replace that.
What survives: products with proprietary data, strong network effects, or deep domain expertise baked into the workflow. The moat moves from "we built a UI" to "we understand this problem better than anyone."
I run 4 side projects and the ones getting traction aren't the ones with the fanciest AI features - they're the ones solving specific problems people have repeatedly (meal planning, meeting search). The AI is the engine, not the product.
The real risk for B2B SaaS isn't that AI replaces your product - it's that your customers can now build a "good enough" internal version in a weekend with Claude Code.
Fair callout. I've been writing too many product descriptions lately and it's leaking into how I write comments. The actual point was simpler than I made it sound: AI kills "UI wrapper" SaaS, but products with real domain knowledge survive. My side projects taught me that - the ones getting users aren't the technically fancy ones, they're the ones solving boring specific problems.
It’s not as far-fetched as people think. I see so many comments here doubting you can vibe code a full CRM or e-commerce SaaS, but a skilled AI-assisted programmer absolutely can, especially if they're aware of strong open-source alternatives already out there.
For Salesforce-like CRM, there's Twenty[0], a good-enough alternative. For Shopify-style e-commerce, Medusa[1] is a headless commerce platform.
The real power comes from using AI to study how these projects implement specific features (payments, inventory, customer dashboards, etc.) and adapt them to your stack. AI excels at finding the "seams" (those connection points where a feature ties into the tech stack) and grasping the full implementation. The trick is knowing precisely where the feature lives in the code (files, functions, modules), because AIs often miss scattered pieces otherwise. That's what I'm building at opensource.builders[2]: turning OSS repos into a modular cookbook with structured "skills" that point to exact details for reliable remixing and porting.
SaaS companies are forever beholden to raising their market cap, even in solved spaces like cart, payment processing, and CRMs. Most businesses run on CRUD apps anyway, and if your core app exposes an API, you can build any customization you need on top of it. People here discounting how valuable it is for a business to have the software that runs their business on a tech stack they understand and something they truly own.
Just because it's possible to build equivalent software by vibe coding doesn't necessarily mean that companies will stop using SaaS. There are multiple reasons why...
First of all, many big companies pay a fortune to use inferior SaaS solutions instead superior Open Source solutions; possibly because one of their CTO may have received kickbacks or promises of a lucrative job at the SaaS provider as a consequence of this deal. There are a lot of politics going on behind the scenes when it comes to procurement.
Execs at big corporations are often looking for plausible ways to spend investors' money in a way that they can capture some of it for themselves. If they choose open source or they choose cheap vibe coded solutions; there is not much money changing hands. No opportunities for insiders to covertly monetize.
And then there are a lot of security implications to using a complex vibe coded app. The AI won't be able to identify the vulnerability in any decent sized codebase unless you know what you want it to look for.
Lets break this down. There is very little in newness in what Anthropic announced. Claude had skills for a long time. They have added one more layer of abstraction and called it plugins. This mainly comes with a set of integrations.
Thats the pitch.
But, what are Claude plugins?
Plugins=Commands+Skills+Integrations.
Commands are specific to Claude code. But commands and skills are nothing but prompts at their basest level.
So what is the main differentiator?
Integrations.
But what are you integrating with?
SaaS companies.
And what is the stock market doing?
Dumping SaaS stocks.
How do they think Claude cowork will work without the integrations. Without the system of records.
If anything, these SaaS products have become more important. If I was a trading guy, I would go to the github of claude plugins, see the default integrations and buy the stock of those companies.
Lot of places that I see AI disrupting - I'm not buying that SaaS is going to be a significant one.
Reading through the article:
> They were paying $30,000 to a popular tool3
Couple things we needed to understand here:
- How large is the client company
- Is that $30,000/month or day or hour....
If it's a technology company of > 1000 employees - then $30,000 month doesn't even get Finance's attention. And there is next to zero chance that anyone is going to vibe-code, deploy, support and run anything in a 1000 person+ company for $30,000 a month. SaaS wins hands down.
Any product/service that people care about comes with a pager rotation - which is 6-7 employees making > $200k/year. If you can offload that responsibility to a SaaS for < $1mmm/year - done deal.
Yeh but in a company of 100 employees for software of 30k a year, it's more than worth it to take your standard 50k (GBP) dev and have them replaced it. It's a one time cost, and the support time will certainly be less than 50% of their time every year so it saves money.
There are many companies that operate like this all over the world. Outside of the hyper-growth tech VC world cutting costs is a very real target and given how cheap Devs are outside of America it's almost always worth it.
I can't imagine it would ever be worth, under any scenario, trying to write/build/support any $25/seat SaaS software for any company I've worked at in 25+ years.
Another thing to keep in mind - very little of the cost of a SaaS license is the time it takes to build the software. Security, Support, Maintenance, Administration, backups/restores, testing/auditing said backups/restores, etc, etc.. and then x-training new SREs on how to support/manage this software, ...
Even as someone who spend 10+ hours a day churning out endless LLM applications, products, architectures from my myriad of Cursor/Codex/CC interfaces and agents - I'm dubious that LLMs will ever eat into SaaS revenue.
I'm sure (lots of) people will try - and then 1-2 years in someone will look at the pain, and just pull the ripcord.
I don't see that happening because companies need to concentrate on their differentiators. Is your enterprise vibe coding its own SaaS? Who's taking care of it?
We wouldn't do it for tools that are purpose made and have sane pricing in the market place. We do it for stuff that would traditionally go on a 'platform' like Salesforce or something that requires a lot of customization to begin with. It's so much easier to just roll your own than even just going through the procurement process of those kinds of tools much less the integration and change process (hiring consultants, etc). I'm not hands on with it, but I know our small group of AI are helping us eliminate $5m recurring annual spend this year and that's directly impacting the topic article. I won't be surprised if at some point we replace our more sticky ERP software or use this leverage to negotiate prices that are sane. Businesses have been gouged by enterprise software long enough.
Yes to some extent. We wrote a CRM that works for what we needed. It's not a full blown SaaS product we could sell to any company as a tenant, as they would all want other features that aren't important to us. This is what happens during an implementation anyways, we only implement what we care about.
No names, but my company is service companies (mostly residential) - many logos with different verticals (think electric, hvac, etc). Having a SaaS CRM that served all our brands needs was always a challenge and made aggregating anything difficult (we basically were running multiple CRMs)
We were using dozens of SaaS tools per logo - and just going through them all and figuring out what features we need/want and rolling them into the larger system. We've also built handful of things for internal operations, finance, etc
Agreed. I thought it was weird on the ct ligature on something like the second sub heading and the next one had a st ligature. I stopped reading the article and was just scanning for st ligatures in the text itself (there are none) and then realised the main font was a less legible serif font and the headings that were bigger and shorter were sans serif which makes the ct and st ligatures stand out even more.
I didn't read any more of the article after that, and the primary reason was just this weird font choice.
It really isn't. Nobody's migrating their payroll vendor to some vibecoded app. I agree with Jensen Huang that this reaction doesn't make sense at all.
My own prediction is that reliable vibecoding will be additive. It's a new capability that will help high-agency people do things faster or answer questions they couldn't easily answer before. Need to spin up a big custom Monte Carlo calculation and want a simple UI to control and configure it? You can just throw that together now. Need to get a draft budget allocation for a big set of projects calibrated against a set of conflicting constraints? Let an agent crank at it for a couple hours, then review and refine manually -- or just toss it out if you don't like it.
But building, running, and maintaining production-grade services or apps that the company relies on for its basic functioning? You're not just paying the SaaS vendor for having built the product -- you're paying them to maintain it, run it, and respond to issues promptly. You're also paying them to keep building it and improving it over time. To be clear, I think there are certainly cases where the rise of "coding AGI" is going to lead companies to build some services internally versus buying from a vendor, but I predict these will be highly custom and bespoke services that are too tailored for a specific corporation to make sense for a third-party vendor to try to sell.
It seems like 'the market' is making this bet. I'm not deep into financial reports or whatever. But what I'm seeing from the tech side, this is not at all true.
If anything B2B SaaS is growing with AI, and it hasn't even begun, the biggest AI markets right now are personal. The B2B market is up for grabs for sure, 0%-1% of niches have an LLM product right now. But traditional SaaS has a huge advantage, they have reams of industry specific data, and they have the customers, sure they will have competition, but they are the incumbents.
As a founder, there is another angle here that is worth mentioning. Not only does AI B2B SaaS allow insourcing, it also allows there to be 10x (imaginary number) the number of companies building SaaS for the same use case. What we see in healthcare or finance for example is executive fatigue from demos, in many cases mostly vibe coded frontend UIs that entrepreneurs are using to test the market. This creates friction for businesses / SaaS companies that are unable to show how their solution is unique, well built or has a clear moat over the many others they have seen.
While the author is wildly overstating things, I do think AI is striking at the heart of the SaaS problem, which is the business model of "pay us $10-100+ per employee per month in perpetuity or we will hold all your data and your company's operations hostage". There is always going to be value in good software, but it is shitty vendors relying on the lock-in effect that are in danger. And good riddance.
The other issue is valuations - B2B SaaS stocks have never been rooted in reality, and the 100+ P/E ratios were always going to come down to earth at some point.
Agree on the valuations. Most have come down and many have overcorrected imho.
As expensive as some of these software seem in terms of cost per seat, most of the subscription contract rarely exceed a few hundred thousand / year if even $1mm, which is drop in a bucket for many companies. (vs running on-prem servers, having staff to support them)
You'd think Atlassian would be printing money given everybody under the sun is using them, but they only make $5B in annual revenue.
I've worked at fortune 50 companies for a while and custom enterprise software is still alive and well for things that are too business specific to buy off the product for. But they're not going to be in a rush to create their own Workday, Salesforce, Jira, Figma, SAP, etc.
Sure its fun to (vibe) code some internal version for a SaaS, but maintain it month after month? Maintain SLAs, etc? That's not fun.
Vibe coding gives you that dopamine hit of creation, but does the internal dev really want to deal with the care and feeding of the random shitty timesheet app they created?
Do they want to take on the work of integrating random backend systems that timesheet system needs to talk to? Do they want to get called at 3AM when it's down?
Even AI assisted, living year after year with production systems is hard.
> we have to understand the relationships in the real world, the processes involved, and the workflows needed, and representing it in a robust way to create a stable system. AI can’t do that.
That is because AI is living in our world, instead of the opposite where we live in AI's world.
Case in point: maybe the AI hallucinated a class method that never existed in our world yet, but perhaps in the AI led processes and workflows it would be written to better fit into the smooth gradient decent those same top parameters' scores.
I think there may be other factors killing SaaS, particularly data sovereignty.
"According to IDC’s Future Enterprise Resiliency and Spending Survey from June 2025, 45% of all organizations and 56% of “digital natives” cited data sovereignty and potential cloud changes as their greatest concern for 2026."
“Killing” is a bit strong, but is there a world where folks just vibe code solutions that they would have bought previously? Absolutely and and I think that world is here now.
I’ve seen many startups recently were it was like “guys I could vibe code your ‘product’ in the afternoon.” Yes someone needs to look after it etc, but the bar on where companies buy vs build is getting much, much higher.
(Insert rant from dev teams about the code sucks, who will maintain it, etc). Yes all valid points, but things are changing regardless of if folks like it or not.
Counterpoint, all your customer's data just got stolen by teenagers in the 3rd world and is available for purchase on the dark web. Was it worth saving $5k a month?
A lot of startups/small businesses are like "with AI we can build more than ever". The problem is so can everyone else and capitalism rewards scarcity not value. The bar for startups and small software business has risen quite substantially. I know we are avoiding buying software now where I work if possible unless we previously committed to it (contracts).
Saas companies will survive for the same reason they do today. The operational overhead of any sufficiently complicated piece of software is too much, even more so if it's vibe coded.
One problem with centrally produced and distributed software is that a small subset of users demanding certain features results in feature bloat for everyone. Costs for all features are shared by all users.
Probably one way SaaS companies will adapt is to break up their offerings into more modular low cost components. While many customers will end up paying less, the addressable market will probably increase because of the new low cost options.
To a degree but most enterprise focused software usually has differential pricing. Often that pricing isn't public so different companies get different quotes.
The framing of 'vibe coding replaces SaaS' misses the more interesting shift: the value SaaS provided was never really the software — it was workflow automation. Software was just the best delivery mechanism we had.
What's changing is that agents + APIs are becoming a better delivery mechanism for many workflows than a UI you manually operate. A company paying $50k/year for a marketing analytics dashboard doesn't actually want a dashboard — they want answers about what's working. An LLM with API access to their data sources often delivers that faster than navigating someone else's opinionated interface.
The SaaS most at risk isn't infrastructure (Stripe, Twilio) or systems of record (Salesforce, Workday). It's the 'pretty UI on top of data you already own' tier — analytics, reporting, simple automation, basic CRM. That's where the compression happens. The products that survive will be the ones that become the system of record, or that offer value AI genuinely can't replicate (regulatory compliance, deep integrations with legacy systems, etc).
I didn't realize B2B SaaS products were in freefall like his numbers suggest. I'm not convinced customers are leaving to vibe code their own products but I do believe we're seeing a major shift in the market, pushed by the sudden relative ease of coding. There are a lot of B2B SaaS products which are outdated and I wouldn't be surprised if they're supplanted by much faster competition
Yup it's definitely not because _customers_ are coding solutions, but the trend and motivation seems to come from the fact that customers are realizing there's something else possible except being tied into expensive recurring yearly subscriptions.
I was surprised when I saw the numbers from Bloomberg myself as well!
The keyword in "Software as a Service" is not Software; it's the Service.
In the early days, the tagline for Salesforce is "No Software". It's secret recipe is this: your sales team only need a browser and a credit card, to get the service. No software installation needed. Even if you have a genius can code something equivalent, it will never be a "service". That genius is not going to support it, not going to add storage for you, not going to restore an accidentally deleted record for you. That takes an army to deliver. It is a service.
Of course, Marc Benioff kind of shot himself in the foot by trying to get ahead of the AI curve... and gutted their customer service division. If the service is delivered by AI agents, what is the selling point again over other AI agents? They have debased their key strengths and are getting punished for it.
I used to be a big advocate for Salesforce in my organization. And it was really great .. allowing us to deliver new functionality without the usual IT procurement bureaucracy.
Now with cloud maturity and Vibe coders who will get better and cheaper, I think it's possible to replace all the features we use on Salesforce at a fraction of the cost of our Salesforce licensing cost.
There is no evidence presented that internally "vibe coded" products are the reason hubspot et al are struggling right now. If anything, the fact that the divergence from the broader index starts in April of last year (well before the current vibe coding moment got going) is evidence that this is something else.
Vibe coding seems to be the iPhone camera to DSLR moment for programming.
- No professional used an iPhone for years. Most don’t today.
- Professional scoffed at it as a toy
- The toy shifted the balance of volume through everyday enablement of amateurs to a degree that professional were right, but now in a severely lopsided terrain.
The value ends up in the most engaged paradigm, rather than the most perfect one.
Most people who've been in a business SaaS environment know that writing the software is relatively the easy part aside from in very difficult technical domains. The sales cycle + renewals and solution engineering for businesses is the majority of the work, and that's going nowhere.
I feel the same way about needing to build platforms that enable companies to build on top. That's why i'm building adventureflow.ai to enable energy companies to build their agentic workflows directly on top of my platform.
The expectations have completely changed now, customers expect more software for less, because it is 5-10x cheaper now or faster to build and there's no changing that. Tools like Opus 4.5 have completely disrupted the software marketplace!
Salesforces market cap today is 180,35B. That, not the change, is the market's judgement of how valuable salesforce is, despite any risk from AI. If salesforce stock drops with a new AI model that doesn't mean that investors think salesforce is worthless. It means a slight risk to their business is getting priced in.
I am kind of hoping that AI will kill the startup grab for money TBH. Too many wannabe CEOs I've met in the past 2 decades have gotten rich thanks to a lucky pitch without a clear path to a viable product. At least 6 of those I know did so at the expense of developers that accepted equity over cash...and the developers wasted a ton of time and 2 even were briefly homeless as a result...and none of them live in California.
Hopefully wannabe senior leadership will try and take advantage of AI without taking advantage of developers, because most of us just want to write code and build something great.
Reminds me of the story of when the Surgeon General (in the US) reported that smoking causes cancer.
People stopped smoking immediately, and cigarette sales tanked. The cigarette companies laughed (with all the phlegm in their throats and lungs) and sales came back 1-2 weeks later.
I suspect in a few months or a year companies with vibe-coded replacements for SaS products will find they need to go back: But, just like how many less people smoke today than in the past, the writing is clearly on the wall. At some point someone will figure out how to replace SaS with AI; it's just going to take a lot longer than many think.
I was reading through the article and waiting for the key info to drop, but nope. It never did. It seemed like marketing fluff. If anything, vibe coding may eliminate some of the B2C SaaSes, but not B2B. If you think an enterprise is going to vibe code a B2B offering that they pay millions for, you're out of your mind.
Here's my general mantra regarding AI: NEVER take suggestions about AI from people who have a vested interest in it. CEOs of companies that train and offer LLMs, Authors of Books about LLMs and AI in general, etc.
This may come off as an unpopular opinion, but this is how I felt after listening to Steve Yegge recently. He has a new book about Vibe coding and he goes on in the interview/podcast to say that the best programmers he knows in the world (the ones better than him and maybe even the top world class programmers), would be equivalent to those of interns in an year, if they don't start vibe coding or use AI. I respect the guy, but damn, this is just peak delusion. He didn't even say it as a hyperbole, he meant it.
According to popular CEOs of companies training LLMs, 2024 was supposed to be the year that would eliminate the need for Junior and mid-level engineers. 2025 happened. Now, we are in 2026.
So yeah, I'm never taking advice about AI from these people ever again.
> Here's my general mantra regarding AI: NEVER take suggestions about AI from people who have a vested interest in it
I get where you're coming from, but let's say you're talking to a HVAC installer, and he recommends you a system to get - I'm sure there's financial self-interest on his part, but I do like to think that he knows quite a bit about what he does, and believes what he's selling is genuinely good stuff (and has reason to), even if he oversells it a bit.
The analogy can work if you're not looking for an HVAC at all and the HVAC guy is instead approaching you, unprompted, to explain that you need to buy this new system. Because if you don't, your business will become uncompetitive and fail.
True. That's the case with almost any commodity in life. That's why I was specific about AI.
The difference is, in other sectors, there's no fear-mongering. If you don't use their HVAC, it's fine. Your job isn't getting replaced. The air you breathe in your home isn't going to be fully polluted. You have other options.
With AI though, there's no middle ground. You either use their tool and become extremely successful (so much that you don't know what to do with that much success) or you're out of a job and become obsolete in like the next 3 seconds.
Are there real documented cases of a company replacing their SaS with a vibe-coded version?
Like I can see how a very small company could replace a portion of an overkill and underutilized SaS platform.
I don’t see how a larger more complex business could replace their SAP or ADP with a vibecoded version.
These stories are all very similar in where the author knows some CEO of an obscure company who told them they had an engineer reverse engineer and vibecode some obscure SaS solution and saved them $50K.
With a new agentic-lashup tearing across the internet every week, pointing the way to "gradient descent" software development, any purchasing manager worth their salt is going to ask some serious questions about their enormous SaaS bill before committing to another expensive long term contract. It follows that valuations must decline. Even if only because risks to moats have increased, but also because it makes sense to negotiate hard on pricing when there's fear in your counterparty.
Preposterous. Have you ever worked for a company as a programmer or for that matter as a manager? They don't just replace products ad hoc. There's an enormous amount of due diligence that goes into any new software product - making sure it fits the company, that it's secure, that it works properly... I recently worked at a small startup who spent on sales force @ $100,000 a year. I said you know what we could do this ourselves and you know what they said as every company I've ever said that to says? "We don't want to support it. We need to cover our ass. Everybody knows how to use this"
I'm not one to sell generative AI short at this point, but this seems at odds with the longer-term trend towards more centralized, off-the-shelf solutions, like Shopify, Salesforce, Squarespace, over the "bespoke," in-house alternatives that many companies developed in previous decades. Perhaps AI is making the TCO of "rolling your own" so low that it makes sense to go back to that over SaaS?
AI, as do most things, help the big players get bigger. If someone is automating small parts of the b2b layer they get dropped, but it’s harder to drop an automation that companies are used to. I don’t see how AI is changing that, companies spent a lot of time and money to set up the automation because it’s needed and because they can write a potential replacement cheaply doesn’t mean they are going to rip away something that works and is reliable.
I would assume one major thing here is that many orgs only need a small subset of functionality from what most products provide. Many times, that small subset of functionality is only "good enough" in and of itself, but the org is paying the premium for the entire suite of whatever it is. This makes realizing that an LLM can get them to MVP and beyond much easier.
Charging hundreds of thousands if not millions per year for very basic functionality is what is "killing" b2b SaaS.
There is also the benefit of being able to use a single database (and hence schema) across multiple "apps". In many cases the complexity arises from the fact that all these apps have their own databases.
I predict the fallout from this is companies being nickel & dimed to death by a million smaller subscriptions (rather than just cutting a huge check to Workday, ServiceNow, SAP, Oracle or similar). There is such a glut of AI ISV startups that are filling highly specific niches, and some are quite good, but they're all usually in the $10-50/mo/user. Gets to be big numbers pretty quickly in a large enterprise.
There will be an exiting explosion of internal apps and tools and then it will die down as companies get back to business. All those tools and apps will turn into legacy apps and they will eventually try to migrate data off them into some saas platform because its not core to business.
Saas will have to drop prices to be competitive so fat margins will go away which will probably affect margins for AWS etc.
Sure, vibe coding has impacted user's expectations. They know you can ship a new update easier and faster than before - and you actually can.
But, not sure which successful SaaS companies just stopped shipping any updates to the product, never talked to their customers and never added any new features to win over major new accounts - and still managed to survive and thrive?
And the author actually confirms this:
> AI isn’t killing B2B SaaS. It’s killing B2B SaaS that refuses to evolve.
It's this generation's "build vs buy." I imagine it will play out the same way, like a revolving door. Customers churn because they can "build it themselves," then a year later when they're sick of maintaining a mess of code for some internal system instead of delivering value to their own customers, they come back. A blip.
- A company vibe codes their own app to replace a SaaS. Great when they only wanted a small chunk of the functionality.
- Startups benefitting from AI coding are copying mature SaaS companies and competing on price.
- Mature SaaS companies are branching out into each others domains. Notion is doing email. Canva is doing an office suite.
Or maybe there is look at true value proposition of the B2B SaaS products. It is not big spend per user, but it does add up eventually. And then savings start to look like big numbers. Big enough for some manager to justify action. This might lead cutting some seats just on cost basis.
here's the secret saas can vibe code features too on top of their paid well developed and secured api. they can get off their ass and vibe code a mcp wrapper, so user can use the ai tooling they pay for to interact with their saas. and they'd be called visionary hero of the agentic revolution.
but they don't want to. and they will be replaced, as it's good and well.
Maybe the type of SaaS that's akin to stock media (photos, video, music). Just hard enough to do from scratch, but not important enough that it needs to be exceptional in it's field. I've made some money off software like that, and it was nice, but I always knew it couldn't last. Better developers took most of it from me years ago.
there is no saas downturn caused by AI. wall street is just starting to say hang on a minute, why is this SaaS stock trading at a price to earnings ratio of 300?
then the sell-off is attributed to AI because it is far easier to say to shareholders hey we know our company lost half its value but thats actually a good thing because we need to pivot to AI and we're going to spend all our free cash flow on AI software and our stock should totally be trading at 300x earnings again in a few weeks. if you can last another few months as CEO and the fed cuts rates you'll be able to ride it out
of course, the tide is going out on a few dogs. I don't think adobe will become dominant again
you see the same trend with mass-layoffs being blamed on AI. easy way to sell bad news to the shareholders
in 2026, AI and JE are the two reasons for absolutely everything
Something notable for SaaS which this article doesn't mention is that in some cases the reason to buy rather than make yourself is due to needing to handle a bunch of different regulations which LLMs don't threaten (barring businesses which would rather have lawsuits than pay for a SaaS).
The real story isn't that some enterprise mega corp is going to vibe-code their own Workday.
The real story is that SOME startups made up of one person (or small number of engineers) will do it, and create pricing pressures against Workday, or DocuSign, or other B2B SaaS.
But if you are a mega corp, spending 0.1% of your CapEx on SaaS subscriptions, do you really want to switch to products made by some no name one person startup? You might save 0.05% of your CapEx, but if something didn’t workout, your whole business will be screwed.
To your point, I think there are 3 main categories:
1. Too big to fail (SalesForce, ServiceNow, ServiceTitan, Shopify). They’re targeting megacorps’ core business operations. Switching costs are too high. They will survive,
2. B2B non-core (PagerDuty, Vanta, Monday, Atlassian). They’re going to have stiff competition and most here will fail or merge/consolidate. They have the most to lose because they’re non-core to a business’s success and pricing pressures will cause many of them will be easily vibecoded with enough time. The large TAM here will attract hundreds of competitors each.
3. Consumer SaaS (Notion, Canva, Grammarly, Dribbble). They're good as dead and can be buried.
We will have to go through the stage of disillusionment of what AI is and understanding of what it is not. There is too much FOMO and too many stories driven by the heavy-AI-invested parties today to see thing clearly.
A middle 100-500 heads firm don't need enterprise level SaaS, a vibe coded website will suit them better.
Fundamentally, those workflow/orchestration SaaS needs to answer the question why people should pay you premium while only getting 80% where they want to be.
For the most part, you can replicate any B2B SaaS product in a spreadsheet. The same reasons why spreadsheets didn't kill B2B SaaS apply to "in house vibe coded SaaS replacements." The original in house apps are (and continue to be) spreadsheets.
I think people here need to accept that software is becoming electricity, you get charged when you use it and by how much. You don't pay for a box shaped electricity or purple color electricity, it is just electricity.
The reason for divergence is actually much simpler. NASDAQ 100 includes data center builders, Morgan Stanley software index doesn't. Stock market is going down across the board if you exclude data center construction.
How corporate incentives are aligned will also define the trajectory. The person who is going to take the call whether to go for vibe coded tool or external vendor has to have enough incentive to put this neck on the line.
Imagine this, you are VP of finance. You know you can get a nice tax calculator built quickly using vibe coding, but will you put your neck on the line and say, let's replace the existing vendor and use my vibe coded tool. You might fired if you send a wrong tax report to your auditor.
Let's take another example - VP of sales wants performance report and visuazliation of the sales team. He has 200 BDRs. The daily sales standup depends on this report, team gets yelled at or praised basis this. Now, will this VP be willing to put his neck on the line and say - let's use my vibe coded report and discard the existing SaaS. Even if such a report feels trivial, it is vital for functioning the sales team and hence, it needs to be reliable.
I think vibe coding will work at prototype level - the trust gap is very huge right now to even consider it for internal tools.
And, until vibe coded tools are stress tested enough this trust gap will not be fulfilled. Think about this, why some of the biggest companies in the world still run on softwares built in 2000s.
It kills low hanging fruit SaaS that was always just some minor piece of functionality wrapped in a subscription model usually based on 99% open source and 1% actual contribution.
Sounds like a lot of products will be in trouble if AI becomes more advanced with producing secure code with maintenance processes to keep evaluating code on an ongoing basis
Remember when businesses ran on cobbled together access databases and vb? It was easier than building something ny prompting an llm.I made a good living just rewriting those things for them when they fell apart.
This was the same hype around NoCode a few years ago. Thing is people for software as a service and internal teams dont want to do the service part. A common thread among all of the vibe coded stuff I hear is that nobody talks about the next requirement which was handled. Frankly UIs are learnable and after a few tries everybody gets used to it. The extra polish is totally not worth it. Eventually every SaaS on the non-critical business path gets ripped out with one of the platform players such as SAP, SalesForce etc which are infinitely customizable. Salesforce even has its own language in which customers write their apps.
The system of record bit is quite correct and imo the only durable advantage. But that doesnt explain why Klaviyo shoyld worry. In fact marketing workflows are some of the most important systems of record directly tied to business earnings.
The assumtpion that in SaaS you build once and everybody uses it is false. There are always customizations or features that need to be built for big contracts. Its the small players that are okay with out of the box SaaS since they lack the budget to pay for a customization. Ironically, these teams will get hurt the most should they choose to go down the vibe code everything path. Here infra capex is far lower than payroll and owning too much software (vibe coded or not) will simply steal time from business development.
Honestly, the market just panicked and caused a temporary correction thats all. Then we all got busy and wrote a bunch of thought leadership crap on top.
In reality AI is the best thing to happen to SaaS companies since it reduces RnD time and expenses, allows even small players to bid for large contracts without overloading existing dev capacity and also makes it possible to put devs in front of customers since now there's no need to sit down and code. AI is also the best thing to happen to engineering since it now allows for product management to be folded into the existing craft.
I am building a desktop app that deploys and manages high availability postgres instances on VPS right now..
The AI is constantly failing at helping me because its about generating and managing remote configuration that is very fragile if something is missing.
I don't think AI is killing B2B SaaS so much as companies are finally reckoning with the immense costs of SaaS in a markably different environment than when SaaS exploded in popularity, and AI offers an off-ramp to some. Let's break it down camp-by-camp to show you what I mean:
1) The must-haves. These are your email and communication systems, the things you absolutely have to have up and available at all times to do business. While previously self-hosted (Exchange/Sendmail, IRC/Skype/Jabber, CallManager/UCS), the immense costs and complexities of managing systems ultimately built on archaic, monolithic, and otherwise difficult-to-scale technologies meant that SaaS made sense from a cost and a technical perspective. Let's face it, the fact nobody really hosts their own e-mail anymore in favor of Proton/Microsoft/Google/et al shows that self-hosting is the exception here, not the norm - and they're not going anywhere regardless of how bad the economy gets. These are the "housing stock" of business, and there's plenty of cheap stock always available to setup shop in without the need for technical talent.
2) The juggernauts. The, "we can do this ourselves, but the pain will be so immense that we really don't want to". This is the area where early SaaS solutions cornered and exploded in growth (O365, ServiceNow, Google Workspaces), because managing these things yourself - while feasible, even preferable - was just too cheap to pass up having someone else wrangle on your behalf with a reasonable SLA, freeing up your tech talent for all the other stuff. The problem is that once-focused products have become huge behemoths of complex features that most customers neither need nor use on a regular basis, at least after the initial pricey integration. Add in the ease of maintainability and scalability brought by containers or microservices, along with the availability and reliability of public cloud infrastructure, and suddenly there's more businesses re-evaluating their relationships with these products in the face of ever-rising prices. With AI tooling making data exfiltration and integration easier than ever from these sorts of products, I expect businesses to start consolidating into a single source of truth instead of using dozens of specific product suites - but not toppling any outright.
3) The nice-to-haves. The Figmas, the HubSpots, the myriad of niche-function-high-cost SaaS companies out there making up the bulk of the market. Those whose products lack self-hosted alternatives risk having vibe-coded alternatives be "good enough" for an Enterprise looking to slash costs without regard to long-term support or quality; those who compete with self-hosted alternatives are almost certainly cooked, to varying degrees. If AI tooling can crank out content similar in quality to Figma and the company has tech talent to refine it for long-term use, why bother paying for Figma? If AI tooling can crank out a CRUD UI for users that just executes standard REST API calls behind the scenes, then why bother paying for fancy frontends? While it's technically interesting and novel at how these startups solved issues around scaling, or databases, or tenancy, the reality is that a lot of these niche products or services could be handled in-house with a container manager, a Postgres instance, and a mid-level IT person to poke it when things go pear-shaped. The higher per-seat prices of a lot of these services make them ripe for replacement in businesses comfortable with leveraging AI for building solutions, and I expect that number to grow as the tools become more widely available and IT-friendly in terms of security.
Ultimately, the core promise of SaaS to business customers was all the functionality with none of the costs of self-hosting support. Nowadays, many of them have evolved into solutions that are more expensive than self-hosted options, and businesses that have shifted IT into public clouds or container-based systems have realized they can do the same thing for less themselves, at the cost of some UI/UX niceties in the process. Now that we (IT) can crank out integrations with local LLMs with little to no cost, we're finally able to merge datasets into singular pools or services - and I'm not talking about Snowflake or its "big data" ilk so much as just finally getting everything into Salesforce or ServiceNow without having to bring in consultants.
The must-haves and many of the juggernauts will remain - for now. It's the niche players that need to watch their moats.
That's a great point. The restaurant business is one of the worst you could possibly go into, with razor thin margins and astronomical failure rates. If those are the future economics of SaaS (accustomed to 70-80% gross margins), than you ought to cash out now while you still can.
SaaS’s competitive advantage is not tech but distribution.
Just because the stock market dips, and a bunch of media outlets ascribe this to AI doesn’t mean that AI ‘caused’ the dip.
If people really think non-tech businesses will start running their own software organizations and maintain all these tools themselves is an idiotic assumption at best.
The “building” of software has never been and will never be the bottleneck.
People have been debating what "real" development is for as long as there have been computers. "That's not real software development, you're not even controlling which registers you use!" "How can you say that's real code when you aren't even managing your own memory!" "That doesn't look like C, must not be code!" and on and on.
At the level of the old adage about whether the horse-drawn buggy-makers are in the buggy business or the transportation business, it's all telling the computer what to do in the context of providing a customized tool that you or others might use. So in this context, a customized Excel spreadsheet counts. And so does a vibe-coded app.
And of course, wringing our hands about what it looks like now totally ignores the fact that it's not going to be like this for more than a year or two at most.
How long until a user can reasonably say to Claude or similar, "I need Bob here to track production at my factory. Lay out a set of tools to do that, and make sure they're layered with help and tutorials so Bob can learn on the job because he doesn't know anything. Don't let him make any mistakes."
That's probably not coming next year, but certainly it's not ten years away.
Having worked in enterprise B2B SaaS for a long time, almost every feature I built could have been a simple spreadsheet or some emails. So I'm highly skeptical AI is going to change anything.
Enterprise sales basically works like this: A non-technical sales team aggressively promises everything to win a deal to a non-technical procurement or exec team. When the deal is won, the SaaS sales team tells engineers "go build this" regardless of how stupid it is. And the customer tells their employees "you now have to use this SaaS" regardless of whether it makes sense.
no. High interest rates and a cautionary view of future economic growth are killing B2B SaaS. Money is no longer free, and so there is a bigger push for cost-cutting rather than growing your buisness with free money.
AI is killing this. Millennials are killing that. Gen Z certainly must be killing another thing. And Yarn? It was killing NPM. This nonsense type of title really was made for a world where nuance doesn’t exist.
B2B SaaS is projected to grow over the next decade, not shrink. Just use the LLMs and you’ll be reminded of the value provided by the company selling non-core but important tools for your business.
A link shortener is such an easy thing to code, it's essentially one database table with a redirect. To add to that, there are many open source libraries to implement link shortening, including analytics and stuff. Even then Bitly and Rebrandly have customers (from their website) like Toyota, Cisco, Oracle, Monday.com, New York Times, etc.
Are these companies unable to build a link shortener? It's also so easy to migrate off shortener service. If they can and still choose to use these shortening services, there must be other reason. And that reason is that they simply don't want to. This has nothing to do with AI.
I run a software company and one of the reasons customers say they want to migrate from their homegrown spreadsheet is because the guy who built it left. A freaking spreadsheet!
Such blog posts and probably many comments here are the perfect answer to "Tell me you don't run a real business without telling me you don't run a real business"
Regarding your last comment, majority of the people here are costal with FAT paychecks slinging code for VCs. It’s a totally different universe than running a Saas. That said, still a valuable forum.
Until Claude Code comes with indemnity insurance for HIPAA / GDPR / etc… B2B SaaS is here to stay. You want me to convince my auditor that the vibe-coded in house software handles PII correctly?
Making the audit someone else’s problem is 90% of the ‘buy’ value in ‘build vs buy’
Spot on. You could argue that most companies buying B2B SaaS could almost always build a clone internally but they need someone to assume SLA and liability.
I wouldn't say that AI is killing B2B SaaS, let's analyze the situation: AI is shifting the boundaries of the Build VS Buy decision.
If software is cheaper... building it seems a much better option but...
...the fact that software is cheaper means that SaaS companies will be able to be more competitive with price, offering more features, integrating them much better with the newest agentic tools and frameworks that are getting released.
Sure, the market will adjust, some will be pushed away, others will find businesses that weren't possible before... but we're far away (I hope) from the AGI revolution, don't forget to see this crysis as an opportunity too.
I've worked in SaaS for most of my career, only recently working at a big corp who is largely the buyer and user of SaaS tools to meet their objectives. From the perspective of the corp business buyer, they want something that works for their needs and they want to buy something instead of build it because the support costs are gnarly. They already have engineers dedicated to the tools they've purchased. Much better to put the risk on someone else they can yell at. And the permissions and access to these tools, reports, data, is usually its own special problem to manage. Building a lot of one-off tools is going to just give IT a huge headache and they will push the org to buy before vibe coding a solution.
Look, software is not going away even though everybody thinks they're a developer now. Do you think companies are going to replace Microsoft Windows, of which there are a billion installs, or Salesforce, Crowdstrike, Quickbooks etc, with some Vibe coded AI slop an intern "coded"?
When enterprises/businesses in general upgrade any software in the company it takes years sometimes... There is also Vendor lock in, you can't just swap things with vibe-coded slop, and trust me your manager will never want to do that either because his butt will be on the line.
I disliked how SaaS CEO's were decrying the death of engineers. Their coordinated layoffs over the past years or so was excruciating to watch and experience. Their language was aggressive and inflammatory.
Although the article may also be hyperbolic, I'm not going to comment on reasons why it might be. Instead, I will agree, and think SaaS companies stock performance this year will be proof. Sure, it might not be the collapse that AI doomers are hoping for, but all the FUD they spread over the past few months to years will signal that they're not insulated from it. They made their cake, now they have to eat it too.
At the end of the day you do not need to replace your B2B SaaS with AI.
You need your B2B SaaS to think you can use AI to replace it though, so said SaaS will keep it's prices reasonable. Otherwise they have you by the balls and will charge you much as humanly possible.
If that would be true, expect in the next decade a frantic search for seclusive grey beards, those who haven't given up their rituals and ancient languages.
If your workforce is vibing all day, they will have no capacity for maintenance, because it isn't their code. So the maintenance that happens will be slop and more spaghetti. I am not saying cases like that never existed before, but such companies will face a moment of truth sooner or later.
The survival advice here — 'be a system of record,' 'make switching painful with compliance' — is exactly the playbook that makes customers want to leave in the first place. The deeper question is whether vibe-coded replacements will rot fast enough to send people running back, or whether AI gets good enough to maintain them too.
No it isn’t. Writing the code was never the issue with making software, it was designing it.
You can shit out an app with AI, just like you could with Indian workers. But that doesn’t mean it will work properly or that you’ll be able to maintain it.
And most importantly, it only works for code they could steal from GitHub. It has no idea how to replicate sensitive systems which aren’t publically documented, and those are some of the most valuable contracts.
> how they’re potentially losing an $X00,000 account just because the customer can’t use a specific failure reporting workflow in the SaaS. They’re now working with me to build what the customer needs and retain them.
You mean the poor SaaS company actually now has to implement features needed by customers??
Just a single data point, and I‘m not pretending it’s a conclusive one (yet), but I think there is a middle ground between buying a SaaS and vibe coding a replacement: replacing a SaaS with your own solution, using AI coding agents — while actually knowing what you do because creating robust software in-house is already a core competency. No vibe coding needed.
At my company, we build software every day because our business is running a job board.
We always had kind of an impedance mismatch when it comes to creating content pages (think landing pages for marketing).
Yes, we can do this ourselves, but then software engineering resources are in conflict between shipping the next feature and creating landing pages.
So we introduced Webflow. Now marketing could create their content themselves. Did it match our corporate identity? Hopefully. Was it technically sound? Sometimes. Was it fun for software engineers to fix things in Webflow. No.
It kind of worked, but wasn’t exactly ideal.
Meanwhile, software engineering became more and more productive with the advent of AI coding agents, Cursor in our case.
So we tried another approach: giving our content creators Cursor.
But that was brittle, too: Cursor presents an overwhelming complex UI for someone who never used an IDE before, it could do a thousand things while only three are actually needed in this use case, you have to explain git on top of Cursor. It kind of worked, but only kind of.
It’s like a hyper-focused „Cursor light“ in the browser, so our content creators can just „chat away“ and create their content pages, with all the guardrails baked into the product. Getting tracking pixel integration etc. right just works. Matching our style guide perfectly just works.
And as a bonus, there is a whole git based storage and versioning workflow underneath, so software engineering can support and test and deploy the results with their preferred tools and methods, but none of this complexity leaks through to the content creators.
We built this ourselves in days, not months, thanks to Cursor, but it’s not vibe-coded — it’s a rock solid application that we will support and improve long-term without headaches: https://github.com/dx-tooling/sitebuilder-webapp
No.. just.. no.
This will be a thing for like 1, maybe 2 years, then people will realise it doesn’t make sense to spend $50K of time per annum to replace a $500/month subscription for a better product.
for profit software is pretty gross tho. it can be made indefinitely complex, and people can make and sell tools to patchwork the complexity together, but then u need more tools to patchwork all the tools together ...
and u end up in aggregators aggregated aggregators type situation where optimal solutions never arise because we don't actually cooperate enough to produce them
ai is fitting into the notion that this is all bullshit ... even if not in the correct way
One point is now you dont have to pay money to 3rd world countries like mine :(, you can manage with fewer resources inhouse. AI will take care of slop work.
Honestly, I'm surprised by how people are pushing back against this idea. I feel like vibe coding is just in its earliest moments of actual viability, and my mind is totally blown by it, and it strikes me that it's exactly what I've always wished software could be. Plastic, flexible, personalized, effective, responsive, organic.
As an anecdote, I've been vibe coding an accounting system that perfectly matches with my own expectations of accounting software, i.e., it's intimately connected to CSVs, imports and exports from CSVs, but acts as a kind of enrichment and reporting and file association layer. If there was anything like this, any kind of SaaS that I could have and download as software and run on my own computer offline and be able to inspect and trust and version control so they wouldn't add or remove some kind of feature that I wanted down the line, then I would have gone with that.
But now I have essentially my absolute ideal solution, written with a Python backend and Vue and JavaScript frontend, and it's radically improved my ability to maintain accounting for our business account.
And I think there's something really important to point out here, which is that the feeling of lock-in is very seriously reduced when you are Vibe coding your own software, because if you don't like the way that it works or you realize that there's something missing, you can add it pretty painlessly. Like, that's always been a huge challenge with choosing vendors for a SaaS platform, is you think, oh no, well, what if their conceptual model for what I'm trying to do doesn't quite map onto our own internal systems or understanding of what's being done? Well, when you have your own Vibe-coded SaaS, you can just add that information. So there's something incredibly organic about it. I used to work at a startup in Redmond where we built this large internal system to manage a scientific process with lots of machinery and data, and it was incredibly empowering and actually became one of the core values of the business that was able to be licensed to other businesses in the same industry. And it seems like we're just improving that capacity from here.
Now obviously, if Vibe Coding magically were to go away or became much more expensive, then I'd have this legacy piece of software, which I couldn't improve, and that would be a dead end. But my expectation is that the functionality that we have today will only improve. And in several years, the scope of changes that I'll be able to make, the level of professionalism, modularization, maintainability, code quality, will only improve. And so this has me thinking in general that software is kind of undergoing a step change where we're moving into the so-called age of intent beyond the age of the interface. And that's tremendously exciting to me, and I just couldn't be more stoked about it.
It's a tale as old as time that developers, particularly junior developers, are convinced they could "slap together something in one weekend" that would replace expensive SAAS software and "just do the parts of it we actually use". Unfortunately, the same arguments against those devs regular-coding a bespoke replacement apply to them vibe-coding a bespoke replacement: management simply doesn't want to be responsible for it. I didn't understand it before I was in management either, but now that I'm in management I 100% get it.
OTOH, I was hired by an enterprise that was many months into a giant backend rewrite. After wrapping my head around the many plans, I realized they were rewriting Django, badly. One weekend I prototyped the whole thing… in Django. It worked. It met the specs. It was a CRUD app with a REST API.
I came in to work Monday morning, showed it off, and inadvertently triggered a firestorm. Later my boss told me not to do that again because it caused havoc with schedules and such.
So I quit and found a better job. Sometimes the new guy can make a better version themselves over the weekend, not because they’re a supergenius, but because they’re not hampered by 47 teams all trying to get their stamp on the project.
(In before “prime example of overconfidence!”: feel free to doubt. It was a CRUD app with a handful of models on a PostgreSQL backend. They were writing a new Python web framework to serve it, complete with their own ORM and forms library and validation library. Not because the existing ones wouldn’t work, mind you, but more out of not realizing that all these problems were already sufficiently solved for their requirements.)
In the beginning of my career, I've been once told by my senior management that I should never again:
1. Optimize things so that they work 10 000 times faster because it makes us look incompetent (must be done slowly to show gradual progress).
2. Brag about such optimization (to stakeholders) without first synchronizing this with them (so they can brag proportionally to their pay rate :) ).
This is the prime example of Law 1 of Robert Greene's "The 48 Laws of Power": "Never Outshine the Master."
The core principle is to always make those above you - your bosses, mentors, or superiors feel comfortably superior.
If you display your talents too aggressively, you risk triggering their deep-seated insecurities, which can lead them to sabotage your career or remove you from your position.
Galileo Galilei handled this really well. When he discovered the moons of Jupiter he strategically named them after the ruling Medici family.
By making the discovery about their greatness rather than his own intellect, he secured their lifelong patronage.
However, if your superior is a "fading star" or is clearly about to fall, you do not need to be merciful. In these cases, it may be strategic to outshine them to hasten their downfall and position yourself as the natural successor.
Sure it has been codified into a "law" but really this is just basic social skills / emotional intelligence which engineers on the spectrum struggle with.
If you've spent any time in a large enough organization you realize quickly that hierarchies form based on status, power and influence & not necessarily technical merit. No it's not "the best person for the job" that rises up and tells you what to do.
Casually solving a problem that required a lot of resources and personnel has big implications in the power dynamics of the org. This is like setting off a nuke. You don't just do this unless you are prepared for the blow back or can easily consolidate attention & influence in the immediate aftermath.
Take a look at OpenAI's corporate politics for an example of how this works in practice. All the key talent that defined the company has left or was forced out and will likely languish in whatever ventures they start next, all because they don't understand how humans operate & how to drive change by aligning incentives.
It’s hardly basic social skill. This is an executive management skill set. That’s the advanced game.
The basic social skill is to avoid conflict and seek acceptance. Go along to get along.
One wouldn’t rewrite the app on one’s on recognizance without peer approval first if this is your vibe.
some people discuss these dynamics as sheep versus goats. Social stability was more precious due to scarcity, while goat behavior included 40 armed men killing their rivals with swords (and better if the rivals do not have their own swords). Many, many parallels exist in mammals that live in groups. You might be surprised at the details of how some mammals actually behave in real life!
Competent management says:
"Look how clever we were to hire this person and put them in the right place at the right time! We are now ahead of schedule and are reallocating teams."
There's remarkably little competent management.
My rule had always been "hire people smarter than you and give them everything they need to succeed". Set a clearly defined goal, ensure understanding of the reasons behind it then provide the support the team needs to make it happen.
Ditto. And then celebrate them like crazy for every win and give them all the credit, even if you helped. Who wouldn't want to do their absolute best work in an environment like that?
doesn't even need to be "smarter than you", just realise that as a manager your job is not to build the product, it's to build the environment in which the people building the product can thrive and build the best product they are capable of.
It seems like you are suggesting it is lamentable that a group of people with the analytical intelligence to create a technology that has changed the world, don't have the social intelligence to be irrational when that is called for? Shouldn't we instead hate the game itself and lament that leaders can't behave rationally? In my more frustrated moments I wonder about a world following a disease that eliminated all neurotypical people.
But then he went on to spite the pope for no good reason, leading to all that trouble with the church.
>>> Galileo Galilei handled this really well
Errr… Galileo was asked to write a book discussing both sides of the heliocentric / geocentric debate … and so wrote a book with two characters having a debate while walking in a garden - one named (I paraphrase for effect) “Galileo” and one named “Pope Simplehead”
Needless to say the next twenty years under house arrest gave him a lot of time to think about character names :-)
Thank you Machiavelli
great perspective and wisdom nuggets.
This was the moment I’ve stopped putting any effort in my work.
Sounds like when I was asked to give minimum hardware requirements for something doing backend processing (receive text submitted as print jobs, massage, send to printers).
The requirements as they went out were much higher than they needed to be, because I decided telling them that we weren't stressing anything on the obsolete NT desktop repurposed as the test system might not please everyone.
IMHO I think the best any engineer can do in an org is to ask "what is the highest value problem to solve for the business" and "can I solve it".
"I made this x times better" is not relevant to _most peoples in any org_.
That's the dark secret. Nobody cares how good of an engineer you are _unless there is a fire to put out_. After which you get pat on the back and back to usual business.
There are situations where years of impeccable, high value diligent work is rewarded.
But what is more common is that the rewards go to those who are in politically expedient position to get the rewards. Favourites, culturally aligned folk, etc. And sometimes it's not even about you or your boss, but the politics in the organization at large. "You are not allowed to promote anyone due to budget" is a very common thing.
So I guess what I mean to say is if as an egineer you want to retain your sanity, when at work focus on maximizing business value. If you know a kick-ass solution that is 10000x better than industry standard go with it but know this - nobody will care! Nobody believes _someone in their org_ could have beaten _industry standard_ unless the org is very unique. What you get is small increase in your reputation - and sadly nobody recognizes how hard that was. Maybe you will meet some other engineer at some point who has tackled that same issue - and then you can bond over the solution.
A large part of software ecosystems is about business, politics, and the large scale impact of technology.
Saying this as an IC whose previous tasks at previous employer could have employed _teams_ but since we were allowed to deal with them smartly it was just me.
So if you know a 10000x solution to a problem many people have - that's a good opportunity to consider can it be productized!
The sad corollary to "you will be noticed only if you put out fires" is nobody actually realizes the elegant solution you shipped will stop tons of these fires from happening. Rather the reaction will be "that looked simple and easy so probably is not important".
And on the other hand, the complexifier (you know the type) ships rude goldberg gizmos just waiting to go off-kilter - and then they come in and save the day - and get rewarded. This creates a very strong "emperor has no clothes" syndrome until reality hits the organization really hard in the face. More often than not these horrible solutions are "good enough" and the show just goes on.
Don't take it too seriously! That's what people are like!
> The sad corollary to "you will be noticed only if you put out fires" is nobody actually realizes the elegant solution you shipped will stop tons of these fires from happening. Rather the reaction will be "that looked simple and easy so probably is not important".
Or that reaction is really "that looked simple, easy and like the last 10 "elegant solutions" that caused fires".
Yes! There are also very good reasons for deep skepticism.
Just smear the heck out of them to stakeholders, after implementing something big and climb over these incompetent shmucks and watch their fall
Also make sure to brag using terms that non-technical people can understand and want to hear. Less "we stopped writing an in-house CRUD that was Django but worse" and more "we saved months and increased security by adopting a market leading solution and it works better with AI too".
While probably facetious, those with power (who you aim to smear and replace) will save themselves and work together to fire you ASAP. This is not a winnable battle nor strategy for success, unfortunately.
This 100%. I once got disciplined for insubordination for skip-leveling my "manager" and disregarding their instructions when she started telling people on the team to work on something totally non-critical, when the team had a demo in a few days that wasn't ready yet, with a client that was already unhappy, on an 8 million dollar contract.
I didn't hang around that place long.
Did they know something you didn't know, about that demo/client? i.e. misaligned incentives?
The opposite, they were 12 hours timeshifted and out of the loop managing a side hustle while I was interacting with the client daily.
If I can only go back in time to 2007 :)
See also, test the flammability of every bridge you cross.
Unless you were working at a startup full of very naive people, I gotta say this sounds made up.
If people at startups weren't slightly naive, they wouldn't attempt an endeavour that has such a low success rate :)
This happens all the time.
Basically build vs buy. The problem is on the 'buy' portion of looking at things the company failed. So they took who they had on hand and built something. It took a fresh perspective to say 'hey have you tried this' and looks like they did not want to hear it. I would say the right choice was made to move on.
This is wildly common. At that point they were committed to the wrong path at 'above my pay grade levels'. Once you get that buy in you better do it that way. Most companies will not pivot unless the champion for whatever is going on is removed in some way.
At 'my paygrade' I can prototype tech but I better make a good case why I need everyone else to do it too. If I dont I will be summerly ignored at best, at worst 'the guy with the lets rewrite the system hahahaha' guy. I might even be right about it. But the probelm is a jr level guy is not going to have the political cover to make it happen. Even if they are right.
But if you can get 'the higher ups' to buy in. Then it is quite dramatic how much better somethings putting that sort of tech in. Then other times it can be a total disaster. So you have to pick your hill to die on.
Yes, but that's not what the specific comment I replied to is saying.
It sounds like pure junior dev fantasy that anyone would care beyond whether it meets the explicitly stated requirements.
Any other flourishes that the devs add are going to be unused or ignored, and that definitely includes what the devs think about their own work.
I can relate to this so much. When I was a newly joined Google consultant at a partner firm, we went to their office - some 13 different types of cuisines, different types of game rooms, lounges and what not. A luxury star hotel experience. We were waiting for our meeting on behalf of this one particularly large media client who was bleeding money on Wordpress.
3 engineers arrived - fashionably late. We explained them the situation and all we wanted from them was some GCP offering that would cure our woes and one that would cut our bills. The senior consultant - and presumably the only tech guy (rest seemed to be salesy) wasted our time like a used car salesman - he didn't even understand Google's own product portfolio and recommended us to use something like Spanner - which was totally not the solution to the problem, not to mention, expensive.
My boss and I left the meeting pissed off and he told me - "Neya, you probably know more about the product portfolio than these guys. Let's leave". That weekend, I went with my tried and trusted favorite Db - PostgreSQL - CloudSQL with a custom Elixir middleware based an old CMS I wrote a decade ago. After some trial and error, the solution worked flawlessly (and still does till date on auto-pilot). My client still has the lowest cost in the region - 1/3rd the cost of their competitors...7 years later. Back then, there was no vibe-coding, no AI, no auto-completion. Just pure thinking and experimentation.
All this just to say I agree that the new guy sometimes can make the best solutions to a problem and not always screw up. I always listen to new hires these days (now I'm a fractional / CTO) because you never know who could pull off that 1/3rd cost cutting framework move.
Nice work!
Sometimes those complex solutions are the right tool for the job. And other times, you just need to glue some stuff together, call it good, and start making money.
Experience helps a good engineer know when each approach is appropriate.
Thanks, totally agreed.
Thanks for sharing! Every time I see a post about Elixir and how it Just Works™, I get an urge to learn and build something with it.
One day I'm gonna build some sort of product in Elixir. I was super interested in LiveView when it was announced and I think the component story has gotten a lot better than when I tried back in pre-1.0 days.
This video by Sasa Juric is still the gold standard (imo) of Elixir demos for anyone who hasn't seen it: https://www.youtube.com/watch?v=JvBT4XBdoUE
Definitely give it a shot. It's a wonderful language and the rewards are immense for the little effort you put in. I promise you, you'll never look back once you fall in love with it!
It’s funny you complain about the sales pitch the guy gave you, but the comment itself sounds like a sales pitch :)
IMHO it sounds more like someone who is proud of solving a problem for very little effort that Google tried to sell a very expensive solution for.
Thank you, that's exactly what I was trying to convey
Hey, really sorry, I'm genuinely not trying to sell anything (I don't have a product to sell...yet). I can see why you might have interpreted like that though. And it's unfortunately too late to edit my comment. I'll try to think less sales-y next time.
I think you need to calibrate your perception of things you read.
> Later my boss told me not to do that again because it caused havoc with schedules and such.
Did you talk to anyone about your plans before you brought in the demo or let them know they were solved problems? Often these sorts of reactions come down to your boss not wanting their team to lose their jobs because of the perception that it can all be handled by one person who's happy to work weekends.
I wasn’t politically savvy enough to do that. Honestly, I don’t want to be. The reality was that the project really could have been done in a month by a couple of people. It got turned into an enterprise project with multiple unaligned teams with Gantt charts and milestones and everything.
Again, and I can’t emphasize this enough, for a Django CRUD app. It was a 4 person-week project turned into a major ordeal. No one should have lost their job; they should have been put to work doing the thousand other more productive things they could’ve been doing instead.
> No one should have lost their job; they should have been put to work doing the thousand other more productive things
I think that's exactly why you should have talked to your peers and let them know they were solved problems, unless the overengineering was intentional.
Sometimes you can explain things and not be heard until you demonstrate them. Then they have to accept that you’re not just BSing, that your idea does have at least some merit.
Also, never underestimate an enterprise’s ability to convince itself that it’s too big and complex for off the shelf tools. Sometimes that’s the case. Very often it’s not.
In this case, I’d also watched this all take shape over a couple of months. Being the new person, I assumed it was some necessarily complex beast that was beyond my scrappy experience and calling for Serious Engineering. Once I recognized it for what it was, I knocked out my weekend project shortly afterward because I couldn’t get it out of my head. As much as anything, I had the need to see if it really was as straightforward as I thought it could be. I didn’t sit on my idea for months while they toiled. I watched them toil for months before I understood the core of what they were making.
> Sometimes you can explain things and not be heard until you demonstrate them.
1000%. In my experience this isn't even a "sometimes". It's the opposite. Explaining/arguing in the abstract why a significant directional change is needed has little persuasive power. If you can demo something, you actually have a fighting chance, even if it barely works. It can be a working product, it can be charts, it can be a semi-functional mockup, whatever, but you have to show _something_ that isn't just talking about it. I learned this the hard way after advocating for things and getting shot down too many times.
> Also, never underestimate an enterprise’s ability to convince itself that it’s too big and complex for off the shelf tools. Sometimes that’s the case. Very often it’s not.
Couldn't agree more with this, also. I've seen an astonishing number of homemade job runner systems, homemade message queues, homemade databases, homemade web frameworks, homemade languages, etc.
One can make the argument that this is how technical progress happens, and in some sense, that's true (we wouldn't have a lot of nice things if this never happened), but it's rare. Like, really rare. Most shops would be better served with e.g. Django, Postgres, and HTML, deployed on Heroku (or your Heroku-equivalent of choice) rather than spending hundreds of human-months building "an ad hoc, informally-specified, bug-ridden, slow implementation of half of $COMMON_OFF_THE_SHELF_TECHNOLOGY".
So, I completely agree with you.
Wow, that just gave me a PTSD shudder. I started at one shop and they had a small team continually fighting against their home rolled message queue and task runner. After joining in the fray, asking about a million questions about why this is done like that, etc., I talked them into replacing it with a stock Python Celery setup. The original author of the local version protested, understandably, explaining why it couldn't possibly work.
It worked. It didn't require handholding. It continued working after I left there.
My coworker was a smart guy, but he got it in his head that their specific use case was something that couldn't possibly be served by a COTS project. Turns out, it could, and easily.
This story is more common than any of us would like to admit, myself included.
I can say this with some confidence because as a junior developer, I was often that person, and I didn’t really understand the collective lessons contained within e.g., Rails, Celery, etc.
I was enamored with doing something “cool” and “interesting” and I didn’t realize that this was distinct from and not actually as cool as solving someone else’s problem on time and under budget.
Easier said than done. If a company is in that situation already it's due to a reason. A new middle-manager would have a hard time convincing anyone, let alone a new IC. IMO you just go down with the flow and enjoy your new salary (which should hopefully be higher than the previous one) or start looking for your next gig
And it’s possible that it wouldn’t have mattered anyway.
I got a green light to do an integration in a week alone, which was planned for a team of 5 for half a year. We knew that it cannot be that much. So I delivered…
It was never used. It was purely political. The integration didn’t happen because it was “half a year”, but because middle management didn’t like the idea of integration for political reasons.
> I wasn’t politically savvy enough to do that.
Over the years I’ve come to realize that what people call politics at times is just having interpersonal skills.
In this case, more like common sense.
I mean yeah what did you think politics meant?
I've been in a similar situation, with a laravel product quoted for over a million and I quoted 40K and did it all.
That did not go down well, even though it was a great product, styled etc. had all the bells and whistles.
> That did not go down well
Enterprise customers are more likely to use a product that they paid $1M over the same product that they "only" paid $40K.
If it was a one-time contract and you get paid for it, what they do next is their problem, not yours.
It was a case of pay $1M and take no responsibility vs. set a budget of 40K and own it internally.
When salesforce leaks your customer's information, whoopsie! not our fault! it's salesforce!
And yet they're far more likely to have the leak. BASICALLY.
In fairness to Salesforce, it was the garbage third party apps in their ecosystem which got compromised and did the leaking, not Salesforce themselves.
you got paid the $40k though?
Nope.
> Honestly, I don’t want to be.
I don't get it.
On the other hand, programmers are happy to work with AI, which is incredibly limited and a pale shadow compared to the real "I" in educated and experienced meat brains.
Also, networking - in both space and time (among the living, the latter with the dead, one way from them to us) - is THE gigantic advantage of humans. Not to want to bother with it is an equally gigantic mistake, if you want to use being human to more than a tiny fraction of its potential.
If you are interested in creating solutions and useful systems, "politics", human networking, should be THE number one priority. Long before anything technical.
Important scientists and engineers were great networkers and communicators. They also knew which connections where worth making. Just like in the brain, fewer good connections are better than wildly cross-connecting everything.
Some people like blowing things up, even if it doesn’t necessarily make sense at the time.
Some people like building things, even if it doesn’t necessarily make sense at the time.
Some people like meeting other people and making money, etc, etc.
Know thyself.
What you’re saying is true. Yet, I can only willingly go along with so much terribleness before it hurts my soul. We only have so many days to do things we care about. The thought of throwing away 6 months of them for no defensible reason horrifies me, and I can’t, won’t, participate.
Edit: for a compensating control, I pair with senior leadership I can directly ask about this things. “Hey CTO, is there a reason we’re doing this thing so ass-backward? No? Can I go fix it then? Thanks!” Or, “oh, because we’re stalling to avoid this horrible customer’s demand, and no one’s really going to be working on it as their day job? Sigh, alright, I’ll look the other way.”
I let them be political so that I don’t have to be.
You’re doing God’s work. Don’t let the bastards grind you down. Keep building.
I couldn’t help it if I tried. It’s who I am.
I'm not good at office politics, but I got better at not caring. Understanding what is erroneous stimuli, as an employee you don't have to respond especially if you aren't noticed. This is fairly easy for engineers, even lead engineers. Anywhere there is a buffer between you and other stakeholders.
Occasionally though, I do get thrust into it, mostly during a company pivot about something I wasn't hired to do. All the personalities to manage, I 100% fumble, but still deliver.
Omg! Who the hell cares if the "boss" got a heads up. When I'm in engineering or you're in engineering with me, we party the same way: better is better.
The bosses - hell management's job leading into organizational culture - is to stop politics from derailing good engineering and customer satisfaction.
It's not too tough for me. Now that you know where I stand the other side better get it's act together.
Drowning in politics helps nobody including the boss. It's a net loser.
Now I'm practical and empathetic: a surprise can bring heat. But then you breath and get a grip. Cool. But thereafter the right things better get done. Politics for a day - np - politics sapping know how making cynical SE'S think twice? Never.
I learned a lot from that job, mostly how not to lead people. Subsequent jobs that I’ve been at for longer stints have placed much more emphasis on delivering good work than on building complicated plans to someday hopefully maybe consider delivering good work.
replace your boss
That’s what I did here, by going to a new place that wasn’t fundamentally broken.
Oh I have seen this story and was the one who caused this story when I was younger.
In a lot of cases the "new guy" thinks its an easy software and does it on his free time and thinks he did a great job.
In reality the specs are never 100% done correctly. The "new guy" misses some edge cases everybody but him knew because its just company knowledge. A lot of info in the specs was missing since they are not complete and so on.
This over the weekend never works in the long run. The ORM worked for all the happy path and written down cases but then you have cases were the ORM just is not good enough or fast. So you start to add strange code to work around the ORM. The same for the web framework or the validation lib.
To me the author of this comment sounds like the typical "Freelancer" coming in into a company knowing everything better then all the people and then leaving after a few months and now everybody else has to deal with his code.
It swings both ways though. I've seen plenty of older engineers dismiss the "new guys" effort and claim that everything had to be custom written, because there's no way a common framework like Django could cover their use case. The same type of engineer has never once worked with a common framework though, so they don't know what's included nowadays.
Turns out it's a lot easier to build on top of a common framework than do everything from scratch.
Sure I had an older dev do bit masking for a list of 3 options in javascript because he was used to old terminals.
Its something different coming in and changing things here and there but rewriting the hole thing on a weekend is something different.
I was very impressed with vBulletin’s use of bitmasking for permissions (of which there were many possible combinations) when I first encountered it.
Would love an excuse to use it, but one has not come up in like 15 years since, hah.
I think it's safe to say that ORM in Django is, in fact, better in all possible ways than an ORM someone at some company just wrote. Including speed and handling edge cases.
We only know what OP wrote and he doesn't sell himself as a genius but as someone who was competing with really, really bad ideas.
> Sometimes the new guy can make a better version themselves over the weekend, not because they’re a supergenius, but because they’re not hampered by 47 teams all trying to get their stamp on the project.
In 99.9% of cases what seems to be "the better" version is better only for the "new guy" or rather his ego.
Those 47 teams hampering doesn't necessarily mean a bad thing, and more often than not actually well justified "stamps".
You only understand those things when you turn from the "supergenius" into an owner who have to take care not only of numbers on screen, but also security, interfacing, management and so on.
Or you don't turn into.
That is often the case, but far from all the time. Other times something is made so needlessly complicated by office politics that it may never get shipped.
Not saying it never happened in history, but most of those "complications" are justified. Being narrowsighted and overfocused does not help to assess it.
Conversely, sometimes when you have 23 people designing something, they can lose track of what they’re trying to accomplish and focus on how they’re trying to accomplish it. It can be an XY problem sort of thing. “How can we get the Redis queue to do an exactly-once insertion into Kafka, if we can’t guarantee exact ordering from the Paxos framework?” “Uh, guys, aren’t we trying to send out the weekly email newsletter to our estimated 500 subscribers?” “Oh, well, I guess we could just use Mailchimp…”
Like I said earlier, it’s ok not to believe me. I don’t particularly mind. But just between us, my solution met every one of the project requirements using COTS parts because they’d made it waaayyyy harder than it needed to me.
Nothing personal, but our conversation reminds me many similar convos I had with developers who thought their product was superiour - but they could see it only from their angle. And it was superiour - but again, only under narrow view.
Good chat. Have a nice day!
Not saying you're wrong in all cases, but there are enough examples of hugely expensive megaprojects which totslly tanked, which would have definitely been much more successful with OPs approach if executed correctly. Not saying they would be done and done within a weekend, that's silly. But the alternative, poorly defined integration interfaces, multiple contractors, multiple stakeholders with conflicting requirements and zero (real) regard for the user is unfortunately fairly common, both in public (city/regional/government) and private bureaucracies.
The examples are legion, and they always seem to have NIH and baroque requirements, and be rather over- than underspecified. I would go so far as to say that these projects are almost never successful (and definitely never on time and budget).
Take this idea and bring your own validation library and forms and UI components to the next job, and you've described what I do. And then you have real lock-in.
Ah, so you’re the one who made that same company’s marketing website!
Hahaha. I'm not above that kind of work. Sometimes having a consistent codebase for both things comes in pretty handy if you need to tie em together or just need to spruce up the CSS every few years.
I don't intentionally make my work hard for anyone else to maintain. I comment and write tests pretty thoroughly in case someone else comes along. Or in case I get woken up at 6am with a bad hangover.
Nah, I gotcha. That makes a lot of sense.
Yeah, that definitely happens.
But I don't think Claude Code is going to prevent an org that thinks they can prompt their way to a replacement for all their SaaS from having internal political bickering that makes them end up with a extra-shitty mega-compromise to try to make all the internal stakeholders happy.
If you've got no vision and no taste, you need to find a vendor who will protect you from screwing up your internal processes and tools.
Internal tools teams have rarely cared much about UX or the day-to-day experience of their poor users. The quick-and-dirty internal-prompt-based one is likely to similarly be unimaginative and unintuitive.
Isn't this agreeing with the parent? If Django were the B2B SaaS product, you didn't vibe-code Django, you just used Django. You aren't responsible for maintaining Django itself.
Django wasn’t the product here, though. I used it as part of the toolkit to “slap something together in one weekend”, and that something was the (actual real life) B2B SaaS product, or at least the user facing interface to it.
> feel free to doubt.
I don't doubt you at all.
I once worked on a project that was a new sign-up process for a large retailer (~90k employees at the time, four figures worth of outlets, quite a few billions in turnover).
There were about 60 people across, I can't even remember, maybe 10 teams that I knew about. One of the managers there assured me that the true participant figure was closer to 160. I was agog.
This project took months, and it had been going for months before I joined. And, as you can imagine, with that many people involved over that sort of timescale, there was turnover: people, sometimes key people, would leave and be replaced - sometimes by others who'd already worked on the project, but sometimes by new people - with the expected disruption that causes.
It was two web pages, plus some back end plumbing across multiple systems.
But, in the grand scheme of things, nothing that complex. I reckon it was a handful of thousands lines of code total across the full stack. I was mostly on the database side and, IIRC, I wrote a few hundred lines of SQL in a couple of stored procedures (wouldn't have been my preferred solution building from scracth but, you know, we weren't, and we had to integrate with a legacy systems that had to keep working as expected).
Overall it took 8 or 9 months from kick off to shipping and I was involved for perhaps 3 months of that towards the end. I was on the call with dozens of other people whilst me and one of the other guys hooked the final pieces together and tested it end to end for the first time... and it worked. There was actual cheering.
Large enterprises are genuinely ridiculous.
Rule #1 of power: never outshine the master
I had a similar experience where someone that had prior experience with django while we were using sqlalchemy started to design a django-like ORM on top of sqlalchemy. Of course it took him some time to get working, was a hell to understand and extend and most importantly lacked support for basic features.
Fortunately it was limited to a small isolated service but I can imagine the damage on the long term if you continue that route on what becomes a huge monolith after a few years.
It feels like I have worked with you (though obviously not). Had same experiences to the T.
Maybe it's just something that happens to many in web development world, not-invented-here and all...
I was complaining about SQLAlchemy's insane quirks to a group from my alma mater and one of the grad students said, "Well, the solution to your problem is clear: Write your own ORM." and I had to explain that this startup does not want to get into the ORM-writing business.
I freaking love SQLAlchemy. Those quirks once let me build a sane API on top of a legacy database (ported from Visual FoxPro hourly using a program I also wrote for the task). Some of the fields were values in an XML doc shoved into a DB column because the original programmer thought that was a good idea at the time. I wrote indexes and virtual columns that let other devs query those fields just like everything else.
It has its edge cases, but Alchemy is the greatest thing in the world when you need its exact features.
But yes, I’ve used that line plenty of times: “we’re not in the X-writing business”. I mean, sometimes you can’t help it, but those should be exceedingly rare cases.
Also, some people want to work on what's already familiar to them. If building a framework from scratch is what appeals to them, they'll do that even if a framework already exists. Busywork to look productive.
I resonate strongly with this story. I’ve seen three people teams get in one month where SAP could not in year, and also let and witnessed incredible number of total fakers in SaaS enterprises.
Big corpo may be too big to fail, not so sure about their whole cohort of partners and fakers.
We are certainly closer now to being able to prototype and go to market faster with a product. In one weekend is a little much but I think its hard to deny that building will continue to expedite. What most developers don't think about is that the marketing, sales, customer service are all non-trivial parts of the business/product and all require legwork that is more than just sitting at an IDE. The nail in the coffin is that the data is a large part of company moats, and new products need time in the market to get that. Migration is also a long process and risky...so to get customers, a newcomer needs to provide way more value than what the incumbent gives.
I imagine you're going to have people trying to automate the whole GTM lifecycle, but eventually the developer that thinks they can bootstrap a one man enterprise without actually doing any kind of social interaction will run into a wall.
> We are certainly closer now to being able to prototype and go to market faster with a product
Absolutely. But this begs the question that businesses want to also sign up to maintain whatever product they've built, on top of their core business.
"Service" is the word that people seem to be forgetting in SaaS. If you roll you own, all you have is software.
The "service" part can still come from internal sources. Plenty of companies have internal support for internal tooling. With a good foundation of infrastructure and a lean team that knows how to build, not just vibe code, there is most definitely some ROI there.
But yes, this brings us back to the point that simply building the tool is only a small part of the process...and it has often been one of the most expensive parts of the process.
In any usable product making a product is like 20% or less. Enter compliance, security, payments and a million other things.
Even if you can build it in a day B2B SaaS will continue to prosper because they sell peace of mind, reliability and compliance. Not features.
Also due to economy of scale it will always be cheaper to buy something from a vendor that sells it to many clients than to DIY it.
Yep. It's a funny thing.
You build a Twitter. Profiles have posts, posts can have images, etc. It's very easy to model the database.
But then how do you make money with it? Now you need to build a separate system for advertising? Or do you want to sell subscriptions? Which means you need to build a separate system to handle payments. This is usually the big one, because when you handle money, what happens if there is a bug and you charge someone without delivering anything? How do you prevent fraud? How do you handle disputes?
Someone posted something illegal. What do you do in this situation? Do you call the police? The FBI? What kind of data do you give the authorities? How much data SHOULD you have been logging in the first place in case something like this happens?
One user doesn't like you so he bought a botnet to DDoS your website. How do you handle this? Are they mass posting? Mass creating accounts? Is it possible for them to exhaust all the usernames possible and then nobody can create an account anymore?
Your website is online but if the server blows up you'll lose all the data in the database. You need backups. You need a system to ensure the backups are actually working. But then some guy from the UK said he wants his posts all deleted. What are you going to do now, because his posts are also in the backups, and you don't want to touch those.
Trolls are posting things against the ToS. Who handles these things? Shadowban? So there needs to be a shadowban system? Moderators? So there needs to be a moderator-only section of the website? Should this be integrated with the main website or not?
Then you look at this horrendous mess of 6 paragraphs and you think back about the first paragraph that already did everything you wanted from Twitter. All these other systems, most of the work, and all you actually wanted was the first paragraph.
All those things are true. It still doesn’t sound like 1000+ engineers at 350k/yr.
What actually happens in a startup is you encounter these problems one at a time as they arise.
Twitter wasn't built by 1000 engineers at 350k/yr.
It had to hire them later on. Because when there are users - you need support, take out fires etc.
And this exact thing will happen with any homebrewed SaaS.
You either run a business or play tech company making your own saas instead of focusing on your business.
Sure you can do both in very rare cases - if you are SpaceX or similar, otherwise you are shooting yourself in the foot.
No. They hired 1000 people to help them justify funding rounds.
Even then, startups prioritize growth over efficiency. So maybe 100 people would have been fine but 1000 gets them a 5% growth improvement in growth.
Startups have no users and no data to start with, and if they fuck up security, well, they just fail sooner than expected.
Once you get past a certain size, you have very different sorts of problems. Any idiot can vibe code a facebook lookalike, but the real one has to handle hundreds of millions of users and posts while being a target for state actors.
TLDR; yes you do need that many
> yes you do need that many
You absolutely do not. what do you think about the website we are using right now! It has half of the problems listed above.
> facebook
Your work project doesn’t have a billion users.
We were talking about what it would take to fix the technical problems resulting from taking a working program to something people use.
> Any idiot can vibe code
I didn’t say that either.
How is it the HN opinion that it’s impossible to make a web application a lot of people use?
It's still possible. Have the product and hire other people for these things.
Use stripe, cloudflare, whatever the legal equivalent of these stuff, S3.
Yes they might take most potential profit, but you'll also not have a huge payroll.
These are two different problems.
AI has solved the 'coding' part. The business is still very human because they are the ones buying, for now.
Yep. Wait until they realize one of their vibe coded apps validates everything client side and their entire DB is open to the world.
Like that never happened with non-vibecoded stuff.
Of course it has, but it's more likely to happen when nobody is paying attention.
There's a difference between someone breaking into your house to steal your valuables, and you getting robbed after leaving your valuables on your lawn with a sign saying "Look At My Valuables"
Startups of the last decade were routinely doing this. Building their fresh ideas on the newfangled databse without bothering to investigste how to secure it in any way against malicious actors.
> We are certainly closer now to being able to prototype and go to market faster with a product.
What are the higher-order effects when anyone can do this, and *aaS becomes a market for Lemons?
I think that just because anyone can do it, doesn't mean they will. Lots of people have really great ideas but very few actually commit to execution. Ultimately ROI will go down, deincentivizing the commercialization of that thing someone wanted to bang out in a weekend.
In the very long term, software will become a commodity, as you mentioned. Process and workflow may move into JIT delivery for the need at hand, in theory the data layer will be comprehensive and clean and the days of clicking around a bunch of stuff to fulfill process needs will move into a lower latency activity like...talking to your agent.
I saw a quote today by Brian Eno(1995) that said: "So the question becomes not whether you can do it or not, because any drudge can do it if they're prepared to sit in front of the computer for a few days; the question then is: of all the things you can now do, which do you choose to do?" and it resonated with me a lot.
> Lots of people have really great ideas but very few actually commit to execution.
This is true when you had to work hard for those ideas. Now you have LLMs. It means more people can sling a lot more crap at walls with fewer barriers to entry.
Good execution doesn't get easier with an LLM.
No, and I agree with the conservative sentiments here. However, putting together a SaaS alternative that frees up money during a crunch, and now with the pet features your boss has always wanted, is potent indeed.
You've hit the nail on the head. Immediate gratification.
AI is like sugar. It tastes nice, gives you energy quickly - what's not to like? The gratification is immediate, and if "today is all that matters" it's brilliant.
The problem with sugar (and AI) is medium term. So sure, that junior dev whipped up the whole framework in ClaudeCode, and it's humming nicely. Junior dev gets credit, and after a couple years moves on somewhere else.
Then something changes. Windows. TLS. Code Signing, whatever. We need to update the program to the change. Just a small tweak. Junior Dev has gone (or is otherwise occupied) so we'll get new-Junior-dev to do it. Is he expected to do the change at the code level? Or at the prompt level? Will ClaudeCode in 2029 be able to maintain ClaudeCode Code from 2026? Or will it want to rewrite everything? Will new-junior-dev have the skillset to prompt as well as first-junior-dev? Was the code good enough that a dev could just "take it over"? Or was it "it works, let's use it" standard?
AI makes everyone look good in the short term. But it worries me for what happens in 5 years, 10 years, and so on. Sugar is great, but you can't live (long term) on sugar. Sometimes you need a proper meal plan.
That is why I said "throw crap".
I think my point is that not everyone is suddenly going to go and start making stuff. There will definitely be an increase, which is a net positive because we can start exploring unknown areas of interest more rapidly, we can fail faster, etc. Fewer barriers to entry will increase competition, lower prices, increase efficiency, and theoretically benefit the consumer.
here's reality before claude:
- nearly every enterprise IT project is a failure anyway
- "can i do this for free?" savvy people write "thing i don't want to pay for github".
- ??? "stupid smelly nerds!" (https://www.reddit.com/r/github/comments/1at9br4)
okay, what was the actual obstacle? it's really simple: in order to use something FREE, you had to touch GITHUB, which meant GIT. and people hate git.
today, with LLMs:
- "can i do this for free?"
- LLM dutifully does the needful, using projects it finds and code it learned from github, and doing the prosaic tasks of launching them for you, whatever that means.
people are getting way up into their heads about what matters, psychosocial and management and whatever bs. chatgpt is FREE. it will fix your problems for FREE. people will put up with ANYTHING for FREE.
the real innovation is laundering all that inaccessible, pre-existing solution space into a format that doesn't require transiting git and giving it away for free.
don't believe me? all of the most profitable SaaS businesses in technology are the packaging, deployment and customization of pre-existing open source free software, whether it is linux, kvm, postgres, etc. they are factories to turn stuff that is inaccessible because it is in GIT, which SUCKS - that is the hard part for people to wrap their minds around, that GIT sucks - into websites you can pay for. now LLMs do that.
Exactly. Once the market tastes like lemonade, everyone will be afraid of trying new apps in the way that they are afraid to accept phone calls from unknown numbers now.
You will trade initial development budget for advertising budget, trying to position your product in proximity with people who are known quantities.
Tbh I think you’re fundamentally misunderstanding the issue (or I am).
It’s not about some single dude disrupting the saas market. It’s about largish companies who already have internal dev teams, slowly weening their company off these ginormous one size fits all saas products and building local, tailored solutions.
It’s death by a thousand cuts from the erosion of their highest paying customers.
I feel the market forces kinda point the other way, though, since the customization of the SaaS is also cheapening, but faster and more targeted than these internal teams. Over time I believe that’ll lead to more, not less, SaaS consolidation.
Let’s put the cost of code production at 0: regulatory compliance with payment processing laws or industry oversight is a recurring job that’s common for the whole industry when it changes. SaaS companies have hundreds of customers to attend, these become first class business functions. New demands won’t be in training data for LLMs, so someone needs to be doing this. SaaS has the funds and customer base to have dedicated experts at these functions, but it’s dead capital and nigh-impossible hiring in a tiny talent pool for the rest of the market… the delta to get Salesforce or SharePoint not to be total ass and fully customized is orders of magnitude smaller than detailing those foundations, and as people who sharecrop on platforms like those know, the devil is always in the details. Those internal teams just aren’t positioned to juggle both sides of that coin, they can’t be experts, mistakes can be existential, and the liability picture is so very ugly… coding is the least of it.
Into this, MBAs are not static. It’s not gonna take more than a few “vibe coding ate our CRM data” high profile snafus, or industry think pieces to map out why customization is faster/better/smarter, to get clear business dogma around this. A witty turn of phrase about focusing on your actual business.
I think ‘no one ever got fired for hiring IBM’ x 5 is on the horizon, and the evil marketers at Salesforce, MS, and the rest are gonna work hard to grow their piece of the pie. They have LLMs too, only with better models and unlimited tokens. And our executives will be checking directly with their LLMs about how to invest (the consultants, journalists, fanboys, and social media bots too…).
My current boss is an ex CTO of IBM, and tbh he's proof that more people should have been fired for buying an IBM.
Unrelated to the convo you make some very valid points. I just absolutely detest that saying xD
in the 90-ies anyone could easily prototype with tools like Access (and all the other "4GL" tools which were similarly all the rage back then). That still didn't preclude companies from buying their major software from software vendors instead of doing it themselves.
In some sense having customer able to prototype what they want is a good thing. I did it myself as i was at the time on that side, and having a quick-whip-it tool was a good thing to quickly get some feature that was missing in the major software before that major software would add it (if at all). (And if one remembers for example Crystal Reports - while for "reports", it and the likes were in many senses such quick-whip-it tools for a lot of such customization that was doable by the customer.)
So, after initial aftershock - "Ahhhh, we don't need software companies anymore!" - we'll get to the state with software companies still doing their thing just with a lot of AI as specialization is one of the main thing in modern economy and AI becomes most powerful tools of the trade. (and various AI components themselves will be part of software delivery, like say a very fine-tuned model (hosted or on-premise) specific to the customer and software - Clippy on steroids)
(Of course some companies wouldn't survive the transition just like some companies didn't survive the transitions to client/server, cloud, etc. while some new companies will emerge like Anthropic has today or Borland had at the time)
Access is not as dead as you might hope. The long tail of internal tools written with Access continues to shamble along. I had to figure out how to dump MDB files on Windows last year for just this reason. As an industry I think we often fail to grasp how much outsider art there is, in the form of internal departmental tools.
LLM coding is going to create a cambrian explosion of these tools. It’s going to be very interesting to see the remnants of this wave 30 years down the line.
One of the key questions here - will LLM coding decrease the proliferation of app-specific Excel files (by for example accelerating and simplifying Excel-to-webapp conversion) or would result in an opposite outcome by making feasible managing even orders of magnitude more of those disparate Excel files :)
I wouldn’t bet against cramming more and more business processes into Excel. The guy who was copying cells from one workbook to another yesterday, tomorrow can have a single mega-workbook with all the macros more or less deconflicted.
The history of software has been that once it becomes cheap enough for teams to flood the market with “existing product” + x feature for y users. The market consolidates around a leader who does all features for all customers.
I’d bet that we skip SaaS entirely and go to Anthropic directly. This means the ai has to understand that there are different users with conflicting requirements and that we all need the same exact copy of the burn rate report.
It's not a market for lemons. We can share info about the lemons and all choose to use the good ones. There's no information asymmetry.
> We can share info about the lemons
That might turn out to be less than reliable over time, as bots are already screwing up systems with fake information and it's probably going to get worse.
I don't disagree with that, but the market for lemons still doesn't really fit.
If I remember my econ class correctly it uses used cars as an example. If you're neighbor bought a used Toyota and tells you about it being a great purchase, you can't go out and buy another used Toyota and expect it to also be in great condition. Every car is a gamble.
But if you use something like Hubspot and tell your neighbor it's really good/bad you can expect to receive the same Hubspot service they did.
If you can gin these things up in a weekend then why would you bother with a monthly subscription model for software? The only valuable part is the specification and possibly the hardware to run it. If I were a CTO trying to save money I might pay for the labor to develop good specs, but I would prioritize getting out from under software companies with a rent seeking models and 80 to 90% margins
> If I were a CTO trying to save money
A CTOs job isn't to save money but to spend money effectively. Saving money by increasing risk is not neccesarily a prudent move.
Even if AI were erased today, most SaaS companies wouldn’t exist in 5-10 years. Doing business with a small tech company that could run out of borrowed money or sell to someone who will destroy the product or just arbitrarily change the terms of service tomorrow is a liability. That’s assuming the hypothetical tech spend isn’t just eroding margin anyway.
True, but that's one of the reason established SaaS can charge an arm and a leg. Not every SaaS is a start up.
On prudent choices: one thing I'm surprised about is that LLMs are showing me libraries and tools that I'd not found via search.
A boring one from today was about select, datalist or some custome element (which LLM can prototype) or some JS libs. Good breakdown; links to playgrounds, rough mocks so team could kick tires. It raises points the team had and had counterpoint to help drive decisions.
it depends a lot on the application, I think, though certainly you can point to cloud services like Cloudflare or whatever Burger King was using to track how many times a clerk said "You Rule" (while capturing all customer audio data, which was then stolen by low-effort attackers) as high-risk; just because you don't feel the safety risks of outsourcing data to a black box on the cloud doesn't mean they don't exist, it just means you get to neglect them. when I headed IT at an SMB, I was given a lot of leeway, and our department had its own budget, so cutting out SaaS was a high priority so we could do more. if I were heading today with LLMs' present competency, I would have replaced much more, up to and including Salesforce which was draining the heck out of our budget despite us not doing anything technically interesting with it.
$40/head/year (including employees no longer with company) for a call metrics suite is low-stakes and relatively easy to replace what we want out of it, and this is an example of something we did replace with a $0 solution with my own abysmal-at-the-time coding skills. ~nobody's about to replace Microsoft suite, though (a couple replacements before me, they earnestly tried; there were still some laptops with OpenOffice on it; I admire them, but I'm not dealing with our sales team trying to figure out what an ODF is).
I love this "petty kingdom" budget model, by the way, as someone whose work personality could be described as "cheap analyst." I'm paying $40/month per head for Software X in your department, and I have an inferior replacement for $0/month/head which meets specs and which you can't quantify productivity loss for (essentially, it just looks ugly and feels bad). I can therefor cut that out of my budget entirely while meeting my obligations, and if *you* really want the decadent solution, *your* department can bear that cost. Either way, I get plenty more money to basically not have to be a dick (like charging careless employees for broken/stolen equipment, or getting an above-expectations solution for ADA employees); and sometimes, maybe some antennas show up on the roof which would be difficult to justify cost for if asked, but I'm way under-budget so nobody would.
It means the same: random lottery of mass, with everuone else failing.
American capitalism hides the depressing fact that rarely does the best succees.
AAI momentum is parallel to just buying lottery tickets and doing so with the belief that you know the real odds, so one can overwhelm with quantity of tickets.
I sure hope I never have to hunt down any GTM options myself soon and I can tell the AI to do what it should be doing. However AI adoption may be getting slowed down by profit motives because what Google should have already been doing is letting me git clone the entirety of GTM with all its configs to a local folder so I can treat it like code because it is code. The difficulty with AI adoption will be to make all products be like this so they can interact on a code level instead of me having to press buttons in different UIs to make thing shappen. E.g cloudflare should be letting me git clone its entire config, everything I did in the dashboard, to my folder too.
> bootstrap a one man enterprise without actually doing any kind of social interaction will run into a wall.
But you are not limited to only using LLM for coding.
I agree that marketing and sales is as important as product and technology, but they are not necessarily safe.
> We are certainly closer now to being able to prototype and go to market faster with a product.
Prototype maybe. Go to market maybe not so. It's giving false hope. You're just taking more shortcuts with prototyping.
This vibe-coding-will-replace-SaaS insanity is the new crypto-will-replace-fiat-money insanity.
It's shocking to me how prevalent this "who needs Salesforce when everyone can just vibe code their own CRM from scratch in a day" narrative has become in the business press. Like, what???
That's not like "Who need Photoshop everyone can just vibe code their own photoshop"
They could just download GIMP or find cheaper alternative, that was always an option
I've had a pleasure of using GIMP recently on Mac. One of the worst UX/UI experiences I've had in quite a while. If that's where vibe coding leads to, then Photoshop is very safe from disruption.
I remember complaining about the UX/UI of GIMP in the late 1990s. Luckily 2026 is the year of the Linux Desktop.
No, the equivalent question that people are seriously asking is "Who needs Photoshop [or graphic designers] when everyone can just vibe paint their graphics with AI?"
Same with „building custom businesses stuff” you can already do it quicker with existing CRM configuration without burning tokens.
Yeah I know a friend (small business owner) vibe coding a feature as a addon for Odoo. He has dreams of selling it (he usually has wild plans), but for now it's just a feature they want and does seem to be good enough for their use.
And the Google AI subscription is cheaper than any of the SaaS offerings.
I vibe coded Stripe and Okta in a weekend. Time to deploy to prod and save some money!
That's what happens when business press is all written by LLMs. Maybe the models think too highly of themselves...
It gets eyeballs.
I don't think vibe-coding will replace anything. However, what if AI tools can make skilled developers more productive, particularly at simple tasks in unfamiliar environments? You could see that reducing the engineering costs of simple utility applications. There are tons of pitfalls that many here have pointed to but also maybe opportunities to do things that wouldn't have been cost effective.
Also: In my life the easier it has gotten to create and run software, the more software people have wanted and the more they have been willing to spend on it.
> I don't think vibe-coding will replace anything. However, what if AI tools can make skilled developers more productive, particularly at simple tasks in unfamiliar environments?
That's not good enough.
Now that the world has successfully laughed off the "our models are so good they're superintelligent" AGI claims, AI companies and investors have moved on to the "our models are so good they're going to do all your workers' jobs" angle.
The insane investment is for AGI/total job replacement, not developer productivity tools. We are going to be sold pie-in-the-sky claims for a long time until the world wisens up to this rhetoric the same way we did with AGI nonsense.
People really seem to believe that code is the only thing you need to make a SaaS company. It's like thinking a line cook is all you need to open a restaurant. There are so, so many other components to running a business.
I agree!
Although the proponents of this idea argue that companies will create and (!) maintain many tools in-house.
It’s not so much about running a business, since you don’t sell anything and only have internal customers.
SaaS is mostly sales.
100%, particularly B2B SaaS
There is also an aspect of thinking no one will go to restaurants when anyone can make the same food at home.
I don't think it will replace SaaS but I do think it can replace the need for a lot of the consultant work that goes around configuring and integrating the SaaS. It will be much easier to have a spec that defines how things need to be configured and the machines can implement it (using the SaaS as tools). Frankly this is the most annoying part. It's not that the B2B stuff can't do whatever, it's that it never gets implemented in ways that aren't a pain in the ass because it's all handled by people who aren't actually using them.
I really don't think it's not going to become "these prompts are specs" and then you have processes of reviewing implementations. It's one thing when you have randos building stuff and they leave etc. Having stored prompts and managed code that uses tools is a different beast.
In my experience this isn’t the case. SaaS systems, at the least the ones that are embracing this sea change seem to recognize that connectivity is key. They are opening APIs and partnering like we’ve never seen. They lack the domain expertise and resources to plumb the last mile. Companies can finally customize and integrate there core SORs at a reasonable price point and if you hire the right people decent technology. It’s a golden era, I do wonder if you’re correct medium/long term but the lack of skill sets to build, deploy, and maintain these solutions is very real. Many can vibe code a great looking app, very few can support it day two even for just a few hundred users.
No serious programmer "vibe" codes. I admit creating SaaS may not be feasible with current infrastructure but you can't ignore the insane jump in productivity that these tools can offer with the right scaffolding.
This website is 70-80% vibe coding frauds pretending to be experts.
There is still a narrative here. Lots of SaaS recurring revenue is built on value-add features that can be easily replaced.
What I struggle with is developers wanting to leave platforms like Datadog for open source equivalents that need to be self-hosted.
I hear all of the cost savings benefit, but I never see the team factoring in their own time (and others time) needed to set up and maintain these systems reliably long term.
Something IC’s at company often struggle to understand is the reason why companies often prefer to buy managed solutions even when “free” alternatives exist (read: the free alternatives are also expensive, just a different type of cost)
My log bill for Google cloud log would be like 30k. For splunk I like 80k. I self host for 1.5k per month. Spend maybe an hour a month? Easiest money I ever made.
When you’re in the middle of a production down event and your whole team is diagnosing the issue, and your log server is unresponsive, who do you contact for support?
No one, you pull an engineer off the production issue to debug the log server, because you need the log server to debug the production servers.
See the problem?
Edit: to be clear I’m no fan of Datadog and I wish self hosting were an option. I want this path for our company, but at least on our team we just don’t have enough (redundant) expertise to deploy and manage these systems. We’d have to hire an extra FTE.
If you’re having a correlated outage like that, then it’s likely you fix the prod issue before the cloud engineers at some giant cloud company even respond to an internal escalation much less fixes an issue. More than likely your prod issue is causing the logging problem.
If you mean you are experiencing two totally unrelated issues at the same time, then I don’t think that’s a reasonable thing to really assign much value to as it’s incredibly unlikely.
Half of $30k/mo trivially pays for an engineer you hire to only manage such a cluster for you and just works an hour a week unless a pager goes off if you truly need that level of peace of mind. If you’re hiring for such a position I have a few rock star level folks who would love such a job.
The hypothetical problems people imagine for on-prem infrastructure get really strange to me. I could come up with the same sort of scenarios for cloud based SaaS infrastructure just as easily.
> I don’t think that’s a reasonable thing to really assign much value to as it’s incredibly unlikely.
In my experience the systems/tools needed to debug production issues are often only used when they’re needed.
Which now means you need health and uptime monitoring on your log server since without that, it might break randomly and no one notices until you need it.
> The hypothetical problems people imagine for on-prem infrastructure get really strange to me
It really comes down to the people and whether you have the expertise on the team. And whether the team can realistically manage the system long term. It’s typically safer to spend more money for the managed service.
(It’s a safer decision, not necessarily better)
> It really comes down to the people and whether you have the expertise on the team
Aren't these people suppose to debug and fix complex problems in prod? And if they can do that, why can't they run and debug a log server?
Of course there are trade offs with any outsourcing decision. But I think we should have higher expectations of engineers
I don’t think it’s necessarily safer or better for anything but your job security.
100% agree. If I am using a cloud log provider I wouldn't expect them to solve my logging issue(s) as fast as I need, more importantly I have no real way to put more resources on that fix.
More importantly, with a third party service I'd be very surprised if both went down at the same time and it wasn't a further upstream issue like AWS. If its my own logging service and it went down during a prod outage, I likely didn't properly isolate my logging service in the first place.
> Half of $30k/mo trivially pays for an engineer you hire to only manage such a cluster for you and just works an hour a week unless a pager goes off if you truly need that level of peace of mind. If you’re hiring for such a position I have a few rock star level folks who would love such a job.
1 person? Is that person always on call?
Yep, absolutely. I’ve come up with the term “man on the mountain” for such positions.
It’s when one person is exceedingly talented at exactly one thing - but isn’t exactly a typical employee who is good or interested in doing much else other than keeping that one thing online and reliable.
Their job is to go live on their mountain for weeks or months at a time without so much as doing anything other than keeping their phone on and answering it within the first couple rings regardless of when called. If they are good at their job you likely don’t even need to call - they already know it’s broken before you do.
I’ve employed a few such folks over my career. They tend to be the “alternative” style candidate - exceptional people with exceptional flaws. They love the simple tradeoff.
That said of course this is ignoring bus factor and overly simplifying things. Typically this is one deep subject level matter expert who sits off on the side of a small team, so there is at least one “understudy” hanging around as well.
I still advocate for such positions when they make sense though. I would much rather in-house my own “insurance” vs overpay some giant company for each month only to find out the insurance didn’t exist when I needed to make a claim. It’s certainly more risk to my career - but I have very strong feelings that as a manager or executive my job is NOT to cover my own ass because it’s easier.
The old argument for being locked in to legacy software costing 6-8 figures a year was that you had no choice. Now you have a choice! Clearly that is better, and everyone should evaluate that choice on its merits, and the stock market sees that people are voting with their dollars. If your whole sales pitch is "good luck when it breaks!" you might want to reevaluate your business model.
The stock market is trying to predict that people will vote with their dollars in the future. I’m not quite sure people are really replacing enterprise Saas at large corporations yet. It’s more of a projection.
Fair, however at some point of a companies size/spending the complexity of integrating with a SaaS becomes as large as the one to run your own open source tool.
Beyond that, and Im aware this is very much application/company dependent, theres plenty of SaaS companies that offer horrendous or no support no matter what you pay. We used to use splunk for monitoring and logging. Paid a ton of money because we were handling financial data and needed tracibility and reliability. We constantly had to put out fires that were caused by their unreliable platform. It was not a good experience.
Ultimately, we jumped ship to Prometheus. We pay a fraction of the price and spent less time on it.
Have you ever tried to contact their support?
The problem is all these SaaS companies have cut costs so much that all their support has been reduced to useless offshore at best and at worst a chatbot. They do go down and don't work and often times there's simply nothing you can do. The worst offenders will seize upon the moment and force you to upgrade a support plan before they will even talk to you, even if the issue is their own making.
Unless you're a huge customer and already paying them tons of money, expect to receive no support. Your only line of defense if something happens and you're not a whale is that some whale is upset and they actually have their people working on the problem. If you're a small company, startup, or even mid-size, good luck on getting them to care. You'll probably be sent a survey when you don't renew and may eventually be a quotient in their risk calculus at some point in the distant future, but only if you represent a meaningful mass of customers they lost.
> The problem is all these SaaS companies have cut costs so much that all their support has been reduced to useless offshore at best and at worst a chatbot.
Tremendous opportunity announcement!
If you are building a dev-focused SaaS, treat your support team exactly as they are: a key part of the product. Just like docs or developer experience, the support experience is critical.
Trouble is, it's hard to quantify the negative experience, though tracking word of mouth referrals or NPS scores can try.
You don’t, you just look at the log like us old timers and solve the problem. It’s literally no different than solving the problem on the cloud.
Boogeyman
Oh come on, nobody uses the cloud because of support! Let's be real now.
99% of the time a cloud migration is because of OpEx/CapEx accounting shenanigans.
This is the exception to the rule
Do they actually not understand that? They might just be fine with a system that makes them more useful.
How do you calculate the time spent on an internal tool like this, actually? (I’ve never been in management). Realistically your team inevitably will have some downtime, maybe some internal tool maintenance can be fit in there? I mean it obviously isn’t fully “free” but is also shouldn’t be “billed” at their full salary, right?
> How do you calculate the time spent on an internal tool like this, actually?
In broad strokes there's two ways. You can count it as an operational expense, or you can count it as capital (this takes more work to do but can have some advantages). If you count it as operations, it's just a big red pit you're throwing money into that you hope is offsetting a larger operational cost somewhere (but this can be hard to quantify). If you count it as capital, you're basically storing all of those hours as an "asset" which then loses value over time (it's kind of like the charge in a battery). The problem is you have to be able to show that this internal tool would, in the case of an acquisition or liquidation, be valued by the new owner at the value you're setting it at.
The problem there being that people are even more hesitant to trust somebody else's internal tool than they are to trust their own internal tool, so I've seen multiple managers think "I sunk a million dollars into this so it must be worth something" but in fact they were just running a jobs program for their team.
> Realistically your team inevitably will have some downtime
What? My team wouldn't have any downtime even if we had 10x the amount of people.
If you work at a company where you have times where you don't have work to do, you should polish your resume because it means the company will go under.
Doing work is easy, not doing work is hard. It's trivial for any engineer to find stuff to do. The trick is doing the right stuff. Most software is bad and clunky, most requirements are wrong, and most of your customers, at best, tolerate your product.
I think most software companies need to be doing less. Deleting code, refining, and making their product genuinely useful as opposed to "able to technically contort to client needs".
Agreed here as well. If you gave me 10 devs for 3 years and zero new incoming requirements the backlog wouldn't even go down by 20%.
Agreed, our backlog is insane.
Because most of them arent trained to think economically... how many people on the planet do you think are aware of the notion of opportunity cost?
If there's ever any use case to leave an expensive SaaS for self hosted, you can find it at datadog
>the free alternatives are also expensive, just a different type of cost
Not if you hire reasonably competent people. These days for vast majority of FOSS services all you need is an ability to spin up a VPS and run a number of simple Docker/Podman Compose commands, it can't be that hard.
Ok so they cost you reasonably competent people. Those are expensive!
Only if your company already is lacking in the domain of competence of your engineers. If that is the case, either you have bigger problems to worry about, or your product probably isn't impressive enough to begin with to warrant an addition of complex, enterprise-grade SaaS tooling.
Or they're busy working on the core product and not screwing around on something that can be bought easily.
I'm sorry but the amount of companies that need something like DataDog is quite small compared to their 30,000+ customer count. Maybe 5,000 companies on Earth truly need something like DataDog, 80% of their customers would be perfectly fine with a self hosted instance of grafana.
Using an open source self hosted solution should be the industry standard, encouraged position, by default. Our industry does not gain overall from using DataDog but only from truly open source solutions that utilized AGPL licenses that allows everyone to move forward together + share lessons together + contribute together toward a common goal of better observability.
Why are we acting like it's hard to set up? This isn't the 1990s, it's 2026. Tooling has gotten quite good over the last decade.
Also corporations stupidly spend money all the time, they over spend too. I recently left a company that was paying SalesForce $10mil a year in licenses when only 8 people in the entire 3,000 person company was using it. I doubt that was the only single instance across our industry too. There is a massive amount of waste and graft in enterprise sales.
I honestly doubt it if you replaced grafana for 10,000 DataDog customers they would notice the difference.
> Why are we acting like it's hard to set up?
Because the current generation of “full stack” engineers are great at spinning up react apps, but struggle with infrastructure and systems management. It’s really not any more complicated than that.
On a typical 8 person engineering team, maybe 1 or 2 people will know how to deploy anything to the cloud if you’re lucky.
The expertise just isn’t there at most companies.
Expertise isn't there because people are outsourcing that sort of work to companies. I didn't know how to do much of anything, until I had to do it for work. Then learning everything became way easier.
Surely all the engineers that existed 20 years ago haven’t simply retired? At the time if you told someone you couldn’t set up your own server they’d ask you what kind of engineer you are then?
> Surely all the engineers that existed 20 years ago haven’t simply retired?
20 years ago we had 5 times fewer engineers. And most of those have moved into management, other fields, retired, work calm jobs for the government or boring companies, etc.
How many 40+ year old engineers do you see, especially when compared to 20-30 year old engineers?
I guess we really are living through the leetcode generation! D:
My experience matches that of cj. In fact, if you do mention anything outside the walled garden, you'll get weird looks and someone will ask "Why?" like you are going down a dangerous path.
Come to think of it, they are right. Why take all this ownership when it's the company that is going to pay for all of this and you can push these responsibilities to some third-party overseas.
& the counter-argument is those SAAS apps being killed by A.I are growing revenue 20%+ YOY
people who write this BS - one never don't understand SAAS fundamentals, they only see what's on the screen and forget the complexity that lives on the backend - forget the costs of running such a SAAS
before it was low-code will kill SAAS, then Visual UI builders, now its A.I
just like it was before that crypto will kill Trad-Fi
people who say these things - have tied their identity into it so they whole-heartedly believe the bullshit they say even though reality doesn't match
to anyone curious read the 10k (Annual Report) of any public SAAS - Salesforce | Workday etc - people should admire these companies for the machines / ecosystem they built - and also learn the good & mistakes to avoid i.e the bad
those annual reports tell you how the revenue generation machine works, how much revenue is expected 2+ / 3+ years from now - their weaknesses | headwinds and also tailwinds - how those companies grow and continue to grow etc
Here are the most recent 10-Ks for Salesforce and Workday.
https://www.sec.gov/ix?doc=/Archives/edgar/data/0001108524/0...
https://www.sec.gov/ix?doc=/Archives/edgar/data/0001327811/0...
SaaS companies are effectively both "software maintainers" and "price gouging middlemen" at the same time. The difference between the bid and the ask for SaaS is part of a simple math problem for whether the company should try to create their own version of the software they need. It may be the right decision, it may be the wrong decision, but it will be the right decision for a non-trivial number of firms. And that means SaaS businesses will both lose customers and have downward pressure on their margins. That means valuations of B2B SaaS firms go down.
My career occupies a weird middle ground where, for 20 years or so, I've catered to smaller businesses that need bespoke solutions (because the SaaS available doesn't conform well to their business logic), but don't have the scale or desire to build and maintain software in-house. Sometimes these are slapped together in a weekend, if that's all that's needed. But in most cases they still become ongoing improvement and maintenance projects for me.
This niche position has had some interesting ramifications for them and for me. They clearly incur a lot of technical debt once their business relies on bespoke software. On the other hand, they own the software and can get an immediate response or new feature or upgrade from me, limited only by my time. And in the end, this ends up saving them time and money. It gives me a permanent and unending flow of work. But if I die, they're pretty screwed.
One reason I don't vibe code things even now, even simple components that could easily be vibe coded, is that I remember and know where everything is, every function or line of code that might be causing issues, because I wrote it myself. I know right away where to look for a query that might be throwing errors after a database upgrade, for instance.
As a manager I assume you would probably not want to go down the road of hiring someone like that, but for companies of a certain size it's an acceptable compromise. However, I wouldn't want to hire someone like that myself unless they were extremely reliable and didn't rely on AI to write any of their code.
People sometimes fail to appreciate the value of KNOWING the system inside and out when it comes to diagnosis and troubleshooting.
Observability is great, dont get me wrong, but past 3 to 6 months of work on the same thing...I can almost beet the observability tools in timetoresolve.
This sounds great if you get on well with your clients. You must be an effective networker and at sales. How do you bill, and how do you price your services?
I bill quarter-hourly at $300/hr for actual time writing or evaluating code. Phone conversations are free, and I take time to evaluate and explain what I'm doing before clocking in. The downside to this is that I make myself available 24/7 should any issues arise. I also don't necessarily charge for hunting down network issues or bugs (because I also host some software for clients). It works out to a good income for 80 hours a month or so.
I'm terrible at sales. My clients have only come to me by rererral from other clients. More than half the time, I'll tell prospective clients that there are already SaaS solutions that would be better for them than building something bespoke, and help them find solutions, because I don't want to do work that's already been done.
So you think this downturn will be short lived?
When management realise that the vibe coded projects are not maintainable, SAAS will be as popular as ever
It seems that current advantages would compound with AI. I.e., if I am making a SaaS for Popsicle stick makers today, why I am disadvantaged with AI vs a new competitor in the space? I guess the hypothesis is the Popsicle stick maker will vibe code all of the software that they need instead. For that, we need significantly better AI than we have today - perhaps something like a 1000X improvement. Basically, this is a world in which non-technical grandparents can vibe code anything that they want. This means, it understands what you want without you being able to articulate it well in the first place.
That's not a 1000X improvement in current AI. That's more like a 2x ~ 5x improvement in current AI, which is measured in months.
So, within months your prompt can simply be "increase NPV" and machines will do the rest? If not, what prompt will work perfectly in your estimation by the end of the year?
“Analyze these business requirements and create a software solution for the problems you identified”.
Right now it can get part way there but quickly falls flat.
In 12-24 months? It’ll be able to audit itself and determine how to fix issues as they come up, mid-stream. That’s (all of) what a human dev does.
How detailed are the business requirements however? "Increase NPV" is certainly a business requirement, albeit a very abstract one. "Add a checkbox to this form" is another, far more concrete business requirement.
Good AI asks clarification questions. Codex plan mode is already getting there-ish.
I suppose it is really only possible to know how close something is until it arrives. When I type in "Maximize NPV" into Codex / Claude Code, I feel like it is incredibly far away from full autonomous capability. I guess we will see.
What do you get when you type in “Maximize NPV” to a human?
"Maximize NPV" is exactly what shareholders prompt boards of directors with. Not all humans can do it, but some can. Perhaps your argument is that AGI isn't required to solve software. This would imply that human level intelligence isn't actually required today to build software.
I don't do tea leaves so I wouldn't commit to that, particularly because I think SAAS was oversold in general even before LLMs came out. But I think the idea that the industry as a whole will shrivel away just isn't feasible, even if there is a correction.
The B2B startup motto of "where someone is using Excel to do something other than accounting, there's a startup waiting to happen" has been shockingly resilient over the decades, and I suspect will continue to be.
We need a new one: "Where someone is using a vibe-coded internal tool made by the creative department that keeps needing bug fixes, there's a start up waiting to happen."
Paper forms used to be our main competitor.
Paper forms have some amazing features that software really can't compete with. And also some significant downsides that software fixes.
I dont even blame management. I believe most of them are well-aware that much of what is going on right now is pure hype.
However, they dont have a choice. The sentiment of shareholders is that they want their cash (yes it is their cash that managers re-invest on their behalf) to be invested in AI-related projects.
So...... you get what you get, and investors will get what they deserve. But they will still blame the management in the end ;)
In many cases, it's not a downturn, just a return to reasonable valuations. Other sectors should follow
All of the hype surrounding AI will subside when a SaaS company eventually deploys a moltbot version of their software and the company is driven out of existence due to the chaos that ensues.
So… next week then?
I wish I knew:). I kind of think Palantir is particularly at risk here. Image a company with siloed data behind APIs and access to other external data APIs. Using something like Claude I could tie all the separate sources into an easily digestible dashboard without any help from Palantir.
I've seen some bad some SaaS that management insists is an integration they need and no one else provides. I can easily see some vibe coded projects replace them.
They will magically realize this when their huge bonuses will be tied to something longer lasting than last quarter/year performance on some very narrow metric (which has nothing to do with sane stuff like adding long term value to some part of the company).
They are not stupid, far from it, most are (very) high functioning sociopaths. And out and up there its everybody for themselves first.
In my career I've deployed close to 100 different saas products at enterprise level and can tell you that most of the current crop are slapped-together half-finished dross with a huge sales and marketing team.
In the time it takes to deploy semi-bespoke saas, or while waiting for the current licence term to expire it would be very easy to develop a more suitable and much cheaper product in-house, this was true before AI tools and doubly so now.
A huuuuuge part of why companies, especially public companies, especially those in regulated industries like healthcare and finance are willing to pay eye-watering sums of money for a SaaS app that you could get an MVP up in a few weeks time from a competent team with no AI is that they need a phone number to call when something shits the bed at 2 AM on a Wednesday. They need support SLAs without the payroll and headache associated with it. They need someone to sue if things truly go tits up.
Moving SaaS apps in house is a great way for a VP to get a fat bonus or a director to get a promotion but I have to imagine it keeps the CIO/CTO up at night unless they're fully asleep at the switch.
Yep! We sometimes have a choice between the gold-standard and commonly updated open source solution to X and a two-bit hacked together proprietary solution that has 24/7 support at high cost...and we choose the one with support, because that's what our audits basically require. Because then we can say "yes, it's still within the support contract, we have an escalation point".
The problem is right now management is not only insisting on their team vibe-coding bespoke replacements, they’re avoiding paying for other SaaS because they can vibe-code their own replacements, often themselves, and they’ve lost sight of that they probably don’t want to be responsible for it.
Besides rampant failures in communication and skills allocation, wild U turns of requirements were (sometimes, not even real business requirements) were holding back corporate environments doing a decent job.
With AI, I can only see the rate of such changes sky rocketing due to expectations wildly misaligned with reality. Hence we are unlikely to see any meaningful improvements.
This is an incredibly broad statement that just isn’t true in a million cases. Last co we migrated all of our observability from Datadog to Grafana/AMP because it’s much much cheaper. The vendor can charge some premium over the cost to build/maintain but not infinity. SaaS is going to have to get dramatically cheaper to compete with the lower cost of building your own.
what if this time it's senior developers and they actually can slap something together better then the expensive SAAS offerings?
what if the expensive SAAS offering is just as vibe coded and poor quality as what a junior offers?
You're not considering opportunity costs and buyers vs. users.
If your senior developers can slap together something better than an expensive SAAS offering you want them directing that energy at your core products/services rather than supporting tools.
And the people deciding to buy the expensive SAAS tools are often not the people using them, and typically don't care too much about how crappy the tool may or may not be for doing the job it's advertising as doing.
And it's never just the slapping together. it's the ktlo: a perpetual tax on your eng team for every thing they own.
No matter what it's a tax on your engineering team to keep it together. But the most brittle parts are always right at the seams. It's not as hard to sew together components when you can cut the cloth down to fit together. Who knows how it'll shake out.
Clubbing all saas products together just means you can’t really have a productive discussion. Saas products are on a spectrum of quality, from amazing (stripe, datadog) to terrible (fivetran, github). Its upto you as a user to make a call as to which will serve you best, what you should focus your limited resources on etc.
> what if this time it's senior developers and they actually can slap something together better then the expensive SAAS offerings
A typical SaaS customer will use many pieces of software (we mostly call them SaaS now) across its various functions: HR, accounting, CRM, etc. Each one of those will have access to the same pool of senior devs and AI tools, but they will pour more resources into each area and theoretically deliver better software.
The bigger issue here is the economics of the C-suite have not changed here. Assume a 100 CPG company uses 10-20 SaaS apps. Salesforce might be $100k/year or whatever. 1Password is $10k. Asana $10k. etc. They add up, but on the other hand it is not productive to task a $150k employee with rebuilding a $10k tool. And even with AI, it would take a lot of effort to make something that will satisfy a team accustomed to any modern SaaS tool like Salesforce or Atlassian. (Engineers will not even move off Github, and it's literally built on free software.)
That's before I get to sensitive areas. Do you want to use a vibe-coded accounting system? Inventory system? Payroll? You can lose money, employees, and customer perception very rapidly due to some bugs. Who wants to be responsible for all their employee passwords are compromised because they wanted to save $800/mo?
Then, the gains from cutting SaaS are capped. You can only cut your SaaS spend to zero. On the other hand, if you have those engineers you can point them at niche problems in your business niche (which you know better than anyone) and create conditions for your business to grow faster. The returns from this are uncapped.
TL;DR; it's generally not a great idea to build in-house unless your requirements are essentially bespoke.
As my manager said to a young me when I offered to replace our CMS, and promised I could do a good job at it, "you could probably assemble our office furniture too, but I don't want to pay you to do that either"
The law of comparative advantage strikes again.
We have replaced many SaaS with inhouse solutions, but most of these where lacking in quality and where part of our existing core business model which we where not "owning" prior. We can flip the argument where we have lost customers and revenue due to SaaS not delivering
The gains is generally more seen outside of monetary as these SaaS solutions where holding us back for achieving our goals and improving our services to our customers. As in the end of the day our customers do not care if "insert SaaS" is having issues, it will always be our problem to own.
To the first question, if your senior devs can do that there's almost certainly something more directly valuable to your business they could be doing than solving a problem your vendor has already solved
The second question is a valid one, and I think it will somewhat raise the bar of what successful SAAS vendors will have to offer in coming years
depends how much the vendor chargers.
Nice what ifs, but not valid so far. I get the motivation to think/hope so, but thats not the proper business world right now where big money are. Maybe next year it could start becoming true but then market will be a bit different too
You're ignoring the biggest part of SaaS as far as management is concerned.
There's a large, stable entity that management can sue if something goes very wrong.
There are of course exceptions to every rule, and I'm sure some companies have been successful in building their own in-house tooling.
At the end of the day these decisions are all series of trade-offs, and the trick is understanding your requirements and capabilities well enough to make the right trade-offs.
It that works, nobody would be using Jira anymore, because people would just use a competitor that's cheaper or vibe code their internal Jira tool.
Somehow that has not happened yet in 2026.
This is because what management wants and what builders want are not aligned, not because the quality of JIRA is so amazing that no other alternative could ever be created. JIRA is fine but many people I know that use have some qualms with it because the bloat is pretty crazy.
As Spolsky said a quarter century ago, "bloat" is just "bugs somebody already fixed". (He may have actually said that about "cruft", but the idea still applies.)
Hard to believe that it was that long ago!
Yeah, I moved my team to Jira and sold it as "yes Jira is terrible but all the others are much worse".
I also spent a solid two weeks in the admin panel chainsawing as much Jira bloat as I could. It's perfectly adequate now.
The market seems convinced it will happen, considering its stock price is in the gutter
I'll be glad to admit I'm in the wrong when it actually happens.
I think there’s also the classic “I can build zoom in a day” - they get video working between two machines. But it’s the last 80% of the app that takes 99% of the time. Nerds don’t see the whole product, just the happy path of a wee technical challenge.
This may be true pre-LLMs, but I think you need to account for the baseline build-vs-buy tradeoff shifting.
Companies in most cases don’t want to build SaaS because it is expensive to hire engineers to do it, not because they are allergic to owning teams.
If in-housing becomes substantially cheaper than the alternatives then companies will adapt.
But even if the new equilibrium is to hire a contract dev shop to build something custom to keep avoiding responsibility, this would have the same impact on SaaS.
So I’m pretty skeptical of this first-principles prediction expressing right level of uncertainty.
You’re forgetting the companies that already had developers.
Whose job had been maintaining a single internal system but had never had the bandwidth to expand their focus.
Companies like that are the ones spending millions a year for large one size fits all SaaS products.
The same cost savings could be captured by SaaS. Potentially not by incumbents, but by up and comers.
If you can spend $10K/year to keep your in house one alive but $5K/year on the new SaaS option, you stop building your own again.
Possibly, but I don’t think it’s certain. For a SaaS to capture, you’d need a forward deployed engineer model. And then I would have ten different FDEs to liaise with, none of whom know my domain.
Vs if I contract a shop, then I have a dedicated team ramped up on my domain who then can vet infra providers and choose the best tech. So potentially still some SaaS, but probably shifting more to PaaS.
Similar to how you don’t hire your Salesforce or SAP contractors from these companies, I would predict this model spreads to other platforms too, and may make OSS viable in more places.
I think with a SaaS you're trading user research and workflow design for a certain lack of customization, and that for 90% of businesses that will remain the right call. (And for the ones where it's not the right call, I think the contractor model also makes more sense than in-house LLM-generated-user-tool teams. That's a lot of code to pile up under a very small team for long-term maintenance. Yeah, "the agents can do it," but you're making ever-more balls that the people overseeing the agents will have to juggle over time.)
If you're selling honey online, say, how bespoke does your inventory management tool really need to be? And are there no lessons you'd learn from a SaaS tool that you'd not have thought of on your own?
I could believe that SMB SaaS doesn’t change much, but the vast majority of revenue is from enterprise.
I think enterprise SaaS is where you’ll see big changes.
I totally agree about the management reluctance to just own everything in house.
But I think it’s plausible that SaaS companies will be easier to start with AI coding, and with lower costs (thanks to AI) they will be able to get into the black with a smaller addressable market. So each one can have a different mix of fewer features, for different segments of customers, at lower prices.
The result would be a loss of pricing power by the incumbent do-everything big guys: no more baked-in 10% annual increases. Which is still a pretty big change in their economics. And therefore valuations.
The companies that already have a strong in-house team will greatly benefit from AI. Many of those who don't are in that situation because managers have PTSD from so many failed projects. Half of all projects fail. That's a lot of emotional trauma.
This was all possible pre-AI. The reasons that some Saas companies win have nothing to do with how quickly or cheaply code can be written for the Saas.
I can't count the times I've told clients and prospects to _not_ hire us to build something they wanted. Because they could just use off the shelf solutions that were cheaper financially, at least in the short to mid term, and much, much cheaper in terms of opportunity costs. I struggle to put even billed hours into something that doesn't make sense to me.
Of course some overdo it. I've seen companies with more random SaaS tools than staff, connected with shaky Zapier workflows, manual processes, or not at all. No backups, no sense of risks, just YOLOing. That's OK in some cases, in others really not.
I suppose it does need some engineering thinking to find the right things and employ them in a good way. Unfortunately even developers commonly lack that.
I'm a manager too, but I'm also the new guy pushing the solution to a human problem: work management. SMAR, ASAN, MNDY, etc. Not only do people not want to be responsible for it (and in some cases simply be "not responsible"), not only is the internal solution "too time consuming", the only answer thus lands on hiring external consultants to implement and maintain massively-overkill-$olution$ in $aa$ like CRM, NOW, etc. which as you know, do not solve the same problems as the aforementioned SaaS.
"Now that I'm in management, I 100% get it." 100% and win or lose I am still going to fight it...
And since you became management, you have refered to software only by the stock symbols of the owning companies?
But this time management has to justify its AI spend.
We've been through cycles of outsourcing and in-housing skill before. This seems similar but for tools and services. Maybe we'll see internal teams taking the reigns back to replace bad-fit SaaS products.
There's still a lot of risk associated with in-housing though (perhaps more than before). That means the real opportunity is for new, leaner B2B SaaS businesses to step in, especially if there's a displacement effect from seeing internally built prototypes of expensive subscription software.
There's that and then there are companies spending 100k on a software suite just to use that 2 features. So now one of their junior dev solves it and becomes a hero. The truth it always somewhere in the middle.
I think the pressure on SaaS margins won't be from customers vibing their way to Figma or DataDog but because gen AI will bring a lot more credible competition in many segments. DD and Figma are probably awful examples because those companies are constantly pushing the envelope, but there are a lot of rent seeking SaaS providers that are going to be in for a rude awaking.
The difference between a vibe-coded prototype product, even a good one, and an enterprise SaaS platform is the difference between a Lightning bug and a Lightning Bolt.
To be fair, re-creating the SaaS solution that simply replicates the features they see can often be done fairly simply. However, there are generally a whole lot of things under the surface. Then there is the whole hosting and maintaining the system, which is its own problem.
Also, management doesn’t have time to fully understand it, which means they need at least one employee who does. And that employee now has leverage.
> "just do the parts of it we actually use".
25 years here. You can absolutely do this. Most software is orders of magnitude more complex than it needs to be.
The junior programmer you are talking about who wanted to rewrite it in a weekend tends to come back with a working program, not empty handed.
I've seen this happen with both juniors and seniors. They do come back with a working solution /for the happy path/. Because the happy path is easy. It turns out that most of the complexity sits in the unhappy paths.
I still don’t agree. The trick to good design is getting more things on the happy path. Most of the software I use is small and constructed in this manner.
"They only coded the happy path" is software engineer for "they coded it as if nothing would ever go wrong". It is definitely not good design to do that.
There's an engineering trap/fallacy I like to call "how hard could it be". How hard could it be to build a [whatever] clone? If you find yourself thinking that, stop what you're doing, because the answer is almost always "at least an order of magnitude harder than you think."
What I meant is that most commercial software has a large number of code paths. Because it’s built incrementally, not holistically. This creates complexity and cost.
If you’ve only worked on that kind of software it’s hard to know the alternative which is to aggressively prune code paths and rework your main code.
And open source example is Quake. I rarely come across software whose inherent complexity is more than quake.
Yeah, that's not what the person you were replying to is talking about. I was explaining the jargon.
Complexity and LoC has nothing to do with "only coding for the happy path". Both complex and simple software can be written this way.
A great example is the moltbook hilarity. They slapped together something that looked good and did function -- in the happy case only. They put together an "authorization" flow but exposed their entire database because they didn't know how to secure Supabase. They had no rate limiting on account creation -- so one dude created 1M in an hour.
Even putting aside adversarial usage, you have to code for, like, normal stuff going wrong or your app will lose data, crash, leak information, fall over, etc, etc.
I think you are not considering what I’m saying.
I’ll put you in the “it’s impossible to make software” camp.
I agree. Just because you can buy some piece of software doesn't mean you should -- there is a lot of software that exists just to sell more consulting hours and will never fit the business. It's actually not hard at all to code and maintain much simpler alternatives.
Actually having to support multiple businesses with commercial software is hard. I've written a ton of custom software that far surpasses the capabilities of commercial offerings but if were to turn that into it's own commercial offering it would be large undertaking.
Yes, I didn't really doubt the developer could do it, the problems are:
1. That's not a great use of the developer's time, and
2. anything in-house increases our training and support costs
1. The whole point of developer time is to save user time; if a developer can do that then it's worth it.
2. If the in-house software doesn't decrease training time or support costs then there is something wrong there.
1. No. The point of having engineers is to build product and make you money. They cannot make you money if you waste their time on building internal apps that do not make you money.
There's no point in saving $20K on an SaaS app if you use $100K in developer time and miss out on $1M of potential revenue. We get paid the big bucks because we can make companies a lot of money.
2. Haaaa no, that's 100% not how that works. If you buy a SaaS product, the company made that product. They have documentation. They have training. You can hire people who have worked on that system before. If it goes down, they get paged.
If you write the tool, all of that is on you to do. If it goes down, you have to fix it. If it screwed up data, you have to fix it. Any time anyone has any questions? Guess what, you're the one they'll ask. All of that costs the company money, because you don't work for free. When you quit, the app is now useless and can't be fixed unless you did a lot of work beforehand.
It's best to think of DIY apps like those really really sticky noxious tarpits. It might look safe or easy to get into, but good luck getting out of them. You might end up at the bottom with the bones of everyone else who thought that DIYing it was a good idea.
> The point of having engineers is to build product and make you money.
You're making the assumption that all software development is for software products. My work supports a non-software industry. Every minute that I save of user's time translates into more time they can use to make money.
> There's no point in saving $20K on an SaaS app if you use $100K in developer time and miss out on $1M of potential revenue.
If the SaaS app is $20K, I would agree. Probably the cheapest we have is $30K per year, most are an order of magnitude more than that. And it doesn't take a $100K of developer time to replace some of them.
> Haaaa no, that's 100% not how that works. If you buy a SaaS product, the company made that product. They have documentation. They have training. You can hire people who have worked on that system before. If it goes down, they get paged.
Haaaa no, that's 100% not how that works. You buy a SaaS product then you pay them to install, configure, customize it. That can a small amount or a large amount. That can take a small amount of time or years. You can maybe hire people who have worked on that system, but probably not, and it's mostly bespoke knowledge that only a small amount of people have. They aren't cheap. But you might be entirely dependent on the vendor.
If it goes down, you have to put in a support ticket. You wait. Everyone is still on your case but you can't do anything about that. If you have access, sometimes you can fix it yourself -- and you do -- because waiting for support to do it properly is awful. If it's screwed data, good luck, they're not good at fixing that. Anytime anyone has any questions? Another support ticket. None of these people work for free; expensive support contracts. The level of support you get is completely divorced from that cost. You can't pay less if the support is terrible, you can't pay more to get better support (not that you would want to).
If I write the tool and it goes down, I can fix it. Awesome. If it screwed up the data, I'm more than capable of fixing that. If anyone has any questions, guess what, I actually know the answers. The company pays me for these services. When I quit, the app can be easily fixed because it's all standard technologies that lots of people know. Those SaaS tools? They're the black box that nobody knows how to configure, customize, or fix. The vendor isn't interested in doing anything more than the minimum needed to close the ticket.
> It might look safe or easy to get into, but good luck getting out of them.
Just try and switch away from your cloud SaaS product. You might not even be able to get your data out.
> You buy a SaaS product then you pay them to install, configure, customize it.
Ok, hold up. That is not a SaaS app lol. That is an on-prem installation. Very very very very much not the same thing.
The entire point of SaaS is you don't install it on prem. SaaS directly competes with what you're talking about.
Before you go declaring an industry is dead, at least understand what it is.
> My work supports a non-software industry. Every minute that I save of user's time translates into more time they can use to make money.
Sure. The corollary to that is every minute your app doesn't work you cost them money. If you fuck up and store protected data the wrong way or lose data because it tipped over, you're also costing them money.
Replacing some tinkertoy nobody relies on is easy. If your app is in the hot path, congrats, you're now critical infrastructure lol. This is the Bad Place.
> When I quit, the app can be easily fixed because it's all standard technologies that lots of people know.
I can tell you have never had to clean up one of these apps. Knowing the technology is not the issue. It's figuring out all the random decisions and details and load-bearing parts and reverse engineering someone's weird tooling without breaking things. It sucks real bad because you don't know what you don't know.
> Just try and switch away from your cloud SaaS product. You might not even be able to get your data out
Sure you can. Getting the data is the easy part. In the very worst case, you might have to pay them or get someone in management to scream at them, but it's the easiest part of that kind of project.
It's the rest of that kind of project that's tricky. Replacing a critical live system without downtime is Srs Bizness.
> Ok, hold up. That is not a SaaS app lol. That is an on-prem installation. Very very very very much not the same thing.
I didn't mean to imply on-prem. "Install" was the wrong word; call that "onboarding" instead. There is always some integration component as well because nothing lives entirely on it's own. Some SaaS providers are really good; no complaints on this part. Some are terrible. I believe one new vendor is going to try and charge us almost $100,000 to integrate their product with our other products. The entire purpose of this product is the integration. This is one I'm pushing to do internally because it's so fiddly.
> The corollary to that is every minute your app doesn't work you cost them money. If you fuck up and store protected data the wrong way or lose data because it tipped over, you're also costing them money.
So? You seem to think SaaS software doesn't go down, break it weird ways, get slow for no reason, etc. Across everything we probably had half a dozen small outages last month. But none of our internal (also cloud) products went down at all. Hell, one of the biggest most common SaaS products in our industry released an undocumented change last month to their API that subtly returned incorrect results. As far as I can tell, they still haven't acknowledged it.
I'm not saying we don't have bugs or bad things don't happen but I don't see why you think that externally purchased software is automatically better.
> I can tell you have never had to clean up one of these apps. Knowing the technology is not the issue.
Good developers produce good results. I have a new intern on my team who's currently still in school and she's absolutely killing it working on our apps. So maybe the problem isn't internal development, it's just shitty developers. Those exist in SaaS products as well; I look at some of their shit and I wonder what we are paying for. It can be well hidden behind nice marketing and big brands but it's still crap.
One vendor tried to sell us a product that was actually sneakily split into two pieces -- one developed in North American in .NET and the other half in India in PHP! They nightly sync the data between them. At the time, we had multiple products for this job and we were looking for one integrated product to replace them. I just happened to notice when looking at the URLs during the sale pitch and that's what caused them to spill the beans. We didn't buy that product.
While a lot of our internal development is complete products, a good chunk is actually filling out the functionality holes or working around bugs in our SaaS products.
> Sure you can. Getting the data is the easy part.
The last one we dropped, we definitely didn't get our data out. In fact, as soon as we cancelled the contract (3 month lead time) we were basically dead to them.
> I'm not saying we don't have bugs or bad things don't happen but I don't see why you think that externally purchased software is automatically better
If you staff an entire team to build apps, update, maintain and deploy changes to them, and run a call rotation, and that's all you do, there's no problem. You just have an internal development team. That's completely fine.
What's not fine is the people going "how hard could it be to replace Y" and slapping something together. Those sort of skunkworks projects have a couple common common failure modes:
1. the project fails after a lot of wasted effort 2. the project succeeds...but is never productionized. The person who wrote it is now stuck writing it forever. Which they might like, but it's miserable if they quit or retired or get hit by a bus aka the bus factor.
If the bus factor is one, that is pretty much always pain.
The point of SaaS and service-contract type enterprise software is not that they are perfect and great and not buggy. Enterprise software sucks a lot. SaaS is usually "you get what you get".
The point is you can't halfass it. Either you go whole ass and staff out a big enough development team (with all the expense and difficulties implied) or you go none ass and buy.
And both are completely different arguments then your original post.
No, those are the two main reasons management don't want to have internal systems belong to them
I see. I misread. My mistake. I agree - the issue is not technical it’s the responsibility for the project.
If the management is the one actually paying for the software from their own pocket (founder), the tables turn. There are millions of SME owners who are forced to pay for B2B software just out of necessity and not having resources to build it in-house.
AI could change that for good.
I work at a smallish public tech company and while this may be true at some companies, it's not true at all of them. We have almost no SaaS vendors. If we do have to buy software, we're almost only interested in On-Prem.
It almost always devolves into some all encompassing ERP that is meant to solve the needs of all parts of the business and save millions in licensing costs, and we all know how well that plan goes.
Software without support is useless. In the business world, what's being bought isn't code—it's a solution to a business problem, with a throat to choke if things go wrong.
I guess one difference is now you can ask an LLM, trained on an open core product, to generate a license-free version of it.
management simply doesn't want to be responsible for it
That sounds dysfunctional. The purpose of management is to manage risk, not to avoid it. A proper manager would be able to quantify both the risks and the costs, present those figures in an easy overview, and then be able to defend their decision (or advise higher management) using that.
My firm has partially transitioned through this curve. We went went from "fully externally supplied" systems, to an architecture that combines "externally supplied" (core functionality) with "low code" about 6 years ago. I would argue (as a financial manager) that that lead to a more flexible and more affordable architecture. A funny mixed bag problem arose though: the curve of business demands grew harder than that of IT-delivery. So IT delivered more value, but business keeps demanding a faster pace. If I project this line to the future AI will most certainly harm our external suppliers. We keep getting better at DIY development and "low code" will transition towards "no code". Not really "no code" of course, but DIY IT developed tooling.
The age of the business developer has re-arrived.
For the first time in my career, I can point to multi million euro external suppliers, tell my environment "that's basicly an API + authentication from X to Z, let's develop that ourselves" and get a response of "When" instead of "No". B2B SaaS is toast in my perspective, as are boutique firms delivering solutions + consulting. I can create a million euro team easily (that's like five developer years), if they deliver a successful insourcing. And now I feel like writing MBA-slop, but's it's all about growing your IT maturity. All insourced code is future maintenance expenditure. You need to balance that to the benefits.
> All insourced code is future maintenance expenditure. You need to balance that to the benefits.
I love this perspective. I feel like the pendulum has swung too far back to "it's easy to build, it'll be easy to support". But to be fair, it was probably too far the other way a few years ago: "it was easy to buy, it'll be easy to have them support it".
Other than trial and error, how do you think about pricing out maintenance costs for insourced code vs purchased functionality?
Building a project is very different than building a product as a billing engine.
> management simply doesn't want to be responsible for it
The problem with this kind of thinking is that it strips away all nuance. At some point you have to be responsible for something ... otherwise you don't have a business. You are simply a wrapper around your SaaS providers and tightly coupled to their success. The key is knowing when to offload and when to keep it in house. Quite frankly, your average weekend MBA VP simply doesn't have the expertise to make these kinds of decisions. This is why so many VPs exit before things get bad.
> At some point you have to be responsible for something ... otherwise you don't have a business.
Uh, yeah? No kidding. That's why you focus on your core business. If your core business isn't "writing a new and better Jira", don't write a new Jira.
Reminded me of big balls and DOGE. Didn’t we vibe code our entire government by now?
Your profit margin is my opportunity.
Think about it differently - let's say a free OSS product can be installed and you can use ALL features except for LDAP (because that's the paywalled portion that requires you to buy it for $25k / month.)
Well, with claude, you can download the code, tell it to implement LDAP authentication, and smile all the way to the bank. And for said fortune 500 company, employing an employee to spend 100% of their time maintaining the app at 10k per month is a 15k savings! And because it _doesn't really take 100% of their time_ it's really only like $500 per month? And to be completely honest, how man times did you get Jira to fast-track your issue?
I get it however, the manager angle. It's still a distraction. But the article being referenced still shows revenue going down.
There's definitely a lot of cope in here, mostly because SaaS is keeping them employed... be ready, the crush is "almosthere".
> an employee to spend 100% of their time maintaining the app at 10k per month
If the cost to the company is $10K a month, the developer's topline salary is $60K, which is going to be a hard hire to make.
And, again, if they can integrate LDAP with an existing software package at that price point, I want them doing something more valuable than that.
sorry, what do you mean?
1. Enthusiastic employee (vibe-)codes a replacement for a turnkey SaaS product that the company uses.
2. Company uses it, maybe even starts to rely on it for important business operations, and for a time the employee supports that app.
3. Bugs creep in, feature request pile up.
4. Employee either leaves the company or moves on to another project.
5. Pain
And don't forget the safety in getting to say "our systems are down because of [X TRUSTED SOFTWARE FROM LARGE KNOWN BRAND] and we're just waiting for them to fix it" instead of "our shitty internal tooling is broken and no one knows how to fix it"
Yes that's reverse-implied(??) in the "Pain" step. ;-)
This feels like it goes along the lines of "people's vibe code is cluttering up our PR's, people still need to review" -- it misses the boat: models are already capable of getting you up to speed on how the code is organized and works, in as much as you want to or need to be up to speed. They are already helping me cut down review time because I don't need to aimlessly hop around, I have a good starting point that I can scrutinize and dialogue about. Same thing here: employee leaves company -- about 3 years ago you would be right, now the company is left with an unmaintainable mess of legacy code and tech debt. TODAY this just doesn't matter. No one really needs to read that code too closely, it's already easy for agents to digest and explain and modify.
Doing this today, in production, with full trust, is clearly not wise, but the writing is clearly on the wall that this is going to be the norm more and more over the coming years. The times they are a-changin.
I think it has to actually work at least once before we can start predicting it will be the norm.
Can you be clear what you mean? What are you saying has not worked once?
And "it will be the norm" is a clear corollary of, absent any significant and unforeseen roadblock, even with the current highly imperfect agentic sausage-making factories we have today, what capabilities will be in like 6-12 months time.
When the effectiveness of vibe coding an internal workflow was measured, only 5% of efforts worked. That's pretty rare and bad. And those are the early adopters who tend to be more adaptable and effective with new technology. That's a big part of why people don't believe the (your) hype. Its great at simple things with a low cost of failure. Problem is, its rare to pay a good wage for simple things with a low cost of failure. Also, writing new code isn't a big part of most engineers jobs. To put it more simply, vibe coding optimizes the wrong things about engineering.
I think you can avoid the pain by thoughtfully designing it to avoid lock-in. You want it so that if needed, a dev can vibe-code a migration tool to the equivalent SaaS offering. AI lowers the barrier for creating these in-house replacements, but it also lowers the barrier for scrapping them too.
The thing about lower barriers is that it makes it easier for e.g. Salesforce to raise the level of expectations. And that's the moving target. New employees will come from elsewhere and wonder how a company is operating using tools from 2020 when X, Y, Z are becoming industry standard.
The key here is that the moving target will _never_ be "what can 1-2 people vibe code without any expectation of being the best at what it does?"
(Also: training people on bespoke tools takes much longer than training on configurations of standard tools. Imagine if you had to learn a new source control system at every job, like in the '80s.)
Even more accurate (I work in this space):
3. Bugs creep in, feature request pile up.
4. Employee continue in the company and request help (or the managers see the need):
4.1 They hire more, but if all are vibe-coders too
4.1.1 The product gets more complicated (no more complex, that good developers can manage!)
4.1.2 Bugs creep in, feature request pile up.
4.1.3 People start to get desperate, not worries! now:
4.1.3.1 Somebody vibe-code a new alternative that solves the immediate problem
4.1.3.2 Bugs creep in, feature request pile up.
4.1.3.3 Needs to sync with the other tools
4.1.3.3.1 Somebody vibe-code the sync that solves the immediate problem
(the saga continue)
In parallel:
4.2 Eventually is obvious that need external help
THEN:
4.2.1 They ask for consultors for build tool, of course, from a company that has embraced the IA!
4.2.2 They build new shinny tool!
4.2.3 Bugs creep in, feature request pile up.
4.2.4 Needs to sync with the other tools ....
AND:
4.3.1 They ask for consultors, to teach them what to do, of course, from a company that has embraced the IA!
4.3.2 New shinny theory of how do the thing with IA is now being implemented!
4.3.3 It require a rewrite of not only past solutions but, a change of how the company behave!
4.3.3.1 Needs to sync with the other tools .......
4.3.4 And it spark beautiful office/political debates around some philosophical whatever that also trigger changes in the structure, hiring or whatever, alienating the people that has been working there, that after months, has started getting the handle of it!
4.3.5 Employees either leaves the company or moves on to another project.
4.3.6 New employees arrive, with a wild new IA tool and different vibes that vibe-coding!
... the saga continues
5. Is now clear that it need to buy a product form a well stablished software provider
5.1 And all of them are now in the IA craze!
.............
Did you just put my post into ChatGPT with a prompt like "take this joke, make it unnecessarily longer, and get rid of the punchline"?
Nope, normal insanity of mine!
All of this will create noise whilst up-starts and competitors who dont fall for the trap carry on making real forward progress.
lol
ya ok, this makes total sense. i agree.
If I understand correctly many organizations will not develop original stuff internally, because nobody internally wants to be the one is shouted at if something goes wrong.
That's a huge part of it. But also you presumably hired a full-time programmer for a reason, and in almost every case that reason was not to have somebody to write and maintain your CRM system. So any system they build and maintain is not just another thing for you to worry about, it's a huge chunk of time that the developer isn't doing what you hired them for.
Depends on the size of the organization.
If software already exists that does X, X is a solved problem. You didn't hire a developer to solve already-solved problems.
ya, i agree. but in your world, this company will fail https://glue.ai/ ?
They're in series A right now, so most likely yes they will fail like most new businesses do. Internal chat is a hugely competitive field with multiple large players (and Teams has had Copilot for a while now). So, I wish them the best, but this is pretty much exactly the kind of "existing product + AI" mashups that will have a tendency to burn out over the next couple of years, just like "our old business but with .com at the end" did back in 1999-2000.
[dead]
I like to bring up JIRA example. You could replace it in-house yeah it is just tickets with statuses. /s
But then keep in mind one who built the replacement will become the owner of an application that business doesn’t want to pay for and that person will be cost center for the company.
That person better get marketing and negotiating skills that Atlassian has on board because that person will be responsible for the app and will not be getting salary increases for working on something that is not core business of the company.
Even if you can make LLM to do the app for you.
You guys keep using services like Jira, Salesforce, Stripe, Datadog, etc. While those are definitely the biggest names, I don't think people are referring to those SaaS platforms as the ones they will replace or try to build an inhouse version of. It will be things like ETL pipeline services, data scraping services, maybe some internal analytics SaaS. The niche things that cost a lot because they’re in a sweet spot where only a few people need them, but no one used to have the resources to build them in-house. So, when the salesperson called and offered a perfect solution to their problem, they bought the service. Those are the ones that will be more targeted for in-house solutions.
Yes, but the market is punishing the former right now.
They are though, atlasians stock is in the toilet. The world seems to think Jira will be replaced by AI built in house replacements, for some reason
when it takes 10 seconds to do anything on Jira, it's not hard to see why people want alternatives
Except that is not the reason, and that’s not new haha
I'd actually say the opposite is the case. B2B (even SaaS) is probably the most robust when it comes to AI resistance. The described "in house vibe coded SaaS replacement" does not mirror my experience in B2B at all. The B2B software mindset I've encountered the most is "We'll pay you so we don't have to wrestle with this and can focus on what we do. We'll pay you even more if we worry even less." which is basically the opposite of...let's have someone inhouse vibe code and push to production. B2B is usually fairly conservative.
Reminds me of a blog post a while back saying that gigabit fiber at home would lead to everyone running their own email server.
There was no chance that everyone would be running their own email server, but if it wasn't for the lack of IPv6 adaptation a plug and go home email server solution would probably see a decent amount of use. I'd bet we'd already be seeing it as a feature in most mid-ranged home routers by now.
The mail server in a router is easy to host, the problem is:
1) Uptime (though this could be partially alleviated by retries)
and most of all:
2) "Trust"/"Spam score"
It's the main reason to use Sendgrid, AWS, Google, etc. Their "value" is not the email service, it's that their SMTP servers are trusted.
If tomorrow I can just send from localhost instead of going through Google it's fine for me, but in reality, my emails won't arrive due to these filters.
> "Trust"/"Spam score"
See jwz's struggles with hosting his own email. (Not linking to his blog here with HN as the referrer...)
With email, the 800 lb gorillas won, and in the end it didn't even solve the spam problem.
I use a small local provider (posteo) and have 0 problems with spam.
So a 20 pound monkey can also throw around some weight. To be fair I only use it for personal stuff its probably different if you need enterprise scale l.
> With email, the 800 lb gorillas won, and in the end it didn't even solve the spam problem.
I have a 15+ year old Gmail account that I've used everywhere. Spam has been a non issue since 15+ years ago.
Your experience isn’t representative. Mine isn’t either.
I've seen plenty of Gmail accounts over the years and they pretty much look the same.
The only Gmail accounts that are "overrun by spam" are those of people subscribing to lots of spammy newsletters and then not knowing how to unsubscribe from them (or figuring they'd stay subscribed in case the next newsletter is the Magical One™). But that's 100% self inflicted and you can't save those people with any technical solution.
Email spam isn't a day to day problem for Gmail (at least) since Bayesian email filtering was first implemented.
[dead]
The specific concern around uptime & reliability was baked into email systems from almost the start - undeliverable notifications (for the sender) and retries.
But yes, the “trust / spam score” is a legit challenge. If only device manufacturers were held liable for security flaws, but we sadly don’t live in that timeline.
Its not a device/MTA issue, SMTP just is not a secure protocol and there is not much you can do in order to 'secure' human communication. Things like spoofing or social engineering are near impossible to address within SMTP without external systems doing some sort of analysis on the messages or in combination with other protocols like DNS.
SMTP isn't at fault, the social ecosystem is at fault. Every system where identities are cheap has a spam problem. If you think a system has cheap identities and no spam, it probably doesn't have cheap identities — examples are HN or Reddit.
Trust / spam score is the largest one I think, second to consumer ISPs blocking the necessary ports for receiving mail.
Even if your "self hosting" is renting a $5/month VPS, some spam lists (e.g. UCEPROTECT) proactively mark any IP ranges owned by consumer ISPs and VPS hosting as potential spam. I figured paying fastmail $30/yr was worth never having to worry about it.
Not to detract from your wider point, but there's a few ISPs which own IP blocks which aren't blacklisted.
I had quite a bit of success with it and of course, DKIM and the other measures you can take some years back.
For personal emails, I don't think I had any which fed straight into spam.
For "Trust", I believe patio11 described this system as the "Taxi Medallion of Email".
e.g. you spend a lot of money to show that you are a legitimate entity or you pay less money to rent something that shows you are connected to said entity.
If everyone ran a mail server at home spam scores wouldn't be so strict
3) Upgrades suck. Admin also sucks
Maintenance is probably my number one reason for giving up on projects where I'm responsible for feeding the pet.
It's all about spam though, right?
Without some kind of federation or centralization, it seems hard to distinguish a hobbyist from a spammer if both of them are using a plug-and-go. Forcing that responsibility into the hands of Google, Zoho, and Microsoft seems like the best compromise, unfortunately.
For one, if my power goes out for an extended period of time I'd still like to be able to access my email. Communications really can't be hosted locally.
The email server bit directly correlates, too. Will everyone vibe-ops their own email server using AI? Of course not.
What a weird take. I was running my own email server 25 years ago on a 512 kbit ADSL line. No problem at all, would even be enough bandwidth today for most messages.
(Back then email still worked from residential IP addresses, and wasn't blocked by default)
I agree with you. In B2B SaaS you don't sell the software, you sell your expertise in a specific domain and the responsability you take for owning that expertise. The fact that the development costs are nearly zero will make them more valuable and more protifable
Development has always been a small fraction of B2B SaaS expenses after the first couple of years anyways
B2B is a large corp is like you describe, but it's very different in SMBs, and there are many, many more SMBs.
My experience is that SMBs are generally not run by people who feel confident doing any kind of self managed IT.
No amount of LLM usage is going to change them into full stack vibe coders who moonlight as sysadmins. I just don't see it happening.
Not until, that is, a new generation, that has grown accustomed to the tech, takes over.
Until then the current SMBs will for the most part fulfill their IT needs from SaaS businesses (of which I think there will be more due to LLMs lowering the barrier for those of us who feel confident in our coding and sysadmin skills already).
What new generation? Younger generations are less accustomed to self-managed tech.
This 100% most of new devices are locked, mobile etc.
Having seen how clueless the new generation is and the amount of brain rot they get from using LLMs over honing their own skills, I'd say it's the opposite...
I assume a vibe coded agent would moonlight as the sysadmin to maintain the vibe coded LoB app.
I'm considering SaaS replacements with in house code in situations where my general thoughts are "how can this possibly be the pricing for this?" which is not uncommon.
Well before vibe coding, tons of open source software existed (and exists) to replace SaaS. With lots of features and knobs and real communities. But I still often pay for SaaS because managing it is a headache. Some human has to do it. I can pay the human or I can pay the company. I really don’t see how vibe coded toys can replace real battle tested SaaS products. A better explanation is the bubble in PE ratio is deflating and it’s happening all over, regressing to the mean. AI is a convenient explanation for everything
How many SaaS companies are public? How is that bubble deflating?
These are real risks to these companies.
Your in-house teams can build replacements, it's just a matter of headcount. With Claude, you can build it and staff it and have time left over. Then your investment pays dividends instead of being a subscription straight jacket you have to keep renting.
I think there's an even faster middle ground: open source AI-assisted replacements for SaaS are probably coming. Some of these companies might offer managed versions, which will speed up adoption.
> Your in-house teams can build replacements, it's just a matter of headcount. With Claude, you can build it and staff it and have time left over. Then your investment pays dividends instead of being a subscription straight jacket you have to keep renting.
Lets take Figma as an example, Imagine you have 1000 employees, 300 of them need Figma, so you are paying 120k per year in Figma licenses. You can afford 1 employee working on your own internal Figma. you are paying the same but getting 100x worst experience, unless your 1 employee with CC can somehow find and copy important parts of Figma on his own, deploy and keep it running through the year without issues, which sounds ludicrous.
If you have less than 1000 employees it wouldnt even make sense to have 1 employee doing Figma
>Lets take Figma as an example, Imagine you have 1000 employees, 300 of them need Figma, so you are paying 120k per year in Figma licenses.
I mean in an example that almost happened... "you are paying 120k per year in Figma licenses, Adobe buys it, you are paying 500k per year in Figma licenses"
At least up until the point of vibe coding it was still worth the SaaS provider charging at least as much if not slightly more than you doing it yourself because most businesses weren't going to anyway.
By that logic, people should never use any Saas products because someday the price will increase. Then why even use Claude Code, someday they will get sick of losing money and increase the price to $1000/month.
I mean, yes it is a potential company ending risk if the continuation of your business depends on said SaaS product.
I mean, for that example there's even less to do: you just put your employees directly on Nano Banana or one of the simple Nano Banana wrappers.
If you need rich outputs, there are tools for that now too.
Let me put it another way - would you want to be Adobe or Figma right now?
And applied to the original point, would you feel comfortable being a SaaS company right now?
> you just put your employees directly on Nano Banana or one of the simple Nano Banana wrappers.
So you end up spending the money elsewhere? with exploratory design you can easily spend 10k a month on these models as a company of 1000, thus completely losing any monetary savings. Anyway you look at it, Saas worked because costs were spread out and low enough to not optimize it too much.
Now you have an entire in-house product to manage and build features on. It could potentially work but so much of what my company pays for is about much more than the software itself. One example would be BrowserStack for very specific browser and mobile app testing edge cases. Can’t vibe code this. Another would be a VPN service with the maximum number of locations to test how our system behaves when accessing from those locations. Another would be hosted git. Another is google suite and all of its apps. How can we vibe code Google Docs and Sheets and Drive and all of the integrations and tooling? It simply isn’t going to happen.
Maybe you are right and the companies do want to pay and not worry about these problems. But now they have a lot more SaaS options to chose from. The incumbent companies like Salesforce and Atlassian have less of a moat. Maybe they'll keep the power users but if a customer is only using 80% of the feature set there is new competition. Competition might come in the form of a startup but it can also come from existing SaaS companies expanding into adjacent domains. Canva now does docs. Notion does email. etc
Also, it is my experience that exec and boards favour safe and well known B2B partners over in house. It's a more publicly defensible approach that gives them an out if things go wrong and shareholders get upset.
For big corporations at least prices of SaaS are rarely an issue. Issues are: we don’t have the time to introduce a new tool, what about our processes, we don’t have the right people.
So how much Constellation Software stock are you buying since the market seems to think they are dead in the water after a 50% drawdown?
hard disagree, several b2b categories are going extinct because AI just completely replaced them.
I mean if we want recent examples just look at tailwindui since it's technically a SaaS.
> we want recent examples just look at tailwindui since it's technically a SaaS.
This is a terrible example. Show me someone ripping out their SAP ERP or SalesForce CRM system where they're paying $100k+ for a vibe coded alternative and I'll believe this overall sentiment.
These examples are going to be lagging indicators of the underlying sentiment.
Just because it cannot be done today, doesn't mean there is not a real appetite in large enterprises to do exactly this.
Without naming names, I know of at least one public company with a real hunger for exactly this eventuality.
I have heard this from execs at public companies as well. I think a HUGE part of this appetite is that today no one has yet been subjected to doing business on a bunch of apps cobbled together by vibe coders.
They are just hearing the promise that AI will allow them to build custom software that perfectly melds to their needs in no time at all, and think it sounds great.
I suspect the early adopters who go this route are going to be in for a rude awakening that AI hasn’t actually solved a lot of hard problems in custom software development.
In the world of B2B software many of the 'hard problems in custom software development' have not been solved by human coders either - it can be an extremely grim market for anyone who cares about software quality. I'm completely unconvinced that on average a vibe-coded app is worse than the typical B2B slop.
Exactly — that’s why SaaS isn’t going away.
I too have an appetite for magic beans, but unfortunately, I'll be unable to eat them until they exist. As it stands now, it doesn't seem like AI stuff can produce anything with this large a scope.
So, do their AI devs have deep knowledge of the business processes, regulations/legal (of course in all kinds of regions), scaling, security, ... ? Because the LLMs sure as hell are lacking that knowledge (again, in depth).
Of course, once AGI is available (if it is ever) everything changes. But for now someone needs to have the deep expertise.
> I know of at least one public company with a real hunger for exactly this eventuality.
Hunger or actually putting real investment against it? I'll wait.
[dead]
>> This is a terrible example. Show me someone ripping out their SAP ERP or SalesForce CRM system where they're paying $100k+ for a vibe coded alternative and I'll believe this overall sentiment.
I cannot imagine an SMB or fortune 500 ripping out Salesforce or SAP. However, I can see a point-tool going away (e.g., those $50/mo contracts which do something tiny like connect one tool to another.)
TailwindUI isn't really what I'd consider SaaS -- it was a buy once and download software product.
That means to keep making money they need keep selling new people. According to them, their only marketing channel was the Tailwind docs, AI made it so not nearly as many people needed to visit the tailwind docs.
If they had gone with the subscription SaaS model, they'd probably be a little better off, as they would have still had revenue coming in from their existing users.
> I mean if we want recent examples just look at tailwindui since it's technically a SaaS.
How is it in any way B2B? At most B2C + freelancers / individuals / really small SME.
It didn't have any clues a med/large B2B would look for e.g. SSO, SOC2 and other security measures. It doesn't target reusability that I as a B would want. The provided blocks never work together. There aren't reusable components.
Tailwind UI or now Tailwind Plus is more like vibe coding pre-AI.
Sorry but tailwindui is not a SAAS. There is no service or hosting. You buy a coded template once and then receive updates. It is totally not the same as a critical B2B SAAS that is running 24-7 on the vendor's servers providing real support and service.
TailwindUI unfortunately sits in a position of being an easy to disrupt business with current AI.
Now attempt the same with Zoom, I suspect vibe coding will fall down on a project that complex to fit the mental model of a single engineer maintained a widely used tool
Perhaps the case for premium CSS SaaS businesses, I guess (which seems particularly primed for disruption even pre-AI), but there are many more robust B2B categories out there that aren't literal code + docs as a service.
There is a paradigm shift but personally I like to zoom out a little:
It used to be that your new b2b product has to try and displace a spreadsheet. Now it has to displace an agent.
how dont people understand? if you have a VC funded b2b saas, you need to charge huge margins for the investors to get a return. now, small teams can vibe code a replacement and charge 90% less money. AI is going to kill saas margins.
i literally cannot understand why people keep repeating that non tech companies will build their own software, thats not the bear case for saas
Atlassian: surviving since 2002 because no-one could previously build a kanban board or project management app
I think the value is lost on the end user, but it’s more readily apparent to everyone above them.
I’ve talked to many non engineering managers that love Jira, love the reports, the way they can see work flows, do intake etc.
Engineers and even alot of engineering managers loathe it, largely, but I think we’re the collective afterthought
Also, FWIW, a lot of pain people have with Jira is self inflicted by the people who setup the instance and how it works, vs vanilla Jira
Did vanilla Jira for a while, battled with a web app that is actively trying to make you hate it—switched our team to Linear, couldn't be happier ever since.
As far as the Atlassian suite goes I do much prefer Trello.
I only mean this all to be fair to Atlassian, that not all issues with Jira derive from anything they’re doing specifically
no the difference is 90% cost savings, which was previously impossible
How does a company charging 10% their competitor afford to compete on marketing, sales, design, user testing or customer service?
(this is even granting that AI is a 10x speedup for developers, which I don't agree with and no-one has shown)
Well for marketing and sales your bigger competitor is already doing the work of showing companies that they want the functionality at all, and the cheaper competitor's sales and marketing pitch can be: we are much cheaper.
This is pretty much what blacksmith.sh does -- GitHub Actions but it's on faster and cheaper hardware. I'm sure they spend non-trivial amounts on marketing but "X but much cheaper" doesn't sound like a difficult sale.
(edit) And the design, sadly, can be as simple as "rip-off bigger competitor" -- of course if one day you are the big competitor because you "won" in the market, you'll need to invest in design, but by then I guess you'll have the money?
they dont, which is why these companies are going to get smoked. a small team of people will compete with atlassian head on. the whole saas business model is under threat
Yeah.... The code isn't the hard part. That's not where the value is.
This hard part when you're doing in house stuff is getting a good spec, ongoing support, and long term maintenance.
I've gone trough development of a module with a stakeholder, got a whole spec, confirmed it, coded it, launched it, and was then told it didn't work at all like what they needed. It was literally what they told me... I've said 'yes we can make that report, what specific fields do you need' and gotten blank stares.
Even if you're lucky and the original stakeholder and the code are on the same page, as soon as you get a coworkers 'wouldnt it be nice if...' you're going to have a bad day if it's hand coded, vibecoded, or outsourced...
This has always been the problem, it's why no-code never _really_ worked, even if the tech was perfectly functional.
this is what the stock market is pricing in
The reality is anyone generate useful code with an AI agent now. Dores in accounting can now automate all her spreadsheets in a single afternoon.
Not trying to hype AI, but we are in an interesting transitional period.
The accounting saas dores presumably uses doesn't "automate spreadsheets" as its core value prop.
related: i'm thinking these vibe coded solutions are revealing to everyone how important and under appreciated good UX is when it comes to implicit education of any given thing. Like given this complex process, the UX is holding your hand while educating you through a workflow. this stuff is part of software engineering yet it isn't "code".
[dead]
I, on the other hand, can't wait to fire every single B2B subscription we've got.
B2B SaaS is a VULN. They get bought out, raise prices, fail. And then you have extremely large amounts of unplanned spend and engineering to get around them.
I remember when we replaced the feature flags and metrics dashboards with SignalFX and LaunchDarkly. Both of those went sour. SignalFx got bought out and quadrupled their insane prices. LaunchDarkly promised the moon, but their product worked worse than our in-house system and we spent nearly a year with a couple of dedicated headcount engineering workarounds.
Atlassian, you name it - it's all got to go.
I just wish I could include AWS in this list. Compute and infra needs to be as generic as water.
If you're working at SaaS, find an exit. AI is coming for you. Now's a great time to work on the AI replacement of your product.
> And then you have extremely large amounts of unplanned spend and engineering to get around them
You get the same shocks with internal teams, just from other causes. And you have to manage them.
I'm sure you've only ever seen brilliant software created by internal software teams?
> And then you have extremely large amounts of unplanned spend and engineering to get around them.
I have no idea how you are spending "large amounts" of unplanned spend on Saas products. Every company I worked for had Saas subscription costs being under 1% of capex. Unless you add AWS, which is actually "large amounts" but good luck vibe coding that.
Metrics at a fintech processing billions of dollars of daily GPV, plus the signals from every microservice in the constellation are enormous. Huge scale time series data.
We had an in-house system that worked, but it was a two pizza team split between time series and logging. "Internal weirdware" got thrown around a lot, so we outsourced to SignalFx for a few years. It was bumpy. I liked our in-house system better, and I didn't build it.
Splunk then buys SignalFx and immediately multiplies the pricing at a conveniently timed contract renewal. Suddenly every team in the company has to plan an emergency migration.
What agents are you using? If you stick to opentelemetry and open source agents and develop a collector infrastructure - You can switch across different vendors with lower impact and ramp off time.
Your supply chain is messed up. You need sign longer contracts with price guarantees.
If you’re working in engineering, find an exit. AI is coming for you.
1. This isn't rooted in data but anecdotes "One Series E CEO told me that they’re re-evaluating the quarterly renewal of their engineering productivity software because they along with an engineer reimplemented something using Github and Notion APIs. They were paying $30,000 to a popular tool3 and they were not going to renew anymore."
2. These anecdotes are about tech startups spend, not your <insert average manufacturing business>. Nor or they grounded in data that says "we interviewed 150 SMB companies and 40% of them have cancelled their SaaS subscriptions and replaced it with vibe coded tools"
3. "Analysts are writing notes titled “No Reasons to Own” software stocks." - there is just one analyst saying this: https://finance.yahoo.com/news/no-reasons-own-software-stock...
4. Most of these SaaS tech stocks have been trading at all time highs...this smells of "explain something very complex with a simple anecdote"
EDIT: Oh lol, the author has a vibe coding SaaS offering...there ya go.
As someone who works in the B2B SaaS space...
- If our customers vibe coded better integration points for us, it probably improves our overall value to our customers.
- The software industry, especially startups, is such an insignificant portion of the market, its not really worth worrying about. But, I can tell you from experience, that even large software companies don't want their own developers spending much time on accounting, ERP, or HRIS systems and they "outsource" this to SaaS companies.
It would be amusing if somebody parodied this article titled "AI is killing speculative articles about AI".
Not what you are asking for, but the Onion has some AI tips: https://theonion.com/tips-for-using-ai/
Fav tips:
- Give the AI restraints, like “Don’t tell me to kill myself as part of this stir-fry recipe.”
- Fact-check any information provided by asking the follow-up question “Are you sure?”
- Offset your water footprint by not bathing for 72 hours after each use.
Exactly. This sounds like a barber advising which haircut to get.
That too on a 30k contract. That CEO likely sells some AI software and is under tremendous VC pressure to show AI investment.
Yes, and the content itself is clearly AI generated marketing nonsense.
Yeah, this is just long-form linkedin slop. He's thought-leadering to get you to get his (no-doubt slop-written) guides and do leadgen for his forthcoming saas.
sigh.
Yeah, also if a SaaS costs, 10k a year, I promise its not not more cost effecient to pull your 10k a month engineer off their usual work to build and then maintain some vibe coded slope everytime an edge case occurs.
Also many customers of SaaS have little to zero engineering staff, they are in construction, resturaunts, law offices ect. These takes are so assanine.
Is there a place on the internet where folks like yourself, who seemingly have a way to think economically congregate? I personally dont know of one, for which if I did, I wouldnt visit here anymore.
So many takes on here are so lazy and simpleton that when you go a few levels deeper all the flaws get exposed.
Its called PolyMarket
... where they come with their own idiosyncratic mental/moral flaws
you gotta treat communities like newspapers - acknowledge their bias and diversify
Its funny you mention this, I was going to say that the only communities I've found online where +EV thinking is the norm is in professional gambling circles. However, those exist basically only in closed off discord and telegram chats, where we are actively manipulating polymarket/kalshi markets && comment sections :)
Also interesting.
Even in companies that have SWE, do you really want to divert in-house SWE time to something as exciting as ... accounting rules and making sure your inventory is auditable? Or any number of the weird compliance things associated with most B2B software for a medium-size business?
I have few sticks in the sand in my thinking framework:
* writing code has always been the easiest part of building software, deciding what to do and what not to do is something else that takes forever sometimes
* there are several open source projects that can replace commercial SaaS and still people prefer to purchase commercial SaaS. These are available immediately, deployed immediately etc etc.
* along the same line, some of those open source projects offer self-hosting and cloud version: I would always personally go for the cloud version because in a small team I don't want to operate something that other people built and I don't know how to operate. That's not my job not my team job
* people are underestimating how draining is operating and maintaining software, which is something that goes beyond the adrenaline rush you get after "building" something with Lovable or similar tools. Also, I find it extremely easy to get 80% done quickly but excruciatingly slow to get things done right.
* I still see huge value in using tools like Lovable to build a working prototype and validate assumptions so that you get quickly build the right thing right solving the right problem in the right away avoiding waste
* camcorders have been around for ages but you don't have millions of directors around just because you make a tool more accessible
* same can be said for other things like restaurants, where sometimes it's more convenient (although expensive) to buy vs build.
>people are underestimating how draining is operating and maintaining software
Yep. Many SaaS have an edge because they factorize the struggle of many customers, if a SaaS has 1000 customers, each customer vibing their way into a home-built solution will require dedicated efforts at maintaining it. Even with AI, those efforts aren't negligible.
Many companies don't even operate any IT infrastructure, cloud or otherwise, themselves, beyond office connectivity, AI replacing SaaS will require someone in charge of that at the very least.
> camcorders have been around for ages but you don't have millions of directors around just because you make a tool more accessible
tiktok alone has 1.5 million directors! it's just that we call them creators now.
the meaning of the word director has changed, that's all. but professional roles shift in meaning all the time. a computer used to be a literal human doing arithmetic. an engineer was someone who designed war machinery. being a doctor used to mean teaching at an university.
human beings are natural tool makers. we always have been. the frontier material to manipulate where the most advanced engineering happens constantly changes: stone -> bronze -> iron -> ink (descartes) -> steel -> silicon -> javascript (YOU ARE HERE).
notice how each step is an improvement/abstraction on top of the steps that came before it. some say english is next in that chain. i honestly have no idea. all i know is there will always be The Next Thing and it'll be much nicer to work with.
I agree with your larger point, however:
> camcorders have been around for ages but you don't have millions of directors around just because you make a tool more accessible
That’s exactly what happened. There are more filmmakers than ever now due to the accessibility of cheap cameras, then digital tools, including affordable HD cameras. Especially once the DSLR revolution took off circa 2011, which enabled budget-constrained aspiring filmmakers to use prime lens sets rather than fixed/built in zooms on cheap camcorders. With proper lighting they could actually make something look pretty damn cinematic. The entire industry has radically shifted in the last 15 years in particular due to these changes, but it started to shift around 2000 if I have to assign a particular year to it.
When you had to shoot on film stock, which was expensive and had a whole processing pipeline that one couldn’t reasonably do at home, there was a much thicker barrier to entry. You basically had to go to film school or get into the industry before you could start making your own stuff. Hell the Duplass brothers started out on crappy camcorders. Now? A smartphone, some cheap LED’s, a basic computer, you can really make something.
My point was along this line: writing code is different than building a product as much as recording a video is different than telling a story with a movie (long and short that you want).
Do everyone has the capability to build a comprehensive set of features that we call a product to solve problems that people or business have in their life?
That’s why I’m always skeptical about measuring AI impact based solely on quantitative metrics.
Like I said I agree with your larger point. But it’s actually not a great example, because lowering the barrier to entry, particularly the hardware side, led to a massive increase in the number of filmmakers and films in the world. People telling full stories from start to finish included. The reason it doesn’t graft well onto the AI discussion is that the process and output are controlled and measurable. There’s no real black box element. What you see is what you get and the output of the camera is fully controlled by the user.
> writing code has always been the easiest part
Let me provide some possible evidence against this: so many teams are desperate to rewrite their codebase but struggle to actually do so. And when they finally make the leap, it takes them 5x as long as they had hoped. Then sometimes the new code isn't even any easier than the old code.
I personally find writing code to be a huge time suck and I'm very happy that AI helps me save that time.
But again, how much of that time is spent writing code?
I've done rewrites, replatforms, a bunch of times. The actual programming is not the tricky part, but instead (1) picking apart the legacy system, understanding what to build, (2) orchestrating the work to shift transactions from service A to service B without breaking anything.
Teams and especially developers love to think they can skip that phase and just crack on with the programming, invariably what happens is the same as described above: intoxicating velocity followed by a hard stop when you realise you haven't solved problems (1) or (2) above
Most of a software project's lifetime will be spent as a maintenance challenge. i.e. How do we add the 237th feature without adding to the performance problems that already exist. Hence, the desire to rewrite the codebase to incorporate the abstractions of all 236 features.
I don't see AI helping with this. From my experience, it seems like the opposite. It can help you write the code after you've deconstructed the problem yourself and know how to keep it in check.
I reckon a lot of re-writes tend to take "them 5x as long as they had hoped" and "isn't even any easier than the old code" exactly because writing the code wasn't the problem in the first place.
It's business logic, edge cases and other small necessary details that accumulated over time which make the code 'messy'. Once you've integrated all those in the new system, it likely looks equally messy. And discovering and implementing all those extra requirements is probably what took you the longest.
Not to say this applies to all re-writes or that AI tools can't help the process
> “…deciding what to do and what not to do is something else that takes forever…”
If that’s the case, then I should think business owners and office workers should be able to sort that out, lestwise on the “how to automate the boring stuff” front. That repetitive, boring, time consuming, error prone work. Incremental, least work for greatest impact.
The danger is they pull a 1999 Mars Climate Orbiter —level mistake. Or their solution suite grows to big to manage with mounting tech debt.
Also, if you’re software also required some custom domain hardware, then there’s your bottleneck for protectionist business practices.
and also:
* several companies require their tool to have several certifications (SOC 2, ISO 27001 etc etc), how this will work with vibe coded tools?
I see that Software as a Service banked too much on the first S, Software. But really customers want the second S, the Service.
When you sell a service, it's opaque, customer don't really care how it is produced. They want things done for them.
AI isn't killing SaaS, it's shifting it to second S.
Customers don't care how the service is implemented, they care about it's quality, availability, price, etc.
Service providers do care about the first S, software makes servicing so much more scalable. You define the service once and then enable it to happen again and again.
They didnt, dont make the mistake of thinking Saas companies are just software companies. They are Sales companies who happen to sell software. Companies like Dropbox & Atlassian have long been surpassed in Tech but they live only because they continue selling even when demand was hard to get. Their moat is sales & networking and software has to be just good enough. And other part is service, these companies still have one of best costumer service since the start of early 2010s. You can still get refund on Uber quite easily, but if you try doing that at a regular old school company you would require a prayer and couple of business weeks.
Good point, sales is the winning factor in most cases. Why is Microsoft one of the largest software companies? Sales.
> it's quality, availability, price, etc.
Are you sure? Companies still use SharePoint Online, Teams etc.
The F in SharePoint stands for fast
Yes, many don't like Sharepoint, but still they use it. It's the tool they can use.
Customers don't care if Sharepoint uses LLM, they just want to share ideas, files, reports, pages, etc. If LLM makes it easier, great! If some other product makes it easier, great!
It's not about the product it's about the results.
You're proving the point? Sharepoint, teams: availability + price. Every company has microflows, sharepoint and teams are automatically available and part of the price or lower priced than the competition.
You missed quality and the price isn't that cheap
Nah it's not that at all. Most of the services are totally fungible and everyone has a short attention span. You need to be in a market which is extremely difficult to disrupt and have a product which people are totally dependent on. And those tend to have a rather large cost to enter unless you were in early.
That 2nd S is sometimes engineered into the product design to maximize vendor lock in, and consulting revenue.
Yes and that is exactly why they are losing. They have hostages not customers.
I think customers sometimes want the third S, Security, which is not (yet) a given in LLM-assisted coding.
I just don't want to pay $50/user/month for an initially open source product that was relicensed and then crippled that the initial group giving something away decided they wanted to make a business of it.
Use the original open source version. They can’t relicense anything they can just use a new license for future versions.
Why not, if it solves your problem?
I think one of the interesting things here is that AI doesn't need to be able build B2B SaaS to kill it. So much of the overhead of B2B SaaS companies is thinking about multitenancy, intergrating with many auth providers and mapping those concepts to the program's user system, juggling 100 features when any given customer only needs 10 of them, creating PLG upsell flows to optimize conversions, instrumenting A/B tests etc...
A given company or enterprise does not have to vibe code all this, they just need to make the 10 features with the SLA they actually care about, directly driven off the systems they care about integrating with. And that new, tight, piece of software ends up being much more fit for purpose with full control of new features given to company deploying it. While this was always the case (buy vs build), AI changes the CapEx/OpEX for the build case.
And in many cases, it's 12 features, with 2 of the features not even existing in the big SaaS.
I'm pretty sure every developer who has dealt with janky workflows in products like Jira has planned out their own version that fits like a glove, "if only I had more time".
If companies wanted to build thier own simple-JIRA they could have built themselves before. I dont think making a kanban board was hard even before AI.
You’re describing Excel.
AI will be used to do “excel better” more than “replace a managed, compliant, feature-rich-carefully-engineered, service”.
JIRA especially, and I'm always shaking my fist at Atlassian that simple APIs or workflows or reports aren't already included in the tool. I have to pay some other company $10/user/month to get this dumb report your tool should already be able to do?? Insane.
Jira has had free competitors that do at least 75% of what it does since it's inception. You could find a dozen on github that actually look good right now.
In spite of this, Jira is bigger than ever.
Until a given company decides they need access control for their contractors that's different from their employees, etc. etc. etc. - seen it all before with internal often data scientist written applications that they then try to scale out and run into the security nightmare and lack of support internally for developing and taking forward. Usually these things fizzle out when someone leaves and it stops working.
Bingo; the exact same arguments against regular-coding it in-house apply to vibe-coding it in-house.
Pretty much. My employer was looking to cut costs and they were spending ~500k a year on a product that does little more than map entra roles/groups to datasets and integrated with a federated query engine through a plugin. Took a couple days to build a replacement. The product had only a few features we needed.
I've found in the embedded space that people sell lots and lots of products that do everything you could ever want, and the most efficient thing to do is not buy those things and instead find a way to do just the subset of things you care about with your own back-end systems. The upshot of that is that because you're in total control if something goes wrong you can fix it without getting 6 people on a phone call to point fingers at each other.
As niche SaaS provider, I'm trying to avoid succumbing to the same fate. The product I built carefully for years would now be within the reach of a senior dev with a couple focused weeks -- if they knew all the requirements. To avoid being overtaken, I'm working to increase my customer's requirements -- getting them hooked on new reports and features I never had time to build before LLMs could do it for me. This makes it less likely for a competitor to be able to afford to quickly replace me.
At the same time, I have no idea what the cost of LLMs usage will be in the future. So I'm working to ensure the architecture stays clean and maintainable for humans in case this kind of tooling becomes untenable.
That sounds like a good strategy to me. We have a couple other products we're looking to knock out to reduce costs, and the decision comes down to me and another colleague. The thing these businesses have in common - difficult to partner with, rough edges for the use cases we need, and no appetite on their end to shore them up. We're paying premium prices for a subpar experience. If instead they adopted your thinking, perhaps we would've looked for savings elsewhere.
there's no shortage of software engineers, if it was so easy for an organization to replace a saas with something built in-house they'd be doing it all the time. In my experience in enterprise consulting implementing a well defined requirement is the easiest part. Getting everyone to agree on the requirement, getting it defined, and stopping it from changing after every demo is the hard part.
Exactly, a lot more focus -- and most importantly specific domain knowledge -- allows the end-user to build exactly what they need, fast.
Sure, and Github is filled with these 10 feature competitors. Some even have active communities.
Didn't seem to kill off the big SaaS players or even weaken them.
I don't think it is killing SaaS. I have definitely had to extend my sales cycle when a potential customer vibe-coded a quick fix for a pain point that might have triggered a sale a few weeks earlier, but eventually the benefit delivered by someone else caring about the software as their entire mission really wins out over a feature here and there.
If you are selling SaaS consider that a vibe-coding customer is validating your feature roadmap with their own time and sweat. It's actually a very positive signal because it demonstrates how badly that product is needed. If they could vibe code a "good enough" version of something to get themselves unstuck for a week, you should be able to iterate on those features and build something even better in short order, except deployed securely and professionally.
Everyone's going to talk about how cool their custom vibe-coded CRM is until they get stuck in a failed migration.
Yeah I have been saying this since the start of vibe coding, Saas companies rely on their sales, who are good enough to sell ther products even in tougher conditions. Software costs for the companies is 100% tax deductible, and they spend a very little on it (Most of times its less than 1% of CapEx). Only reason to optimize this cost is if the Execs of those companies think you can sell the same product.
> Software costs for the companies is 100% tax deductible
Section 174 almost changed that, but was reversed last year.
https://www.goodwinlaw.com/en/insights/publications/2025/07/...
> Everyone's going to talk about how cool their custom vibe-coded CRM is until they get stuck in a failed migration.
Failed/partial/expensive migrations is the name of the game with SaaS as well. Lock-in is the bottom line.
Migrations become much less scary when you truly own your data and can express it in any format you like. SaaS will keep sticking around, especially those that act like white-hat ransomware.
The other thing is bringing in the knowledge about what other customers in the same field want. For business-focused software this can be a boon, customers often can't really envision the solution to their problem, it's like the Henry Ford attributed "If I had asked people what they wanted, they would have said faster horses"
> What they don’t know, though, is that a poorly architected system will fail, eventually. As every senior programmer (eventually) understands, our job is complex because we have to understand the relationships in the real world, the processes involved, and the workflows needed, and representing it in a robust way to create a stable system. AI can’t do that.
I have a strong feeling the future's going to look like this:
Company vibe codes to replace a SaaS.
Little do they know this creates a time bomb: fragile systems where fundamental architectural defects are papered over by humans who knew the underlying dynamics but didn't articulate them well enough during the initial "vibe-architecture," so they're forced to patching the "impedance mismatches" with data entry or with even more vibe coding.
Those humans are eventually laid off, because of course they are. Data quality rapidly deteriorates. Operational mishaps deteriorate relationships with human counterparties. Defects begin to cost thousands to millions.
Suddenly, there's demand: not for SaaS, but for actual service businesses. Consultancies that can parachute in, do actual domain-driven design, and un-vibe that code. They do have a stronger-than-ever pool of out-of-work engineers (many from the failed SaaS companies).
The SaaS companies that survive understand that the first S no longer stands for Software; it stands for Solutions.
You're assuming that code in the future will need to be unvibed. Either the code will be good, or AI will be good enough to unvibe it. That might be awhile in the future but it will happen.
> or AI will be good enough to unvibe it
it already is
just point Claude Code at a Claude Code codebase you forgot about for a few weeks with no plan.md or agents.md or memory.md implemented
configure the session correctly this time and put it in plan mode, it will deal with your whole database schemas, migrate, tie everything to the new models correctly, make a backend deployment script, and fix your UI/UX
Not my experience at all. Claude Code is impressive but it needs to be used iteratively for serious development and requires lots of testing.
Need it to one shot that report against your db using React/Typescript? Or pump out a web form that submits to your backend? works every time.
Need it to do something a little more creative? It frequently fails in subtle ways that aren't apparent until later.
nobody was talking about one-shotting
but I could see why we would be talking past each other, there's one-shotters and everyone else
It’s about the "Per User Tax"
The panic over SaaS vs AI is simpler than people think. For years, we’ve been paying "Enterprise" prices for tools that are essentially just a UI on top of a database.
I'm a solution architect, and we recently looked at the $30/user/mo price tag for legacy test management tools. It’s insane. Why am I paying a "per user per month tax" for a glorified spreadsheet when I can pay $20 for an AI agent that can build me a custom version in a week?
So, we did exactly that. We used Claude and Cursor to "vibe-code" EZTest. A 100% open source, self hosted alternative that does 90% of what the expensive SaaS tools do, but with zero recurring fees and total data ownership.
The market is crashing because the "Application Layer" has been commoditized. If you can build and own your infrastructure for the cost of a few API calls, the era of renting basic software is over.
We aren't just building a tool; we're proving that the "SaaS Tax" is now optional.
Literally everything is a UI atop a database. Writing the data models, crafting the right uI and the right flows is non trivial. It requires iteration and that refinement is what customers pay for. The reality with SaaS stocks is they dont make anything critical. eg Take any large consumer tech company and they dont use Klaviyo. These companies build their own stack and one thats intimately connected with the data lake. It works for tech companies since they hve good data and it doesng work for non-tech companies because a good fraction of their data is trash.
That’s great. The overhead is that you have to host it and maintain the environment and app. If there is downtime that’s now your responsibility.
If that’s better than $x/month to be someone else’s problem then it’s a win.
Is there a middle ground that hasn't emerged yet?
Someone to host and manage your SLop-As-A-Serivce (SLAAS) for a price point in the middle.
That feels like a business.
Hey, that sounds like OpenAI!
> How to keep asking customers for renewal, when every customer feels they can get something better built with vibe-coded AI products?
Wrong take. You don't need to build something better, you only need something good enough that matches what you actually need. Whether you build it or not and ditch the SaaS is more of an economic calculus.
Also, this isn't much about ditching the likes of Jira not even mentioning open source jira clones exists from decades.
This is more of ditching the kind of extremely-expensive-license that traps your own company and raises the price 5/10% every year. Like industrial ERP or CRM products that also require dedicated developers anyway and you spend hundreds of thousands if not millions for them. Very common, e.g. for inventory or warehouse management.
For this kind of software, and more, it makes sense to consider in-housing, especially when building prototypes with a handful of capable developers with AI can let you experiment.
I think that in the next decade the SaaS that will survive will be the evergreen office suite/teams, because you just won't get people out of powerpoint/excel/outlook, and it's cheap enough and products for which the moat is mostly tied to bureaucratic/legal issues (e.g. payrolls) and you just can't keep up with it.
Having participated in the build of an inventory system / system of record for a large national retail company, I can't see vibe coding helping anything more than the prototyping in the discovery / requirements gathering parts of the process.
The sheer volume of data, the need for real time consistency in store locations, yada yada means that bad early decisions bite hard down the road.
Lots of drudge work can be assisted by AI, especially if you need to do things like in ingest excel sheets or spit out reports, but I would run far away from anything vibe coded as hard as possible.
The example I made about inventory wasn't random.
One of my clients spends 500k+ on XXX licensing per year (for a 200M revenue company that's not peanuts), and on top of that has to employ 12 full time XXX developers (that command high figures just for their expertise on that software while providing very little productivity) and every single feature takes months to develop anyway. Talking about stuff like adding few fields to a csv output.
So the total cost of XXX is in the 2M/year range, and it keeps ballooning.
My (4 men) team already takes care of the entire warehouse management process except inventory, the only thing that XXX provides, we literally handle everything: picking, manufacturing, packaging, shipping phase and many others.
In any case, nobody has mentioned vibe coding.
I stated that a handful of good engineers with the aid of AI in a couple of months can provide a working prototype to evaluate. In our case it's about extending our software that already does everything, except inventory management.
When you spend 2M/year on a software (1% of your revenue), growing every year by 100/150k it makes sense to experiment building a solution in house.
That situation makes sense but then i have to ask why hasn't it been done already? Software developers are not rare and if the use case is so isolated and discreet then surely it would have been tried by now. Even without genAI, CRUD, RDBMS record management, SSO, row level security... none of those things are new or out of reach until now. I think what you'll find is when you sit down with the users and start asking about the parts of the exiting system they actually need you'll never get agreement nor a clear answer. When/if you finally get a set of requirements and after UAT sign-off and then after go-live the users will say "this isn't what i meant" and you're back to square one. Rinse/repeat for years and then one day an exec will say "why are we wasting all this time, let's just subscribe to an OTS saas and make them configure it to meet our needs".
Nobody gets fired for choosing SAP, Salesforce etc.
Spending tons of money to get a janky, unreliable system of record, or finding out too late it is missing crucial auditing capabilities, or that it has Big Money bugs, on the other hand, is far worse, especially if you have investors asking what the hell you were thinking.
Your point about users not knowing what they wanted until after the fact is also painfully true. The hardest part about these systems is the people most likely to buy are the ones who have been doing it with a lot of human processes for years. Buying a SaaS or other third party product means having leverage to force them to change to more standard practices. Building in-house means that everyone will fight to high hell to make sure that their special snowflake way of doing things is accounted for and you end up in a worse spot as a result.
Complacency, bad management, revenue growing faster than costs for a decade hiding the problem, politics.
There's multiple people highly involved into maintaining the status quo which do everything to take any responsibility out of them.
People do do it, but unless you work for a company you won't hear about their internal tools or products since they aren't selling them.
Its funny you mention excel, I see vibe coding in the business sense right now being a gateway to replace all of the ad hoc uses of excel. We've basically leveled up the quality of the software you can build before buying a SaaS product or a hiring an in house engineer.
> I see vibe coding in the business sense right now being a gateway to replace all of the ad hoc uses of excel
I rather use Excel. It's likely More robust and safer than the vibe coded app that could trigger data loss / incorrectness / issues any time.
> I rather use Excel. It's likely More robust and safer than the vibe coded app that could trigger data loss / incorrectness / issues any time.
Excel has had a lot of data loss / incorrectness issues.
Example: https://www.bbc.com/news/technology-54423988
> Example...
It was 2020 and they were using a format that was replaced in 2007.
It. says more about their issues than Excel. I doubt paper forms would have saved them. Maybe they'll run out of paper and just ignore new entries too.
The moment vibecoded excel has a bug that regular Excel doesn't and a user has to wait on you to re-vibecode it's over. They'll just use Excel while you're trying to get the llm to find and fix the bug.
"For example, to create a data visualization I won’t seek any SaaS. I’ll just code one myself using many of the popular vibe coding tools (my team actually did that and it’s vastly more flexible than what we’d get off-the-shelf)."
That maybe doable in your 10-people startup, Namanyay. Try doing it in a larger organisation with layers upon layers of firewalls, databases, authentication systems and not the least importantly - management. Not to mention the vastly different audience, both in size and interest. Your own experience is not the experience of everyone else.
also, who pays for "a data visualization" SaaS?
I guess they mean BI, but for a company of any scale, they aren't paying for a chart, they're paying for a permissions system, query caching, a modeling layer, scheduling, export to excel, etc.
Stand alone BI tools are going to struggle, but not because they can easily be vibe coded. It'll be because data platforms have BI built-in. Snowflake is starting down this direction and we're (https://www.definite.app/) trying to beat them to it.
Definite looks pretty interesting!
thanks! It's been a long, painful 3 years getting here.
The term "B2B SaaS" is doing a lot of heavy lifting here and I think conflates two different things:
(1) Business model: hosted software you pay monthly for (vs self-hosted/one-time purchase)
(2) "Glue" products: tools like Monday.com that primarily provide synergy between data sources and workflows
The article is really about (2) - and yes, those are vulnerable to vibe-coding. If your product's core value is "we connect X to Y and show you a dashboard," that's now a weekend project.
But there's a huge category of SaaS where the value is in the product itself, not the integration layer. Take Excalidraw - fits the SaaS model, but try vibe-coding a collaborative whiteboard with real-time sync, proper data persistence, conflict resolution, export formats, etc. The hard problems aren't "connect API A to API B."
Or PostHog - sure you could vibe-code some analytics tracking, but building reliable event ingestion at scale, session replay, feature flags with proper rollout controls? That's years of engineering.
The "vibecodeable" SaaS products were always somewhat commoditized - AI just accelerated the timeline. The ones solving genuinely hard technical problems seem a lot safer to me.
I don't really agree with this.
Simple CRUD app sure, but we're nowhere near being able to vibe code even a relatively low-complexity enterprise SaaS product.
If it's got customer data in it and/or you're making important business decisions based on it, you really need your system to be accurate and secure. My experience is the people who procure enterprise software know this and tend to care a lot about it. They often have legal and contractual obligations around that.
In the 1990s there were people who thought OOP with point and click tools like FoxPro and Delphi would make it so easy to create software that everything could be built in-house without expert programmers. The invention of SQL was supposed to eliminate roles like Report Writer and Data Analyst because now business people could just write their own queries "in English" and get back answers.
> In the 1990s there were people who thought OOP with point and click tools like FoxPro and Delphi would make it so easy to create software that everything could be built in-house without expert programmers. The invention of SQL was supposed to eliminate roles like Report Writer and Data Analyst because now business people could just write their own queries "in English" and get back answers.
And yet, precisely that happened in the end, just not with the tools envisioned. Excel, VBA and, where you had one knowledgeable employee, MS Access makes for incredibly powerful and incredibly hard to maintain "shadow IT" - and made even more difficult when someone sneaked in a password, because that takes a bit of an effort to remove [1], knowledge that is easy for us today to find, but not when I was young.
Also, back in the IE6 era, there was a lot of point-and-click created web interfaces... just that it wasn't HTML5 or even HTML. It was an <object> tag loading some ActiveX written by some intern in VB6, or Java, or Flash. I sort of miss that era but also, it was a damn security nightmare. Flash with its constant stream of security vulnerabilities was ripe for exploits, but at least it didn't run native code with full user privileges by design. I'm not kidding, theoretically you could go and import/use functions from any system DLL up to and including Kernel32. OLE/OCX, ActiveX... a design way ahead of its time.
[1] https://stackoverflow.com/questions/272503/removing-the-pass...
Software got easier to develop, but we just came up with more problems to solve with software.
The new tools didn't shrink demand for COTS enterprise software - it grew massively since the 90s!
This is what I want to be true, but as someone’s at the middle of their career I’m terrified.
It's an interesting time for sure and I'm not clairvoyant but I really don't think "we won't need developers because business people will just vibe code their own apps" is coming any time soon (or possibly ever)
I think opensource is a good analogue here. For many SaaS products, you don't even need to vibecode anything - there is already a reasonable OSS alternative. Yet people still pay for the SaaS. They want support, maintainability, security, edemifcation, a throat to choke, regulation and domain expertise, etc.
I do think like this HN post (https://news.ycombinator.com/item?id=46847690) is a good example of where a custom more domain specific solution makes a lot more sense that dropping in an off-the-shelf ERP. Still though, I think the bakery would prefer to buy the bakery-ERP than build it but vibecoding does reduce the barrier to entry so we might see more competition and share taking from incumbents by domain-specialized new entrants.
Lots of companies buy saas, and then spend years customizing and effectively building what they thought they bought. And for big companies, it is costly - a few tens of millions for saas licenses, and maybe around 50-100m for system integrators leaching on the enterprise, and doing the integrations and customizations, usually dancing around the data model, api surface limitations of each of the saas tools they want to wire together.
I dont think going back to having own developers, owning the code is going to be a bad financial propositions for such companies. My company is now one month into trying this out and so far, so good. We kicked our outsystems addiction and are just went live with a react rewrite - and are well into rewriting an expensive to run document management system which we were at the same time under-utilizing and abusing. Our product people are loving it since for the first time in ages we dont need to tell them "well that would be real hard, considering we have salesforce crap underneath and it just doesnt do this or that well".
My thoughts are sort of similar. AI/LLMs have allowed many of the typical SaaS customers to think that maybe they could do at least some of this work themselves, and get better results.
For most companies this was always true, but LLMs have given them the confidence to actual start writing more software in house. The SAPs of the world have nothing to fear, companies aren't going to vibe code a CRM, but they are going to be able to more easily write integrations. At a previous job we frequently had bills for €10.000 for small integrations into our ERP, but once we figured out the API and gained more confidence in our abilities, all those integrations got pulled in house.
If your SaaS platform provides actual benefits, then you don't need to worry. If your business in writing integrations for other companies into platforms you don't own, yes, AI is going to hurt your business.
This should have happened regardless of AI though. The idea that companies (over a certain size, e.g. ~20 people) doesn't have a least on developer employed, regardless of industry always seemed like a missed business opportunity. We wrote so many tools for sales, warehousing, customer service and accounting and it's hard to imagine the business functioning without those tools. I might have spend two weeks writing a tool, but if it saves sales 20 hours a week punching in orders, we get a positive return in a month.
That sounds great. What SaaS are you replacing?
I'd rather not name names - but one of the major, popular ones.
We contracted a lot of usage, and are using it literally like a S3 bucket with a malware scanner attached to it, and ignoring the dozens and dozens of document management capabilities it has - that we don't need. (Because really, we only ever needed a S3 bucket with a virus scanner...). This alone will allow us not to renew that contract, and save, maybe, around 2M per year.
Sure, we will have to have our own API that will require support and what not, but... we already HAD to have our own API that requires support and what not, since we have a bunch of legacy document management platforms running in various countries, and we anyway have to operate an abstraction and a router.
I am sure ours might not be the most typical case, but there will be savings, and since the economy is what it is, my bosses are telling me to go for every saving I can find, and thats one of them.
(I'd not try to re-write an ERP system, for instance, or a CRM. But a lot of smaller things where we pay a substantial premium? Sure - we will try.).
Maybe it's mostly from AI, maybe it's mostly general economic cutbacks. I also feel like these "wrapper" style SaaS products are the first ones companies are dropping when they are looking to cut costs, and I think a lot of companies are looking to cut costs. I do agree with the overall conclusion either way, that System of Record products/companies are the most likely to survive. There are a lot of SaaS companies with questionable long-term businesses who are getting hit, but that was bound to happen.
The stocks of a lot of these SaaS companies were priced on the expectation that they could become the next IBM: become entrenched with the customer and then hike prices until their eyes bleed.
A lot of companies have been too smart for that, and a lot of SaaS offerings are too small to be truly entrenched. Arguably the investment horizon is too short (IBM took decades getting to that point).
The only real vendors who managed to become the next IBM are the cloud providers.
I think it's a combination of budgeting, upward price pressure from the SaaS companies themselves, plus bringing things in-house through vibe coding, but there's another factor that I think is harming existing SaaS products. Many of them are becoming legacy solutions with AI bolted on top so they don't really feel that effective or next-level. The underlying tech might even be a generation older too - but the SaaS value-add is providing support, scaling, etc to maintain whatever some old tech that's still a requirement. At some point someone looks at all of these interconnected systems and just says 'start over'.
Vibe coding might not be supplanting all SaaS solutions but it's definitely shaking out "last-gen" solutions.
System of Records especially for boring industries is the way to go. What kind of wrapper SaaS are you seeing getting dropped?
Analytical systems. I see a lot of add-on services that will add intelligence/analytics/etc and companies try them out to solve some issue they have and bounce off them frequently due to growing costs. I can only assume as mentioned that over time these are also easier for companies to in-house vibe-code as well, I just haven't seen a ton of that yet, but people are definitely trying which still shrinks the available pie.
This isn't happening. The past six months has been rough on public B2B SaaS valuations, but the impact is a lot wider than just B2B SaaS (its all non-S&P10 software), and valuations are just vibes in the end. Most of these companies are, financially, doing pretty well; seeing key metric growth, including revenue and profit. This makes sense: AI does not fundamentally change the bargain SaaS brought to the table, that companies would rather pay someone to solve their problems than solve them themselves. However, the stock market doesn't care about this. The stock market doesn't care about anything; it behaves irrationally and non-sensically, and trying to derive any sense of how stable, strong, or successful a company is from stock market valuation is like using lines of code to claim that a software project is really good.
>that companies would rather pay someone to solve their problems than solve them themselves.
Are they not able to just engage AI to solve those problems now? E.g. this morning I saw an app that did something interesting to me for $20 a month. 20 minutes in Gemini and I had a functional app that replicated the behavior. SaaS are more complex but give me a small team and a couple months and we could replicate most any of them.
No one is replacing Jira or Salesforce with an internally-AI'd analogue.
Give it a year.
Equity markets both private and public are mangled today, for a wide range of reasons which I wont get into.
Financial performance e.g. revenue is what counts right now as any hard-evidence.
This feels a lot like the old RPA hype cycle to me — more sales narrative than structural change.
Most companies are not going to replace stable SaaS with a pile of AI-generated internal tools. They don’t want the maintenance or the risk.
If there’s a real B2B game changer, it’s Microsoft.
The day Excel gets a serious, domain-aware AI that can actually model workflows, clean data, and automate logic properly, half of these “build vs buy” debates disappear. People will just solve problems where they already work.
Excel has always been the real business platform. AI will just double down on that, not kill SaaS.
> The day Excel gets a serious, domain-aware AI that can actually model workflows, clean data, and automate logic properly, half of these “build vs buy” debates disappear. People will just solve problems where they already work
Best they can do is more adware in windows. Sorry.
"The SaaS model was built on a simple premise: we build it once, you pay forever."
I've never seen a SaaS product that fits this description. There are always things to do. Libraries to upgrade, performance bottlenecks to diddle around with, an endless stream of nonsense feature requests from people at the customer who never actually use the product, fun experiments your developers want to try out, and so on.
The hard part in SaaS is to delete code, and that's what you should do, at least some of the time. Either through simplifications, or just outright erasing functionality that very few if any of your customers rely on.
What you should not do is let your customers grow the liability that is code in your production environment, unless your entire product set is designed to handle things like this, e.g. the business models of Salesforce and SAP.
It's not and I really doubt it will, for true SaaS platforms. A desktop .gif recorder (frequent example I've read about) is not a SaaS, even if you charge monthly for it.
Let's put an example an exception-tracking SaaS (Sentry, Rollbar). How do the economics of paying a few hundred bucks per month compare vs. allocating engineering resources to an in-house tracker? Think development time, infra investment, tokens, iteration, uptime, etc. And the opportunity cost of focusing on your original business instead.
One would quickly find out that the domain being replaced is far more complex and data-intensive than estimated.
There are many cases where the company might only use a fraction of the features (and therefore complexity) of the SaaS and so only need to develop and maintain those features they actually need. That's when ditching the SaaS can make sense if you can easily develop/maintain what you specifically need on your own with AI assistance.
Even if they use it less, if you combine all of the Saas products used by a company, thats a tiny fraction of the overall CapEx. And this cost is tax deductible, so there is no reason to optimise it unless Execs are really penny pinching, but at that point that company isn't worth selling to anyway.
What the authors of this kind of doomer-type articles do not realize is that B2B software companies have the data that their customers pay for, and they also have access to the AI tools themselves, meaning they can accelerate in adding new features to their products, making them more competitive.
It's a fallacy to consider the bad performance of software stocks as a definite sign that AI is going to replace them. One needs to factor financials into the equation to explain a downtrend. Take Figma for example, spending 109 mil on AWS bills, cutting through their margins. Investors know that such costs do not simply go down due to the vendor lock-in companies experience when using cloud services.
Claude Code is good, but definitely far away from being able to vibe code Figma.
I think the corrective to this is that many of these incumbents will fail to re-conceive their product stack from a user-centric perspective, and as a result they will be reduce to just a dumb data layer which is easily swappable.
Sure, they could do that, but the cultural change required is an order of magnitude harder than just sticking an agent on top of their source-of-truth and believing that the problem is solved.
Maybe it works for areas where the application is a relatively self-contained island of productivity. Figma is somewhere that a designer spends a lot of their day, so it's going to be less vulnerable, but most pieces of softare fit into broader workflows. So for Figma the disruptor is less likely to be "AI-powered designer" and more "AI-powered web builder" - e.g. Lovable or even Claude Code itself that just generates great designs.
> can accelerate in adding new features to their products
If anything AI helps companies escape the "feature wheel" that is used to justify exorbitant costs, while providing debatable (and often even negative) utility to the end user.
Keep in mind, Excel '98 would still probably be overkill for 85% of people's needs in 2025.
What companies thought was adding more utility, was actually just continually stacking costs in front of getting to that core functionality.
AI replaces the core functionality, and the "feature" scheme collapses...
“Overkill for 85% of people” is a vibes statistic, not an argument.
Also you're generalizing some things to the whole sector like every software provider now is useless and the new features they add are not bringing any values. How can you make such generic statements about a sector that is so diverse?
I start to suspect some of you are just private-equity-sponsored accounts trying to push Anthropic propaganda over the Internet.
People in tech are so wildly detached from how everyday people on the ground use computers.
By people in tech you mean the tech bros that do not actually code, just emit opinions on the Internet, right?
Claude Code doesn’t need to vibe code Figma. It _is_ Figma.
Take a couple screenshots of your legacy app, write a short paragraph describing it, and the web tool will give you a self-contained HTML file that’s a fully interactive mock-up.
But it’s still a mock-up. So software dev in general will be fine, it will evolve. But unless the AI companies run out of money and it turns out the $20/mo plan actually costs $1000/mo without VC subsidies, Figma is cooked.
so many conditions need to be met to have Figma "cooked". Plus you forgot that the underlying LLMs need to get exponentially better, hard to do that without infinite VC money.
The software industry moat is disappearing. What will happen is 1000 (10,000?) competitors putting price pressure on every saas app.
Software will cease to be a winner take all and be a very long tail distribution!
Where are all these 1000 competitors coming from?
You need to have tremendous agency/will to start competing with a public company. Plus, you need to have a lot of distribution channels, competing with sales people that do this for a living since ages, and marketing budgets that are higher than your annual Claude spending.
Regular people do not press 10 clicks daily to track their calories, and you're saying that they will start competing with Salesforce and the like?
Focus is a currency and you have a limited amount of it, if all SaaS is built internally, teams would go bankrupt. There's likely always going to be a band of experts focused on solving a problem and everyone pays them to solve it for them, because they do it better and can handle the hassle of maintaining it.
AI isn't killing SaaS exactly, but instead of selling UIs, SaaS companies are going to have to focus on infrastructure and data. You have to host stuff somewhere, so there's an inescapable cost and transaction that has to take place. If businesses can pay one bill for infra + data management and get nice apps and stuff on top of that (without being locked in), that makes more sense than trying to roll stuff together even if you have a platform team.
> AI is killing B2B SaaS
Anecdata sample size of one, but this is not my experience at all. My business has only continued to grow over the past couple years, and I don't think I've had a single customer mention AI to me at all (over the phone or email).
It's the opposite IMHO. AI is enabling a lot more B2B SaaS. There are a lot of companies that are running on outdated software. Especially in manufacturing and industry. They've had decades of experience with very expensive IT projects where cost got out of hand because things just are very complicated in the real world.
There are many millions of companies that are going to be re-examining if they can do better in the next years. The work will still be very complicated but with the help of AI, small IT shops might just deliver enough value to be worth the trouble.
The notion of e.g. busy floor plant/logistics managers vibe coding this themselves is silly. 1) they don't have the time; these people are super busy 2) they lack the ability. 3) they'll want it done properly 4) their employers won't skip all the certifications, iso stuff, and what not.
Companies invest in SAAS software if it delivers some kind of revenue/profit benefits. If it's too expensive/complex, it can't do that. AI tools lower the cost of SAAS solutions. So the totally addressable market grows. Companies will want to maximize their ROI though. So, they'll do the usual and engage software companies and integrators to help them do this. They'll expect to pay less for more. And there will be lots of haggling around that topic. But there's an enormous amount of companies that are quite far behind on getting their operations into this century in terms of IT already. There are going to be early adopters looking for early successes here that will put pressure on their competitors if they are successful.
I'm running a small company in this space. We're seeing a lot of opportunities right now. And AI is making my work massively easier already. All those complex ERP integrations just became an order of magnitude easier to do with a small team. They are still hard though. Forget about vibe coding that. You need a plan.
The framing is a bit dramatic but the underlying shift is real. What AI actually kills is the "wrap an API in a UI" SaaS model. If the value is just presenting data nicely or doing simple transformations, an agent can replace that.
What survives: products with proprietary data, strong network effects, or deep domain expertise baked into the workflow. The moat moves from "we built a UI" to "we understand this problem better than anyone."
I run 4 side projects and the ones getting traction aren't the ones with the fanciest AI features - they're the ones solving specific problems people have repeatedly (meal planning, meeting search). The AI is the engine, not the product.
The real risk for B2B SaaS isn't that AI replaces your product - it's that your customers can now build a "good enough" internal version in a weekend with Claude Code.
why does half of your comment read like it was written by AI?
Fair callout. I've been writing too many product descriptions lately and it's leaking into how I write comments. The actual point was simpler than I made it sound: AI kills "UI wrapper" SaaS, but products with real domain knowledge survive. My side projects taught me that - the ones getting users aren't the technically fancy ones, they're the ones solving boring specific problems.
It’s not as far-fetched as people think. I see so many comments here doubting you can vibe code a full CRM or e-commerce SaaS, but a skilled AI-assisted programmer absolutely can, especially if they're aware of strong open-source alternatives already out there.
For Salesforce-like CRM, there's Twenty[0], a good-enough alternative. For Shopify-style e-commerce, Medusa[1] is a headless commerce platform.
The real power comes from using AI to study how these projects implement specific features (payments, inventory, customer dashboards, etc.) and adapt them to your stack. AI excels at finding the "seams" (those connection points where a feature ties into the tech stack) and grasping the full implementation. The trick is knowing precisely where the feature lives in the code (files, functions, modules), because AIs often miss scattered pieces otherwise. That's what I'm building at opensource.builders[2]: turning OSS repos into a modular cookbook with structured "skills" that point to exact details for reliable remixing and porting.
SaaS companies are forever beholden to raising their market cap, even in solved spaces like cart, payment processing, and CRMs. Most businesses run on CRUD apps anyway, and if your core app exposes an API, you can build any customization you need on top of it. People here discounting how valuable it is for a business to have the software that runs their business on a tech stack they understand and something they truly own.
[0] https://github.com/twentyhq/twenty
[1] https://github.com/medusajs/medusa
[2] https://opensource.builders
Just because it's possible to build equivalent software by vibe coding doesn't necessarily mean that companies will stop using SaaS. There are multiple reasons why...
First of all, many big companies pay a fortune to use inferior SaaS solutions instead superior Open Source solutions; possibly because one of their CTO may have received kickbacks or promises of a lucrative job at the SaaS provider as a consequence of this deal. There are a lot of politics going on behind the scenes when it comes to procurement.
Execs at big corporations are often looking for plausible ways to spend investors' money in a way that they can capture some of it for themselves. If they choose open source or they choose cheap vibe coded solutions; there is not much money changing hands. No opportunities for insiders to covertly monetize.
And then there are a lot of security implications to using a complex vibe coded app. The AI won't be able to identify the vulnerability in any decent sized codebase unless you know what you want it to look for.
Lets break this down. There is very little in newness in what Anthropic announced. Claude had skills for a long time. They have added one more layer of abstraction and called it plugins. This mainly comes with a set of integrations.
Thats the pitch.
But, what are Claude plugins?
Plugins=Commands+Skills+Integrations.
Commands are specific to Claude code. But commands and skills are nothing but prompts at their basest level.
So what is the main differentiator?
Integrations.
But what are you integrating with?
SaaS companies.
And what is the stock market doing?
Dumping SaaS stocks.
How do they think Claude cowork will work without the integrations. Without the system of records.
If anything, these SaaS products have become more important. If I was a trading guy, I would go to the github of claude plugins, see the default integrations and buy the stock of those companies.
Lot of places that I see AI disrupting - I'm not buying that SaaS is going to be a significant one.
Reading through the article:
> They were paying $30,000 to a popular tool3
Couple things we needed to understand here:
If it's a technology company of > 1000 employees - then $30,000 month doesn't even get Finance's attention. And there is next to zero chance that anyone is going to vibe-code, deploy, support and run anything in a 1000 person+ company for $30,000 a month. SaaS wins hands down.Any product/service that people care about comes with a pager rotation - which is 6-7 employees making > $200k/year. If you can offload that responsibility to a SaaS for < $1mmm/year - done deal.
Yeh but in a company of 100 employees for software of 30k a year, it's more than worth it to take your standard 50k (GBP) dev and have them replaced it. It's a one time cost, and the support time will certainly be less than 50% of their time every year so it saves money.
There are many companies that operate like this all over the world. Outside of the hyper-growth tech VC world cutting costs is a very real target and given how cheap Devs are outside of America it's almost always worth it.
$30k/year? For 100 Employees. So - $25/seat?
I can't imagine it would ever be worth, under any scenario, trying to write/build/support any $25/seat SaaS software for any company I've worked at in 25+ years.
Another thing to keep in mind - very little of the cost of a SaaS license is the time it takes to build the software. Security, Support, Maintenance, Administration, backups/restores, testing/auditing said backups/restores, etc, etc.. and then x-training new SREs on how to support/manage this software, ...
Even as someone who spend 10+ hours a day churning out endless LLM applications, products, architectures from my myriad of Cursor/Codex/CC interfaces and agents - I'm dubious that LLMs will ever eat into SaaS revenue.
I'm sure (lots of) people will try - and then 1-2 years in someone will look at the pain, and just pull the ripcord.
I don't see that happening because companies need to concentrate on their differentiators. Is your enterprise vibe coding its own SaaS? Who's taking care of it?
> Is your enterprise vibe coding its own SaaS?
Yes, a lot.
> Who's taking care of it?
It's not hard.
We wouldn't do it for tools that are purpose made and have sane pricing in the market place. We do it for stuff that would traditionally go on a 'platform' like Salesforce or something that requires a lot of customization to begin with. It's so much easier to just roll your own than even just going through the procurement process of those kinds of tools much less the integration and change process (hiring consultants, etc). I'm not hands on with it, but I know our small group of AI are helping us eliminate $5m recurring annual spend this year and that's directly impacting the topic article. I won't be surprised if at some point we replace our more sticky ERP software or use this leverage to negotiate prices that are sane. Businesses have been gouged by enterprise software long enough.
Am I to understand your company wrote a CRM? What other applications did you replace? What company is this?
Yes to some extent. We wrote a CRM that works for what we needed. It's not a full blown SaaS product we could sell to any company as a tenant, as they would all want other features that aren't important to us. This is what happens during an implementation anyways, we only implement what we care about.
No names, but my company is service companies (mostly residential) - many logos with different verticals (think electric, hvac, etc). Having a SaaS CRM that served all our brands needs was always a challenge and made aggregating anything difficult (we basically were running multiple CRMs)
We were using dozens of SaaS tools per logo - and just going through them all and figuring out what features we need/want and rolling them into the larger system. We've also built handful of things for internal operations, finance, etc
Imagine working at a company who has it own Figma, Docker etc... Thats a recipe for disaster.
And you'd have to relearn everything every time you changed companies.
AI
It's hard to tell when people are joking.
Boy that "st" ligature in the subheading font is eye-catching, to the point of distraction.
There's a lot of it in the article. Very distracting, I just didn't know what to call it (I searched for 'tail' before posting my own comment).
Indeed totally unbearable to even read the article
Agreed. I thought it was weird on the ct ligature on something like the second sub heading and the next one had a st ligature. I stopped reading the article and was just scanning for st ligatures in the text itself (there are none) and then realised the main font was a less legible serif font and the headings that were bigger and shorter were sans serif which makes the ct and st ligatures stand out even more.
I didn't read any more of the article after that, and the primary reason was just this weird font choice.
I stopped reading the article because of it.
Here is the list of evidence the author gives for why AI is the reason software company stocks are down:
but it is down 25% in days. if not contagion that ai is going to kill saas, then what?
It really isn't. Nobody's migrating their payroll vendor to some vibecoded app. I agree with Jensen Huang that this reaction doesn't make sense at all.
My own prediction is that reliable vibecoding will be additive. It's a new capability that will help high-agency people do things faster or answer questions they couldn't easily answer before. Need to spin up a big custom Monte Carlo calculation and want a simple UI to control and configure it? You can just throw that together now. Need to get a draft budget allocation for a big set of projects calibrated against a set of conflicting constraints? Let an agent crank at it for a couple hours, then review and refine manually -- or just toss it out if you don't like it.
But building, running, and maintaining production-grade services or apps that the company relies on for its basic functioning? You're not just paying the SaaS vendor for having built the product -- you're paying them to maintain it, run it, and respond to issues promptly. You're also paying them to keep building it and improving it over time. To be clear, I think there are certainly cases where the rise of "coding AGI" is going to lead companies to build some services internally versus buying from a vendor, but I predict these will be highly custom and bespoke services that are too tailored for a specific corporation to make sense for a third-party vendor to try to sell.
It seems like 'the market' is making this bet. I'm not deep into financial reports or whatever. But what I'm seeing from the tech side, this is not at all true.
If anything B2B SaaS is growing with AI, and it hasn't even begun, the biggest AI markets right now are personal. The B2B market is up for grabs for sure, 0%-1% of niches have an LLM product right now. But traditional SaaS has a huge advantage, they have reams of industry specific data, and they have the customers, sure they will have competition, but they are the incumbents.
If I had any money I'd buy the dip
As a founder, there is another angle here that is worth mentioning. Not only does AI B2B SaaS allow insourcing, it also allows there to be 10x (imaginary number) the number of companies building SaaS for the same use case. What we see in healthcare or finance for example is executive fatigue from demos, in many cases mostly vibe coded frontend UIs that entrepreneurs are using to test the market. This creates friction for businesses / SaaS companies that are unable to show how their solution is unique, well built or has a clear moat over the many others they have seen.
Bang on. I mentioned this as well. Mature SaaS companies are also expanding into each others domains. Notion is now doing email for example.
While the author is wildly overstating things, I do think AI is striking at the heart of the SaaS problem, which is the business model of "pay us $10-100+ per employee per month in perpetuity or we will hold all your data and your company's operations hostage". There is always going to be value in good software, but it is shitty vendors relying on the lock-in effect that are in danger. And good riddance.
The other issue is valuations - B2B SaaS stocks have never been rooted in reality, and the 100+ P/E ratios were always going to come down to earth at some point.
Agree on the valuations. Most have come down and many have overcorrected imho.
As expensive as some of these software seem in terms of cost per seat, most of the subscription contract rarely exceed a few hundred thousand / year if even $1mm, which is drop in a bucket for many companies. (vs running on-prem servers, having staff to support them)
You'd think Atlassian would be printing money given everybody under the sun is using them, but they only make $5B in annual revenue.
I've worked at fortune 50 companies for a while and custom enterprise software is still alive and well for things that are too business specific to buy off the product for. But they're not going to be in a rush to create their own Workday, Salesforce, Jira, Figma, SAP, etc.
Sure its fun to (vibe) code some internal version for a SaaS, but maintain it month after month? Maintain SLAs, etc? That's not fun.
Vibe coding gives you that dopamine hit of creation, but does the internal dev really want to deal with the care and feeding of the random shitty timesheet app they created?
Do they want to take on the work of integrating random backend systems that timesheet system needs to talk to? Do they want to get called at 3AM when it's down?
Even AI assisted, living year after year with production systems is hard.
> we have to understand the relationships in the real world, the processes involved, and the workflows needed, and representing it in a robust way to create a stable system. AI can’t do that.
That is because AI is living in our world, instead of the opposite where we live in AI's world.
Case in point: maybe the AI hallucinated a class method that never existed in our world yet, but perhaps in the AI led processes and workflows it would be written to better fit into the smooth gradient decent those same top parameters' scores.
I think there may be other factors killing SaaS, particularly data sovereignty.
"According to IDC’s Future Enterprise Resiliency and Spending Survey from June 2025, 45% of all organizations and 56% of “digital natives” cited data sovereignty and potential cloud changes as their greatest concern for 2026."
https://www.veeam.com/blog/saas-data-sovereignty-microsoft-3...
“Killing” is a bit strong, but is there a world where folks just vibe code solutions that they would have bought previously? Absolutely and and I think that world is here now.
I’ve seen many startups recently were it was like “guys I could vibe code your ‘product’ in the afternoon.” Yes someone needs to look after it etc, but the bar on where companies buy vs build is getting much, much higher.
(Insert rant from dev teams about the code sucks, who will maintain it, etc). Yes all valid points, but things are changing regardless of if folks like it or not.
Counterpoint, all your customer's data just got stolen by teenagers in the 3rd world and is available for purchase on the dark web. Was it worth saving $5k a month?
A lot of startups/small businesses are like "with AI we can build more than ever". The problem is so can everyone else and capitalism rewards scarcity not value. The bar for startups and small software business has risen quite substantially. I know we are avoiding buying software now where I work if possible unless we previously committed to it (contracts).
Saas companies will survive for the same reason they do today. The operational overhead of any sufficiently complicated piece of software is too much, even more so if it's vibe coded.
The bus factor is gonna be pretty high if your enterprise relies on an internal tool that some guy at your company vibe coded at some point.
Bus factor would be 0 because even he wont be able to debug it.
This was true pre-AI, but now, the bus factor is actually way lower in any software than it was before:
- Hey Claude, what is the project in XXXXX/ about and how does it work ? What should be improved there ?
Or even better:
$opencode
/init
Wait 20 second, then describe the bug.
AGENTS.md seems to exist not just to save tokens, but also so the Bus has to do overtime Isekaing people before a company goes down.
One problem with centrally produced and distributed software is that a small subset of users demanding certain features results in feature bloat for everyone. Costs for all features are shared by all users.
Probably one way SaaS companies will adapt is to break up their offerings into more modular low cost components. While many customers will end up paying less, the addressable market will probably increase because of the new low cost options.
> Costs for all features are shared by all users.
To a degree but most enterprise focused software usually has differential pricing. Often that pricing isn't public so different companies get different quotes.
The framing of 'vibe coding replaces SaaS' misses the more interesting shift: the value SaaS provided was never really the software — it was workflow automation. Software was just the best delivery mechanism we had.
What's changing is that agents + APIs are becoming a better delivery mechanism for many workflows than a UI you manually operate. A company paying $50k/year for a marketing analytics dashboard doesn't actually want a dashboard — they want answers about what's working. An LLM with API access to their data sources often delivers that faster than navigating someone else's opinionated interface.
The SaaS most at risk isn't infrastructure (Stripe, Twilio) or systems of record (Salesforce, Workday). It's the 'pretty UI on top of data you already own' tier — analytics, reporting, simple automation, basic CRM. That's where the compression happens. The products that survive will be the ones that become the system of record, or that offer value AI genuinely can't replicate (regulatory compliance, deep integrations with legacy systems, etc).
I didn't realize B2B SaaS products were in freefall like his numbers suggest. I'm not convinced customers are leaving to vibe code their own products but I do believe we're seeing a major shift in the market, pushed by the sudden relative ease of coding. There are a lot of B2B SaaS products which are outdated and I wouldn't be surprised if they're supplanted by much faster competition
Yup it's definitely not because _customers_ are coding solutions, but the trend and motivation seems to come from the fact that customers are realizing there's something else possible except being tied into expensive recurring yearly subscriptions.
I was surprised when I saw the numbers from Bloomberg myself as well!
The keyword in "Software as a Service" is not Software; it's the Service.
In the early days, the tagline for Salesforce is "No Software". It's secret recipe is this: your sales team only need a browser and a credit card, to get the service. No software installation needed. Even if you have a genius can code something equivalent, it will never be a "service". That genius is not going to support it, not going to add storage for you, not going to restore an accidentally deleted record for you. That takes an army to deliver. It is a service.
Of course, Marc Benioff kind of shot himself in the foot by trying to get ahead of the AI curve... and gutted their customer service division. If the service is delivered by AI agents, what is the selling point again over other AI agents? They have debased their key strengths and are getting punished for it.
I used to be a big advocate for Salesforce in my organization. And it was really great .. allowing us to deliver new functionality without the usual IT procurement bureaucracy.
Now with cloud maturity and Vibe coders who will get better and cheaper, I think it's possible to replace all the features we use on Salesforce at a fraction of the cost of our Salesforce licensing cost.
counterpoint: why would sales people want to use a different crm each time they job hop every 2-3 years?
There is no evidence presented that internally "vibe coded" products are the reason hubspot et al are struggling right now. If anything, the fact that the divergence from the broader index starts in April of last year (well before the current vibe coding moment got going) is evidence that this is something else.
Vibe coding seems to be the iPhone camera to DSLR moment for programming.
- No professional used an iPhone for years. Most don’t today.
- Professional scoffed at it as a toy
- The toy shifted the balance of volume through everyday enablement of amateurs to a degree that professional were right, but now in a severely lopsided terrain.
The value ends up in the most engaged paradigm, rather than the most perfect one.
I just don't buy it.
Most people who've been in a business SaaS environment know that writing the software is relatively the easy part aside from in very difficult technical domains. The sales cycle + renewals and solution engineering for businesses is the majority of the work, and that's going nowhere.
Great insights Namanyay!
I feel the same way about needing to build platforms that enable companies to build on top. That's why i'm building adventureflow.ai to enable energy companies to build their agentic workflows directly on top of my platform.
The expectations have completely changed now, customers expect more software for less, because it is 5-10x cheaper now or faster to build and there's no changing that. Tools like Opus 4.5 have completely disrupted the software marketplace!
Not sure about that, however agents in low code tools are certainly taking over old school integrations.
Nice, what kind of agents and integrations are you seeing being used?
Platforms like Boomi, Workato, Optimizely Opal,
Wow, the tails on the lowercase letter 't' throughout that article are distracting.
Salesforces market cap today is 180,35B. That, not the change, is the market's judgement of how valuable salesforce is, despite any risk from AI. If salesforce stock drops with a new AI model that doesn't mean that investors think salesforce is worthless. It means a slight risk to their business is getting priced in.
I am kind of hoping that AI will kill the startup grab for money TBH. Too many wannabe CEOs I've met in the past 2 decades have gotten rich thanks to a lucky pitch without a clear path to a viable product. At least 6 of those I know did so at the expense of developers that accepted equity over cash...and the developers wasted a ton of time and 2 even were briefly homeless as a result...and none of them live in California.
Hopefully wannabe senior leadership will try and take advantage of AI without taking advantage of developers, because most of us just want to write code and build something great.
Reminds me of the story of when the Surgeon General (in the US) reported that smoking causes cancer.
People stopped smoking immediately, and cigarette sales tanked. The cigarette companies laughed (with all the phlegm in their throats and lungs) and sales came back 1-2 weeks later.
I suspect in a few months or a year companies with vibe-coded replacements for SaS products will find they need to go back: But, just like how many less people smoke today than in the past, the writing is clearly on the wall. At some point someone will figure out how to replace SaS with AI; it's just going to take a lot longer than many think.
> it's just going to take a lot longer than many think
I'd be very surprised if devs were fully replaced by AI in less than 10 years.
And where are they now (cigarette companies)?
https://straitsresearch.com/report/e-cigarette-market
Altria has 72.2% gross margins. 45% net
Well, that was 1964.
Smoking survived.
At least 2 have 100B market caps.
SaaS dying is mostly nonsense.
Which is easier to vibecode - AI agent or Salesforce?
The fragmentation in the AI agent space will be markedly larger than at the base CRM layer.
Abd the AI agent is replaceable in under a minute but your data in Salesforce isn’t.
I was reading through the article and waiting for the key info to drop, but nope. It never did. It seemed like marketing fluff. If anything, vibe coding may eliminate some of the B2C SaaSes, but not B2B. If you think an enterprise is going to vibe code a B2B offering that they pay millions for, you're out of your mind.
Here's my general mantra regarding AI: NEVER take suggestions about AI from people who have a vested interest in it. CEOs of companies that train and offer LLMs, Authors of Books about LLMs and AI in general, etc.
This may come off as an unpopular opinion, but this is how I felt after listening to Steve Yegge recently. He has a new book about Vibe coding and he goes on in the interview/podcast to say that the best programmers he knows in the world (the ones better than him and maybe even the top world class programmers), would be equivalent to those of interns in an year, if they don't start vibe coding or use AI. I respect the guy, but damn, this is just peak delusion. He didn't even say it as a hyperbole, he meant it.
According to popular CEOs of companies training LLMs, 2024 was supposed to be the year that would eliminate the need for Junior and mid-level engineers. 2025 happened. Now, we are in 2026.
So yeah, I'm never taking advice about AI from these people ever again.
> Here's my general mantra regarding AI: NEVER take suggestions about AI from people who have a vested interest in it
I get where you're coming from, but let's say you're talking to a HVAC installer, and he recommends you a system to get - I'm sure there's financial self-interest on his part, but I do like to think that he knows quite a bit about what he does, and believes what he's selling is genuinely good stuff (and has reason to), even if he oversells it a bit.
The analogy can work if you're not looking for an HVAC at all and the HVAC guy is instead approaching you, unprompted, to explain that you need to buy this new system. Because if you don't, your business will become uncompetitive and fail.
True. That's the case with almost any commodity in life. That's why I was specific about AI.
The difference is, in other sectors, there's no fear-mongering. If you don't use their HVAC, it's fine. Your job isn't getting replaced. The air you breathe in your home isn't going to be fully polluted. You have other options.
With AI though, there's no middle ground. You either use their tool and become extremely successful (so much that you don't know what to do with that much success) or you're out of a job and become obsolete in like the next 3 seconds.
Are there real documented cases of a company replacing their SaS with a vibe-coded version?
Like I can see how a very small company could replace a portion of an overkill and underutilized SaS platform.
I don’t see how a larger more complex business could replace their SAP or ADP with a vibecoded version.
These stories are all very similar in where the author knows some CEO of an obscure company who told them they had an engineer reverse engineer and vibecode some obscure SaS solution and saved them $50K.
Customers don't want to pay for rolodex + 8000-data-point-visulization + integrated-automatic-contact-form-filling + assisted-real-time-closest-contact-scanning + 15 new-features-months + Annual-UI-rewrites + All-that-amazing-businesses-functionality-for-only-$199/usr/mo.
They want AI to vibecode a rolodex. And just use that. For 30 years if needed. 2000 LOC and a one time $20 cost.
The cancer of SaaS cannot die fast enough.
Any competent programmer can write 2000 lines in a few days or less. If the SaaS could be replaced by that no AI would be needed.
With a new agentic-lashup tearing across the internet every week, pointing the way to "gradient descent" software development, any purchasing manager worth their salt is going to ask some serious questions about their enormous SaaS bill before committing to another expensive long term contract. It follows that valuations must decline. Even if only because risks to moats have increased, but also because it makes sense to negotiate hard on pricing when there's fear in your counterparty.
Preposterous. Have you ever worked for a company as a programmer or for that matter as a manager? They don't just replace products ad hoc. There's an enormous amount of due diligence that goes into any new software product - making sure it fits the company, that it's secure, that it works properly... I recently worked at a small startup who spent on sales force @ $100,000 a year. I said you know what we could do this ourselves and you know what they said as every company I've ever said that to says? "We don't want to support it. We need to cover our ass. Everybody knows how to use this"
I'm not one to sell generative AI short at this point, but this seems at odds with the longer-term trend towards more centralized, off-the-shelf solutions, like Shopify, Salesforce, Squarespace, over the "bespoke," in-house alternatives that many companies developed in previous decades. Perhaps AI is making the TCO of "rolling your own" so low that it makes sense to go back to that over SaaS?
AI, as do most things, help the big players get bigger. If someone is automating small parts of the b2b layer they get dropped, but it’s harder to drop an automation that companies are used to. I don’t see how AI is changing that, companies spent a lot of time and money to set up the automation because it’s needed and because they can write a potential replacement cheaply doesn’t mean they are going to rip away something that works and is reliable.
Are B2B sales actually impacted or is the stock market just randomly predicting AI will impact B2B and selling off?
Since when does stock price / valuation have to match actual business realities?
I would assume one major thing here is that many orgs only need a small subset of functionality from what most products provide. Many times, that small subset of functionality is only "good enough" in and of itself, but the org is paying the premium for the entire suite of whatever it is. This makes realizing that an LLM can get them to MVP and beyond much easier.
Charging hundreds of thousands if not millions per year for very basic functionality is what is "killing" b2b SaaS.
There is also the benefit of being able to use a single database (and hence schema) across multiple "apps". In many cases the complexity arises from the fact that all these apps have their own databases.
Well it definitely killed mine so I can't say this is not true
> Well it definitely killed mine so I can't say this is not true
I feel like there's an interesting story in there.
I'm sorry to hear that ... if not too painful, would you mind sharing more (so others can learn).
Oh no...
I predict the fallout from this is companies being nickel & dimed to death by a million smaller subscriptions (rather than just cutting a huge check to Workday, ServiceNow, SAP, Oracle or similar). There is such a glut of AI ISV startups that are filling highly specific niches, and some are quite good, but they're all usually in the $10-50/mo/user. Gets to be big numbers pretty quickly in a large enterprise.
There will be an exiting explosion of internal apps and tools and then it will die down as companies get back to business. All those tools and apps will turn into legacy apps and they will eventually try to migrate data off them into some saas platform because its not core to business.
Saas will have to drop prices to be competitive so fat margins will go away which will probably affect margins for AWS etc.
Sure, vibe coding has impacted user's expectations. They know you can ship a new update easier and faster than before - and you actually can.
But, not sure which successful SaaS companies just stopped shipping any updates to the product, never talked to their customers and never added any new features to win over major new accounts - and still managed to survive and thrive?
And the author actually confirms this:
> AI isn’t killing B2B SaaS. It’s killing B2B SaaS that refuses to evolve.
> Sure, vibe coding has impacted user's expectations. They know you can ship a new update easier and faster than before - and you actually can.
Can you though? With major bugs? We've been getting more and more crashes, downtime, issues etc lately and a lot of it has had to do with vibe coding.
The whole point of these B2B SaaS is meant to be quality.
i.e. it's set users' expectations but in the wrong way.
> They know you can ship a new update easier and faster than before - and you actually can.
And all of those updates are just AI features.
>They know you can ship a new update easier and faster than before - and you actually can.
How's that going for Microsoft?
https://www.windowscentral.com/microsoft/windows-11/2025-has...
It's this generation's "build vs buy." I imagine it will play out the same way, like a revolving door. Customers churn because they can "build it themselves," then a year later when they're sick of maintaining a mess of code for some internal system instead of delivering value to their own customers, they come back. A blip.
I can see three forms of competition here:
- A company vibe codes their own app to replace a SaaS. Great when they only wanted a small chunk of the functionality. - Startups benefitting from AI coding are copying mature SaaS companies and competing on price. - Mature SaaS companies are branching out into each others domains. Notion is doing email. Canva is doing an office suite.
Or maybe there is look at true value proposition of the B2B SaaS products. It is not big spend per user, but it does add up eventually. And then savings start to look like big numbers. Big enough for some manager to justify action. This might lead cutting some seats just on cost basis.
here's the secret saas can vibe code features too on top of their paid well developed and secured api. they can get off their ass and vibe code a mcp wrapper, so user can use the ai tooling they pay for to interact with their saas. and they'd be called visionary hero of the agentic revolution.
but they don't want to. and they will be replaced, as it's good and well.
Some founders are realizing this, we're helping a lot of B2B SaaS achieve exactly this with our whitelabelled solution.
well then, happy first billion, where I send a resume?
Maybe the type of SaaS that's akin to stock media (photos, video, music). Just hard enough to do from scratch, but not important enough that it needs to be exceptional in it's field. I've made some money off software like that, and it was nice, but I always knew it couldn't last. Better developers took most of it from me years ago.
Anybody who says this doesn't understand build vs buy, and why companies buy in the first place, or they'll selling AI.
Bingo, the OP is selling AI, and wrote multiple blog posts to promote his tool, this is just fear induced sales pitch.
there is no saas downturn caused by AI. wall street is just starting to say hang on a minute, why is this SaaS stock trading at a price to earnings ratio of 300?
then the sell-off is attributed to AI because it is far easier to say to shareholders hey we know our company lost half its value but thats actually a good thing because we need to pivot to AI and we're going to spend all our free cash flow on AI software and our stock should totally be trading at 300x earnings again in a few weeks. if you can last another few months as CEO and the fed cuts rates you'll be able to ride it out
of course, the tide is going out on a few dogs. I don't think adobe will become dominant again
you see the same trend with mass-layoffs being blamed on AI. easy way to sell bad news to the shareholders
in 2026, AI and JE are the two reasons for absolutely everything
Something notable for SaaS which this article doesn't mention is that in some cases the reason to buy rather than make yourself is due to needing to handle a bunch of different regulations which LLMs don't threaten (barring businesses which would rather have lawsuits than pay for a SaaS).
The real story isn't that some enterprise mega corp is going to vibe-code their own Workday.
The real story is that SOME startups made up of one person (or small number of engineers) will do it, and create pricing pressures against Workday, or DocuSign, or other B2B SaaS.
But if you are a mega corp, spending 0.1% of your CapEx on SaaS subscriptions, do you really want to switch to products made by some no name one person startup? You might save 0.05% of your CapEx, but if something didn’t workout, your whole business will be screwed.
To your point, I think there are 3 main categories:
1. Too big to fail (SalesForce, ServiceNow, ServiceTitan, Shopify). They’re targeting megacorps’ core business operations. Switching costs are too high. They will survive,
2. B2B non-core (PagerDuty, Vanta, Monday, Atlassian). They’re going to have stiff competition and most here will fail or merge/consolidate. They have the most to lose because they’re non-core to a business’s success and pricing pressures will cause many of them will be easily vibecoded with enough time. The large TAM here will attract hundreds of competitors each.
3. Consumer SaaS (Notion, Canva, Grammarly, Dribbble). They're good as dead and can be buried.
We will have to go through the stage of disillusionment of what AI is and understanding of what it is not. There is too much FOMO and too many stories driven by the heavy-AI-invested parties today to see thing clearly.
It is obvious.
A middle 100-500 heads firm don't need enterprise level SaaS, a vibe coded website will suit them better.
Fundamentally, those workflow/orchestration SaaS needs to answer the question why people should pay you premium while only getting 80% where they want to be.
For the most part, you can replicate any B2B SaaS product in a spreadsheet. The same reasons why spreadsheets didn't kill B2B SaaS apply to "in house vibe coded SaaS replacements." The original in house apps are (and continue to be) spreadsheets.
> build once, sell the same thing again ad infinitum, and don’t suffer any marginal costs on more sales.
Unless you consider customer acquisition cost. Not considering cost of sales is one of the big mistakes software developer entrepreneurs make.
I think people here need to accept that software is becoming electricity, you get charged when you use it and by how much. You don't pay for a box shaped electricity or purple color electricity, it is just electricity.
The reason for divergence is actually much simpler. NASDAQ 100 includes data center builders, Morgan Stanley software index doesn't. Stock market is going down across the board if you exclude data center construction.
How corporate incentives are aligned will also define the trajectory. The person who is going to take the call whether to go for vibe coded tool or external vendor has to have enough incentive to put this neck on the line.
Imagine this, you are VP of finance. You know you can get a nice tax calculator built quickly using vibe coding, but will you put your neck on the line and say, let's replace the existing vendor and use my vibe coded tool. You might fired if you send a wrong tax report to your auditor.
Let's take another example - VP of sales wants performance report and visuazliation of the sales team. He has 200 BDRs. The daily sales standup depends on this report, team gets yelled at or praised basis this. Now, will this VP be willing to put his neck on the line and say - let's use my vibe coded report and discard the existing SaaS. Even if such a report feels trivial, it is vital for functioning the sales team and hence, it needs to be reliable.
I think vibe coding will work at prototype level - the trust gap is very huge right now to even consider it for internal tools.
And, until vibe coded tools are stress tested enough this trust gap will not be fulfilled. Think about this, why some of the biggest companies in the world still run on softwares built in 2000s.
It kills low hanging fruit SaaS that was always just some minor piece of functionality wrapped in a subscription model usually based on 99% open source and 1% actual contribution.
Sounds like a lot of products will be in trouble if AI becomes more advanced with producing secure code with maintenance processes to keep evaluating code on an ongoing basis
Remember when businesses ran on cobbled together access databases and vb? It was easier than building something ny prompting an llm.I made a good living just rewriting those things for them when they fell apart.
Can't wait for the "AI Is supercharging SAAS" article when the stocks go up, and another "SAAS IS DEAD" when they go down again
This feels like it started out being written by a human
but around the point "2. Security, authentication, and robustness" the LLM took over and finished it...
This was the same hype around NoCode a few years ago. Thing is people for software as a service and internal teams dont want to do the service part. A common thread among all of the vibe coded stuff I hear is that nobody talks about the next requirement which was handled. Frankly UIs are learnable and after a few tries everybody gets used to it. The extra polish is totally not worth it. Eventually every SaaS on the non-critical business path gets ripped out with one of the platform players such as SAP, SalesForce etc which are infinitely customizable. Salesforce even has its own language in which customers write their apps.
The system of record bit is quite correct and imo the only durable advantage. But that doesnt explain why Klaviyo shoyld worry. In fact marketing workflows are some of the most important systems of record directly tied to business earnings.
The assumtpion that in SaaS you build once and everybody uses it is false. There are always customizations or features that need to be built for big contracts. Its the small players that are okay with out of the box SaaS since they lack the budget to pay for a customization. Ironically, these teams will get hurt the most should they choose to go down the vibe code everything path. Here infra capex is far lower than payroll and owning too much software (vibe coded or not) will simply steal time from business development.
Honestly, the market just panicked and caused a temporary correction thats all. Then we all got busy and wrote a bunch of thought leadership crap on top.
In reality AI is the best thing to happen to SaaS companies since it reduces RnD time and expenses, allows even small players to bid for large contracts without overloading existing dev capacity and also makes it possible to put devs in front of customers since now there's no need to sit down and code. AI is also the best thing to happen to engineering since it now allows for product management to be folded into the existing craft.
Be a System of Record, not just a Wrapper™ is excellent advice.
Thank you! I hope you enjoyed the little ™ at the end as well.
AI isn't killing B2B SaaS. It's killing the service economy. Perhaps, the correct term, technically, is just shrinking it to very very small fraction.
Previously on HN:
https://news.ycombinator.com/item?id=46268452
Maybe things will finally go full circle and people/companies will restart self-hosting their infrastructure instead of farming out everything.
I wouldn't see it positive that we just need to rethink and offer platforms. As this platforms already exist Azure, AWS, GCP
The trick is to build stuff that is hard to vibe code
Yes, that is not the random SaaS product, possibly not any SaaS software at all.
Its not that hard.
I am building a desktop app that deploys and manages high availability postgres instances on VPS right now..
The AI is constantly failing at helping me because its about generating and managing remote configuration that is very fragile if something is missing.
Build infra heavy saas. Somehow can get through. Llm will get better only, and people start copying every sucessfull platforms.
I don't think AI is killing B2B SaaS so much as companies are finally reckoning with the immense costs of SaaS in a markably different environment than when SaaS exploded in popularity, and AI offers an off-ramp to some. Let's break it down camp-by-camp to show you what I mean:
1) The must-haves. These are your email and communication systems, the things you absolutely have to have up and available at all times to do business. While previously self-hosted (Exchange/Sendmail, IRC/Skype/Jabber, CallManager/UCS), the immense costs and complexities of managing systems ultimately built on archaic, monolithic, and otherwise difficult-to-scale technologies meant that SaaS made sense from a cost and a technical perspective. Let's face it, the fact nobody really hosts their own e-mail anymore in favor of Proton/Microsoft/Google/et al shows that self-hosting is the exception here, not the norm - and they're not going anywhere regardless of how bad the economy gets. These are the "housing stock" of business, and there's plenty of cheap stock always available to setup shop in without the need for technical talent.
2) The juggernauts. The, "we can do this ourselves, but the pain will be so immense that we really don't want to". This is the area where early SaaS solutions cornered and exploded in growth (O365, ServiceNow, Google Workspaces), because managing these things yourself - while feasible, even preferable - was just too cheap to pass up having someone else wrangle on your behalf with a reasonable SLA, freeing up your tech talent for all the other stuff. The problem is that once-focused products have become huge behemoths of complex features that most customers neither need nor use on a regular basis, at least after the initial pricey integration. Add in the ease of maintainability and scalability brought by containers or microservices, along with the availability and reliability of public cloud infrastructure, and suddenly there's more businesses re-evaluating their relationships with these products in the face of ever-rising prices. With AI tooling making data exfiltration and integration easier than ever from these sorts of products, I expect businesses to start consolidating into a single source of truth instead of using dozens of specific product suites - but not toppling any outright.
3) The nice-to-haves. The Figmas, the HubSpots, the myriad of niche-function-high-cost SaaS companies out there making up the bulk of the market. Those whose products lack self-hosted alternatives risk having vibe-coded alternatives be "good enough" for an Enterprise looking to slash costs without regard to long-term support or quality; those who compete with self-hosted alternatives are almost certainly cooked, to varying degrees. If AI tooling can crank out content similar in quality to Figma and the company has tech talent to refine it for long-term use, why bother paying for Figma? If AI tooling can crank out a CRUD UI for users that just executes standard REST API calls behind the scenes, then why bother paying for fancy frontends? While it's technically interesting and novel at how these startups solved issues around scaling, or databases, or tenancy, the reality is that a lot of these niche products or services could be handled in-house with a container manager, a Postgres instance, and a mid-level IT person to poke it when things go pear-shaped. The higher per-seat prices of a lot of these services make them ripe for replacement in businesses comfortable with leveraging AI for building solutions, and I expect that number to grow as the tools become more widely available and IT-friendly in terms of security.
Ultimately, the core promise of SaaS to business customers was all the functionality with none of the costs of self-hosting support. Nowadays, many of them have evolved into solutions that are more expensive than self-hosted options, and businesses that have shifted IT into public clouds or container-based systems have realized they can do the same thing for less themselves, at the cost of some UI/UX niceties in the process. Now that we (IT) can crank out integrations with local LLMs with little to no cost, we're finally able to merge datasets into singular pools or services - and I'm not talking about Snowflake or its "big data" ilk so much as just finally getting everything into Salesforce or ServiceNow without having to bring in consultants.
The must-haves and many of the juggernauts will remain - for now. It's the niche players that need to watch their moats.
Anyone can learn to cook, and the barrier to entry is low. There's no shortage of restaurants though.
There's no shortage of restaurants that go out of business. Even big name brands have issues with location turnover.
That's a great point. The restaurant business is one of the worst you could possibly go into, with razor thin margins and astronomical failure rates. If those are the future economics of SaaS (accustomed to 70-80% gross margins), than you ought to cash out now while you still can.
SaaS’s competitive advantage is not tech but distribution.
Just because the stock market dips, and a bunch of media outlets ascribe this to AI doesn’t mean that AI ‘caused’ the dip.
If people really think non-tech businesses will start running their own software organizations and maintain all these tools themselves is an idiotic assumption at best.
The “building” of software has never been and will never be the bottleneck.
Slight tangent: what’s the deal with the weird ligatures on that page in the headings?
I'm the biggest typography nerd and love ligatures. Can't tell if the majority likes them or dislikes them lol
People have been debating what "real" development is for as long as there have been computers. "That's not real software development, you're not even controlling which registers you use!" "How can you say that's real code when you aren't even managing your own memory!" "That doesn't look like C, must not be code!" and on and on.
At the level of the old adage about whether the horse-drawn buggy-makers are in the buggy business or the transportation business, it's all telling the computer what to do in the context of providing a customized tool that you or others might use. So in this context, a customized Excel spreadsheet counts. And so does a vibe-coded app.
And of course, wringing our hands about what it looks like now totally ignores the fact that it's not going to be like this for more than a year or two at most.
How long until a user can reasonably say to Claude or similar, "I need Bob here to track production at my factory. Lay out a set of tools to do that, and make sure they're layered with help and tutorials so Bob can learn on the job because he doesn't know anything. Don't let him make any mistakes."
That's probably not coming next year, but certainly it's not ten years away.
Maybe the new SaaS is to build vibe coding (aka conversation) into whatever you’re offering.
thats what theyre all doing. its gimmick and wont really fix the underlying issue.
The problem is never building, it's maintenance. SaaS isn't going anywhere.
Having worked in enterprise B2B SaaS for a long time, almost every feature I built could have been a simple spreadsheet or some emails. So I'm highly skeptical AI is going to change anything.
Enterprise sales basically works like this: A non-technical sales team aggressively promises everything to win a deal to a non-technical procurement or exec team. When the deal is won, the SaaS sales team tells engineers "go build this" regardless of how stupid it is. And the customer tells their employees "you now have to use this SaaS" regardless of whether it makes sense.
no. High interest rates and a cautionary view of future economic growth are killing B2B SaaS. Money is no longer free, and so there is a bigger push for cost-cutting rather than growing your buisness with free money.
AI is killing this. Millennials are killing that. Gen Z certainly must be killing another thing. And Yarn? It was killing NPM. This nonsense type of title really was made for a world where nuance doesn’t exist.
B2B SaaS is projected to grow over the next decade, not shrink. Just use the LLMs and you’ll be reminded of the value provided by the company selling non-core but important tools for your business.
A link shortener is such an easy thing to code, it's essentially one database table with a redirect. To add to that, there are many open source libraries to implement link shortening, including analytics and stuff. Even then Bitly and Rebrandly have customers (from their website) like Toyota, Cisco, Oracle, Monday.com, New York Times, etc.
Are these companies unable to build a link shortener? It's also so easy to migrate off shortener service. If they can and still choose to use these shortening services, there must be other reason. And that reason is that they simply don't want to. This has nothing to do with AI.
I run a software company and one of the reasons customers say they want to migrate from their homegrown spreadsheet is because the guy who built it left. A freaking spreadsheet!
Such blog posts and probably many comments here are the perfect answer to "Tell me you don't run a real business without telling me you don't run a real business"
Regarding your last comment, majority of the people here are costal with FAT paychecks slinging code for VCs. It’s a totally different universe than running a Saas. That said, still a valuable forum.
Until Claude Code comes with indemnity insurance for HIPAA / GDPR / etc… B2B SaaS is here to stay. You want me to convince my auditor that the vibe-coded in house software handles PII correctly?
Making the audit someone else’s problem is 90% of the ‘buy’ value in ‘build vs buy’
Spot on. You could argue that most companies buying B2B SaaS could almost always build a clone internally but they need someone to assume SLA and liability.
I know this is petty but I stopped reading when I saw the “c-t” ligature in the article headings. Obnoxious and pretentious.
I'm the biggest typography nerd and I'll fight to death in the defense of ligatures! Bring them back
I love ligatures and typography too but not these.
Jellyfish is a Jolly Fish, also invertebrate
I wouldn't say that AI is killing B2B SaaS, let's analyze the situation: AI is shifting the boundaries of the Build VS Buy decision.
If software is cheaper... building it seems a much better option but... ...the fact that software is cheaper means that SaaS companies will be able to be more competitive with price, offering more features, integrating them much better with the newest agentic tools and frameworks that are getting released.
Sure, the market will adjust, some will be pushed away, others will find businesses that weren't possible before... but we're far away (I hope) from the AGI revolution, don't forget to see this crysis as an opportunity too.
That’s cool. I’m building a mob programmer.
the procurement bypass was the best part. now watching ai devs ship faster than our salesforce admin could configure flows
Vibe coded SaaS is a SaaTA. Throw away.
I've worked in SaaS for most of my career, only recently working at a big corp who is largely the buyer and user of SaaS tools to meet their objectives. From the perspective of the corp business buyer, they want something that works for their needs and they want to buy something instead of build it because the support costs are gnarly. They already have engineers dedicated to the tools they've purchased. Much better to put the risk on someone else they can yell at. And the permissions and access to these tools, reports, data, is usually its own special problem to manage. Building a lot of one-off tools is going to just give IT a huge headache and they will push the org to buy before vibe coding a solution.
if you're a software company and all your clients are in tech...you're gonna have a bad time. godspeed.
Look, software is not going away even though everybody thinks they're a developer now. Do you think companies are going to replace Microsoft Windows, of which there are a billion installs, or Salesforce, Crowdstrike, Quickbooks etc, with some Vibe coded AI slop an intern "coded"?
When enterprises/businesses in general upgrade any software in the company it takes years sometimes... There is also Vendor lock in, you can't just swap things with vibe-coded slop, and trust me your manager will never want to do that either because his butt will be on the line.
I disliked how SaaS CEO's were decrying the death of engineers. Their coordinated layoffs over the past years or so was excruciating to watch and experience. Their language was aggressive and inflammatory.
Although the article may also be hyperbolic, I'm not going to comment on reasons why it might be. Instead, I will agree, and think SaaS companies stock performance this year will be proof. Sure, it might not be the collapse that AI doomers are hoping for, but all the FUD they spread over the past few months to years will signal that they're not insulated from it. They made their cake, now they have to eat it too.
At the end of the day you do not need to replace your B2B SaaS with AI.
You need your B2B SaaS to think you can use AI to replace it though, so said SaaS will keep it's prices reasonable. Otherwise they have you by the balls and will charge you much as humanly possible.
been thinking about this too. the middleware layer is getting decimated first
If that would be true, expect in the next decade a frantic search for seclusive grey beards, those who haven't given up their rituals and ancient languages.
If your workforce is vibing all day, they will have no capacity for maintenance, because it isn't their code. So the maintenance that happens will be slop and more spaghetti. I am not saying cases like that never existed before, but such companies will face a moment of truth sooner or later.
The survival advice here — 'be a system of record,' 'make switching painful with compliance' — is exactly the playbook that makes customers want to leave in the first place. The deeper question is whether vibe-coded replacements will rot fast enough to send people running back, or whether AI gets good enough to maintain them too.
No it isn’t. Writing the code was never the issue with making software, it was designing it.
You can shit out an app with AI, just like you could with Indian workers. But that doesn’t mean it will work properly or that you’ll be able to maintain it.
And most importantly, it only works for code they could steal from GitHub. It has no idea how to replicate sensitive systems which aren’t publically documented, and those are some of the most valuable contracts.
> how they’re potentially losing an $X00,000 account just because the customer can’t use a specific failure reporting workflow in the SaaS. They’re now working with me to build what the customer needs and retain them.
You mean the poor SaaS company actually now has to implement features needed by customers??
Jesus wept.
at last, TrueAnon has arrived at hackernews
Just a single data point, and I‘m not pretending it’s a conclusive one (yet), but I think there is a middle ground between buying a SaaS and vibe coding a replacement: replacing a SaaS with your own solution, using AI coding agents — while actually knowing what you do because creating robust software in-house is already a core competency. No vibe coding needed.
At my company, we build software every day because our business is running a job board.
We always had kind of an impedance mismatch when it comes to creating content pages (think landing pages for marketing).
Yes, we can do this ourselves, but then software engineering resources are in conflict between shipping the next feature and creating landing pages.
So we introduced Webflow. Now marketing could create their content themselves. Did it match our corporate identity? Hopefully. Was it technically sound? Sometimes. Was it fun for software engineers to fix things in Webflow. No.
It kind of worked, but wasn’t exactly ideal.
Meanwhile, software engineering became more and more productive with the advent of AI coding agents, Cursor in our case.
So we tried another approach: giving our content creators Cursor.
But that was brittle, too: Cursor presents an overwhelming complex UI for someone who never used an IDE before, it could do a thousand things while only three are actually needed in this use case, you have to explain git on top of Cursor. It kind of worked, but only kind of.
So we sat down and built https://dx-tooling.org/sitebuilder/
It’s like a hyper-focused „Cursor light“ in the browser, so our content creators can just „chat away“ and create their content pages, with all the guardrails baked into the product. Getting tracking pixel integration etc. right just works. Matching our style guide perfectly just works.
And as a bonus, there is a whole git based storage and versioning workflow underneath, so software engineering can support and test and deploy the results with their preferred tools and methods, but none of this complexity leaks through to the content creators.
We built this ourselves in days, not months, thanks to Cursor, but it’s not vibe-coded — it’s a rock solid application that we will support and improve long-term without headaches: https://github.com/dx-tooling/sitebuilder-webapp
Time will tell.
No.. just.. no. This will be a thing for like 1, maybe 2 years, then people will realise it doesn’t make sense to spend $50K of time per annum to replace a $500/month subscription for a better product.
for profit software is pretty gross tho. it can be made indefinitely complex, and people can make and sell tools to patchwork the complexity together, but then u need more tools to patchwork all the tools together ...
and u end up in aggregators aggregated aggregators type situation where optimal solutions never arise because we don't actually cooperate enough to produce them
ai is fitting into the notion that this is all bullshit ... even if not in the correct way
One point is now you dont have to pay money to 3rd world countries like mine :(, you can manage with fewer resources inhouse. AI will take care of slop work.
Article is AI slop based on a mostly made up premise.
goooood.
“Software is eating the world” and “AI is eating software”
Honestly, I'm surprised by how people are pushing back against this idea. I feel like vibe coding is just in its earliest moments of actual viability, and my mind is totally blown by it, and it strikes me that it's exactly what I've always wished software could be. Plastic, flexible, personalized, effective, responsive, organic.
As an anecdote, I've been vibe coding an accounting system that perfectly matches with my own expectations of accounting software, i.e., it's intimately connected to CSVs, imports and exports from CSVs, but acts as a kind of enrichment and reporting and file association layer. If there was anything like this, any kind of SaaS that I could have and download as software and run on my own computer offline and be able to inspect and trust and version control so they wouldn't add or remove some kind of feature that I wanted down the line, then I would have gone with that.
But now I have essentially my absolute ideal solution, written with a Python backend and Vue and JavaScript frontend, and it's radically improved my ability to maintain accounting for our business account.
And I think there's something really important to point out here, which is that the feeling of lock-in is very seriously reduced when you are Vibe coding your own software, because if you don't like the way that it works or you realize that there's something missing, you can add it pretty painlessly. Like, that's always been a huge challenge with choosing vendors for a SaaS platform, is you think, oh no, well, what if their conceptual model for what I'm trying to do doesn't quite map onto our own internal systems or understanding of what's being done? Well, when you have your own Vibe-coded SaaS, you can just add that information. So there's something incredibly organic about it. I used to work at a startup in Redmond where we built this large internal system to manage a scientific process with lots of machinery and data, and it was incredibly empowering and actually became one of the core values of the business that was able to be licensed to other businesses in the same industry. And it seems like we're just improving that capacity from here.
Now obviously, if Vibe Coding magically were to go away or became much more expensive, then I'd have this legacy piece of software, which I couldn't improve, and that would be a dead end. But my expectation is that the functionality that we have today will only improve. And in several years, the scope of changes that I'll be able to make, the level of professionalism, modularization, maintainability, code quality, will only improve. And so this has me thinking in general that software is kind of undergoing a step change where we're moving into the so-called age of intent beyond the age of the interface. And that's tremendously exciting to me, and I just couldn't be more stoked about it.
[dead]
This immediately lost credibility for me with this quote:
> And vibe coding is fun. Even Bret Taylor, OpenAI’s chair, acknowledges it’s become a legitimate development approach.
Color me shocked! Bret, who directly profits by how his product is perceived, thinks it's legitimate???? /s
And if I understand correctly the author is running a business that helps SaaS companies overcome the risk of using their own vibe-coded solutions.
Good point -- removed for being biased and partial. Thanks for the feedback!
> Good point -- removed for being biased and impartial. Thanks for the feedback!
??? Do you mean biased or do you mean impartial?
"biased" and "impartial" are antonyms. Pick one or the other.
Edited, allow me blame it on my ~12 hour workday today :^)
[dead]
[dead]
[dead]