Live data from Hacker News

AI is killing B2B SaaS

nmn.gl

721–730 of 752 posts

Re: AI is killing B2B SaaS

#721

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…

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.

Re: AI is killing B2B SaaS

#722
post #665

Earlier quoted context omitted.

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?

Re: AI is killing B2B SaaS

#723
post #668

Earlier quoted context omitted.

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.

Re: AI is killing B2B SaaS

#724

Earlier quoted context omitted.

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

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

Re: AI is killing B2B SaaS

#725

Earlier quoted context omitted.

"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 y…

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

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.

Re: AI is killing B2B SaaS

#726

Earlier quoted context omitted.

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.

Re: AI is killing B2B SaaS

#727
post #623

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…

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

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

Re: AI is killing B2B SaaS

#728
post #724

Earlier quoted context omitted.

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

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

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.

Re: AI is killing B2B SaaS

#729
post #665

Earlier quoted context omitted.

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.

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.

Re: AI is killing B2B SaaS

#730
post #724

Earlier quoted context omitted.

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

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

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.

Post reply on HN