zlacker

[parent] [thread] 9 comments
1. epolan+(OP)[view] [source] 2026-02-04 18:08:11
> 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.

replies(1): >>zdragn+45
2. zdragn+45[view] [source] 2026-02-04 18:30:00
>>epolan+(OP)
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.

replies(2): >>bbatha+e6 >>epolan+Hf
◧◩
3. bbatha+e6[view] [source] [discussion] 2026-02-04 18:33:54
>>zdragn+45
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.
replies(2): >>re-thc+i7 >>chasd0+NQ
◧◩◪
4. re-thc+i7[view] [source] [discussion] 2026-02-04 18:38:05
>>bbatha+e6
> 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.

◧◩
5. epolan+Hf[view] [source] [discussion] 2026-02-04 19:14:43
>>zdragn+45
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.

replies(1): >>chasd0+xS
◧◩◪
6. chasd0+NQ[view] [source] [discussion] 2026-02-04 22:13:13
>>bbatha+e6
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.
◧◩◪
7. chasd0+xS[view] [source] [discussion] 2026-02-04 22:21:54
>>epolan+Hf
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".
replies(3): >>zdragn+dY >>epolan+l11 >>zipy12+Mg1
◧◩◪◨
8. zdragn+dY[view] [source] [discussion] 2026-02-04 22:53:27
>>chasd0+xS
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.

◧◩◪◨
9. epolan+l11[view] [source] [discussion] 2026-02-04 23:10:32
>>chasd0+xS
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.

◧◩◪◨
10. zipy12+Mg1[view] [source] [discussion] 2026-02-05 00:54:38
>>chasd0+xS
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.
[go to top]