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…
AI is killing B2B SaaS
721–730 of 752 posts
Re: AI is killing B2B SaaS
#722Earlier 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.
Re: AI is killing B2B SaaS
#723Earlier 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.
Re: AI is killing B2B SaaS
#724Earlier 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…
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
#725Earlier 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…
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
#726Earlier 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.
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
#727It'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…
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
#728Earlier 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…
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
#729Earlier 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.
Re: AI is killing B2B SaaS
#730Earlier 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…
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.