zlacker

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.

>>d_watt+(OP)
Exactly, a lot more focus -- and most importantly specific domain knowledge -- allows the end-user to build exactly what they need, fast.

>>d_watt+(OP)
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".

>>d_watt+(OP)
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.

>>bdcrav+j3
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.

>>gritsp+jc
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.

>>gritsp+jc
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.

>>bdcrav+j3
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.

>>elevat+TE
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.

>>d_watt+(OP)
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.

>>fallou+UG
You’re describing Excel.

AI will be used to do “excel better” more than “replace a managed, compliant, feature-rich-carefully-engineered, service”.

>>physic+sU
Bingo; the exact same arguments against regular-coding it in-house apply to vibe-coding it in-house.

>>d_watt+(OP)
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.