zlacker

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.

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

>>chasd0+QC
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.

>>chasd0+QC
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.

>>chasd0+QC
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.