Saylify progress update:

I have started on the web app and so far it is going quite well. There is summary, translation, summary of the translation and similar stuff. Everything is cached and wired through queues, because there is a real chance of hitting OpenAI (or AssemblyAI) rate limits. If you try to do everything synchronously, the user will just see errors, which is bad practice. It is better if the user waits a bit but gets a result, than having to press buttons again.

What I am working on right now (in addition to web app improvements):

1. Integrating Typesense for text search.

I came to this in a funny way: while I am developing, I naturally test a lot and upload dozens of voice messages into the system. Among test voices there are personal ones too. I realised I remember what the conversation was about, but I cannot find that voice in the list, even with filters. That is exactly the kind of problem users will 100% run into.

2. Dropping RPC over RabbitMQ.

Some queues ended up with overly complex dependency chains. I decided it will be much simpler to turn this into microservices over HTTP.

3. In parallel, I am experimenting with a desktop app.

Pain points I do not yet know how to solve (or do not want to solve before launch):

1. iOS/Android app.

2. OpenAI API latency. Example: a text of about 45,000 tokens. For GPT-5.1 completions the response time sometimes exceeds 15 seconds. Ideally, I should stream the output and show it to the user immediately (like ChatGPT does when it is 'typing'), but that is a lot of extra work. I will probably have to live with this at launch.

3. Telegram Bot API sendChatAction is a terrible method: the action stays active for a maximum of 5 seconds, after which you have to send it again if the reply is still not ready. Objectively, that is a very silly limit.