When a product is built from the trendiest technologies and the original team has left, every change becomes expensive: few people can find their way around the system, and even a simple change is hard to test. NaturalTTS is an AI-based SaaS that turns text into audio and speech into text. It runs on subscriptions through a Stripe integration, the back end is written in NodeJS on Amazon Web Services with an Amazon Pipelines setup, and the front end is React. The project came to us from another team, and the main challenge was not a feature but the complexity of the architecture itself.
Natural TTS
What the product is and what you see first
For a user it all starts with the form on the home page: paste text, choose a language and voice, listen to the result. The home page promises more than 61 natural voices, 6 popular languages and free MP3 downloads.
The voices section lets people listen to samples and choose a sound before paying.
The plans in a September 2024 screenshot are built around a character limit: a free plan with 5,000 characters and 6 languages, a personal plan at $9.99 a month with 200,000 characters and 15 languages, and a commercial plan at $79.99 a month with 1,000,000 characters and all languages. Paid plans include SSML markup, file history and uploading text from a .txt file, and reading scanned documents is advertised for commercial use.
Speech to text: the transcription dashboard
The second half of the screenshots shows a speech recognition dashboard, which appears on screen under the Rythmex brand. Sign-in is by email, Google or Facebook, followed by a workspace: drag-and-drop upload (mp3, m4a, mp4, ogg, flac, webm, wav), a balance in minutes and a transcription history.
Monetisation in the dashboard is based on minutes: a 7-day trial with 5 free minutes, Premium at $12 a month with two free hours and $5 per extra hour, a team of up to 3 accounts, and Enterprise at an individual price. Annual billing gives a 25% discount.
The affiliate programme gives each user a referral link to the home page or the sign-up page and shows a 5% conversion rate, visits, earnings and withdrawals. The menu also has a separate API section for connecting the service to external systems.
Where our work began
We did not join at the very start: the key architecture decisions had already been made. Because of requests for fast scaling and autoscaling (automatically adding server resources without shutting the server down), a fully cloud-based development model had been chosen. It has its advantages, but for this project the drawbacks probably outweighed them, especially as the previous team chose not to continue.
The key success: we quickly got to grips with a number of specialised technologies in which we had no prior experience, even in theory, and took the project into development.
Why complex architecture became a business risk
The first problem is simple: when a project is packed with complex technologies, the pool of people able to work on it shrinks sharply. The second: after a while, even the project's author may struggle with the complexity or simply tire of it.
The project merged the skills of several specialists:
- AWS DevOps for cloud computing and servers. The infrastructure is cleverly designed and, once understood, even convenient, but it is tangled and undocumented. Few programmers combine strong coding with deep experience of Amazon services.
- React developer with TypeScript. They find it easiest to debug the app, but only the front end: almost no front-end developer could install the back end locally for testing in this project.
- NodeJS developer with TypeScript. There are plenty of them, but here they need to know the specifics of Amazon services, and a mid-level back-end developer spends the first week unable to pass a simple set of parameters that takes a minute in a simpler architecture.
All these skills overlapped heavily through Amazon services, so the entry threshold was very high. A developer without AWS experience cannot see how to test a change or run step-by-step debugging without separate specialised software, which also requires experience. TypeScript pays off when a stable team runs a project from start to finish, but when the team changes it becomes one more barrier.
How we take over a project from another team
- A code and infrastructure audit: which cloud services are used, how build and deployment work, where configuration lives.
- A system map and documentation, without which the next developer will again spend weeks getting started. We explain why this pays off in our piece on documentation.
- A test environment where a change is checked without risk to live users.
- A simplification plan: what to keep and what to move to a simpler setup. The approach is described in our piece on deployment and infrastructure.
The honest boundary: the scope of work on someone else's project cannot be named before an audit, so the estimate comes after the code and infrastructure review.
Where else it applies
Speech synthesis and recognition are needed by voice agents and call centres, online learning for course voiceovers, and services that transcribe meetings and interviews. How voice works over the phone is shown in the AI secretary case.
If you have inherited a complex system from another team or are planning a voice product, book a free consultation with an architect. Afterwards you will receive a price and timeline estimate broken down by stage.
