Honestly, you're not miles off. Though with developers, it was actually more the "gotcha" variety of "It sucks ass".
We would have a senior dev on the dealing-making-or-breaking call and he would say something like, "Wait -- sorry, do you support <specific thing that our system doesn't have>?" We would say honestly that we don't have that yet. Then the senior dev would say, "Ooohh.... sorry... yeah... we need (per-message arbitrary data storage | support for on-prem | real-time analytics | per-messsage privacy controls | etc.)." We eventually had to face the reality that one of two things must be true:
1) The market is just too fragmented such that there cannot exist one product that serves it
2) The devs involved really, really don't want to give a product like this a chance because they actually want to build fun features like this themselves and they're (rightfully) skeptical that some random startup can do it better
As I sit here now, I have some confidence that it's 75% #2 and 25% #1. Anyway, the basic shape of the sales calls went a lot like what you're saying.
I've been there for the addition of, initial heavy investment in, slow decline of, and eventual removal of Storybook like 6 times across as many companies. The only places where I've seen it work are places that are so steeped in process that they move at a snail's pace. It's not unlike automated UI tests. Someone gets a bee in their bonnet to add it. They do a ton of work to get it off the ground. It looks really good and seems really valuable. And then it becomes a maintenance hazard that falls out of sync with the codebase within the week. Sorry Storybook, but never.
I'm an American software dev that has been in London for ~11 years now after working in Silicon Valley for years. The lower dev salaries are definitely a thing here. But I personally don't see much evidence of US jobs coming here to get filled on the cheap. Certainly not from A-list/exciting companies any way. Maybe it's a growing trend, but it's not something that many people here are taking note of.
It's for verifying the correctness of subtitle files. The whole subtitling world is very, very messy. There are dozens of file formats, many of which have many variants and versions. You might have a file that works in one place, but when you upload it somewhere else, it doesn't work.
Trying to figure out why means reading dozens of pages on dozens of sites trying to understand that 'Oh SRT formatting doesn't support that particular styling format'. It's a mess. Also dumb stuff like a subtitle that has zero length or a subtitle that has a end time before its start time. Trying to understand whats broken in a subtitle file is a PITA.
This is the first tool I've seen trying to make it easy to figure out if a subtitle file is broken.
We would have a senior dev on the dealing-making-or-breaking call and he would say something like, "Wait -- sorry, do you support <specific thing that our system doesn't have>?" We would say honestly that we don't have that yet. Then the senior dev would say, "Ooohh.... sorry... yeah... we need (per-message arbitrary data storage | support for on-prem | real-time analytics | per-messsage privacy controls | etc.)." We eventually had to face the reality that one of two things must be true:
1) The market is just too fragmented such that there cannot exist one product that serves it
2) The devs involved really, really don't want to give a product like this a chance because they actually want to build fun features like this themselves and they're (rightfully) skeptical that some random startup can do it better
As I sit here now, I have some confidence that it's 75% #2 and 25% #1. Anyway, the basic shape of the sales calls went a lot like what you're saying.