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

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.

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.

This vibe-coding-will-replace-SaaS insanity is the new crypto-will-replace-fiat-money insanity.

& 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

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)

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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?

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.

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.

Reminded me of big balls and DOGE. Didn’t we vibe code our entire government by now?

Building a project is very different than building a product as a billing engine.

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.

Your profit margin is my opportunity.

sorry, what do you mean?

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

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