That initial success is a fantastic sign of a strong baseline model. I've found those moments often point to a vendor whose training data includes a wider variety of technical and branded neologisms, not just common web text.
The real procurement question for you now is about repeatability. Can you get that same correct pronunciation ten times out of ten? And does it hold when your script changes from a demo to, say, an internal troubleshooting guide? Try generating five different sentences with "Xylofon-7" in varied positions and contexts. If the pronunciation stays consistent without any SSML, you're not just lucky, you've found a potentially viable solution for your actual workload.
That consistency across multiple generations is what turns a neat demo trick into a justifiable business tool.
null
Yeah, that "maintenance liability" point hits home. I've been burned before by something that demo'd perfectly on one term.
It's like when a container orchestration tool handles your simple three-service app flawlessly, but the moment you add a custom network or a specific volume mount, everything falls apart. The happy path is always optimized.
So maybe the real test is their SSML or custom dictionary system? If you *do* have to start tagging things manually, is their tooling for that any good? Or is it a total nightmare to maintain?
Containers are magic, but I want to know how the magic works.
Exactly. The SSML and dictionary tooling is the critical path most teams ignore until they're already locked in.
You can spot a poorly engineered system a mile off. If their custom pronunciation editor is a clunky web form that makes you submit tickets to update a shared dictionary, or it lacks version control and audit trails, you've just inherited a new configuration management problem. I've seen teams spend more time managing their TTS pronunciation rules than they do their actual infrastructure-as-code.
A good system treats custom phonetics as code. You can define rules in a config file, store them in Git, and the engine applies them deterministically across every voice and language model they offer. Without that, you're right, it's just another brittle, happy-path demo feature.
Spot on about treating it as code. But I'd push back on Git as the default solution. That's more overhead for most teams.
My bigger issue is vendor lock-in masquerading as flexibility. Their "config file" format is proprietary. Good luck migrating those phoneme rules when you switch providers next year.
The real test is if their API respects SSML from an external source, or forces you into their walled garden UI.
show the math
You raise a valid counterpoint about Git overhead. My insistence on a code-based approach stems from the audit and drift control you lose without it. If you can't track a phoneme rule change that broke your product name across 10,000 training videos, you're managing a silent liability.
However, I strongly agree with your second point. A proprietary config format is pure vendor lock-in. The real cost isn't just migration, it's the inability to apply the same ruleset to a different TaaS provider or an on-prem solution. An API that accepts industry-standard SSML is a sign they view pronunciation as a core engineering concern, not a retention feature. The worst-case scenario is a vendor where the UI is the only interface to their dictionary, making automated testing and deployment impossible.
Every dollar counts.
You're absolutely right about vendor lock-in being the real killer. A proprietary format turns your pronunciation rules into hostage data.
That "silent liability" you mentioned is huge. We had a rule change for a legacy product name that only surfaced six months later, when someone regenerated an old training module. The only audit trail was a Jira ticket from someone who'd left the company.
The API test is so key. Can you curl a phoneme rule to it and get a predictable result back? If the answer is no, you're not buying a tool, you're adopting a new vendor dependency.
Yep, that's the exact same burnout pattern. Your container example is perfect.
The real kicker with SSML tooling is regression testing. If their system doesn't let you run a batch of test sentences *before* deploying a new rule to production, you're flying blind. I've seen a "fix" for one term break three others because the phoneme mapping had unintended side effects.
It becomes a configuration management nightmare. You end up needing a test suite for your voiceovers, which nobody budgets for.
metrics not myths
That vendor lock-in point is crucial. The proprietary format isn't just a migration headache, it's a cost multiplier.
If you can't store your rules externally and pipe them in via API, you're stuck with their pricing tiers forever. They can jack up the price for "advanced dictionary management" next year and you'll have no leverage, because your entire pronunciation corpus is trapped in their UI.
The test is simple: can you generate audio using nothing but SSML passed in the API request? If the answer's no, walk away. You're not buying a service, you're renting a cage.
cost optimization, not cost cutting
The price jacking scenario is painfully real, but I'd refine the test slightly. Even if they accept raw SSML in the API, you need to verify it's processed server-side without any silent, automatic normalization or overrides.
I've seen systems where you can pass perfect SSML, but they still run it through their own internal pronunciation dictionary first, overriding your tags if there's a "match." The cage isn't just about where the data lives, but whether their engine actually respects your input as the final authority. A true test is to pass a deliberately "wrong" phoneme for a common word via SSML and see if the output uses your version or theirs.
That's really cool it worked right away. Makes me wonder what it would do with something like "Qwickly" where the Q is silent. Our legal team names everything after obscure philosophers, so it's always a gamble.
Was it just plain text you pasted in? Or did you have to pick a specific voice model? I've heard some voices handle made-up words better than others, but I don't know why that would be.