[eloisant]

I know you had commercial arguments when working at Zendesk.

Still: when you code your own solution, you don't need to build an integration with every single platform you can think of. Just those you use.

And sometimes, especially now with AI, coding your own solution exactly tailored to your needs can be simpler than configuring a complex product designed to match as many use case as possible.

[macspoofing]

>And sometimes, especially now with AI, coding your own solution exactly tailored to your needs can be simpler than configuring a complex product designed to match as many use case as possible.

Coding a solution was never a problem. Supporting and maintaining it was. I can guarantee you an in-house ticketing system will be more expensive than Zendesk for every small and medium company.

[Ethee]

I feel like this is the biggest disconnect I'm seeing with the new AI trend. Supporting something is infinitely times easier than building it and typically requires a different group of people, but the simple fact that I can build a thing that works, by myself, in 48 hours with very little opportunity cost is insane and feels so understated here.

What would it have taken to get this off the ground before? A ton of meetings with stakeholders to decide if this is even a good idea. Meetings with other developers who touch systems you might understand but have never used before yourself. And WAAAY longer than 48 hours to get an MVP prototype off the ground.

It's a little ironic to me that we constantly shit on how broken something underneath the hood is here despite the fact that it works, while in the same breath complaining about the enshitification of products that have been garbage long before AI came along. I'm not going to disagree that vibecoding spits out a lot of garbage, but we're already swimming in garbage so what does it matter?

[macspoofing]

>Supporting something is infinitely times easier than building it

No it isn't. That is patently untrue. I've had to deal with in-house solutions many times in my careers. Inevitably what happens is the original author leaves the company or just doesn't want to support it and whatever tool they built atrophies and we end up moving to an off-the-shelf product with a lot of pain.

I'm dealing with a homegrown project management tool like that now. Originally built 10-15 years ago - it now has a feature request list a mile long. Finance is annoyed they can't pull the kinds of reports they want, and that it doesn't integrate into our CRM. IT is annoyed it doesn't support SAML and they have to manage backups. The tool is running on whatever the hot stack was at that time - so it is horribly out of date now ... but the original people that wrote it have long since left the company. The engineers don't want to touch it. Product doesn't want engineers to work on it because it takes away from our core business.

There are commercial off-the-shelf tools that provide the same feature-set (+more) and don't tie up my engineers, but now the thing is engrained into workflow and moving off of it is a major project spamming multiple departments (including engineering).