Project Phoenix is live: What we changed, why we changed it, and what broke first

We launched Project Phoenix this week. It went live with bugs. That was a deliberate call, and I want to explain it.

This is not a product announcement. It is a debrief — what we changed, the specific decisions behind each change, what broke within the first 24 hours, and what we are watching now. If you use MachineTranslation.com regularly, you will notice the tool feels different. This is why.

What is Project Phoenix?

Project Phoenix is the internal name for the largest product update I have shipped on MachineTranslation.com this year. It changes how and when translation triggers, how the interface responds while you are still typing, how the SMART consensus mechanism surfaces its results, and how the product-led growth layer reaches new users.

The name is internal. The changes are visible to every user from the moment they open the tool.

At its core, Phoenix addresses a problem I have been tracking for a while: the gap between how fast users type and how fast the tool responds. That gap was creating friction that had nothing to do with translation quality. Users would write quickly, hit a silent pause, and wait (sometimes five to ten seconds) with no visual indication that anything was happening. The tool felt slower than it was. Phoenix addresses that at the logic level, not just at the surface.

Why I pushed it live with known bugs

On June 17, I asked Shashank (our Tech lead) to push Project Phoenix to live with two known issues still open: minor language-switch alignment inconsistencies, and a display bug showing "zero words" in the source text under certain browser conditions.

My reasoning was simple. Neither issue blocked the core use case. The primary flow (type text, trigger translation, receive SMART consensus output) was working. The Product-Led Growth feature was active on English desktop. The PLG disappearing-on-URL-reaccess bug we had identified earlier in the week had already been resolved. What remained were cosmetic problems, not functional ones.

There is a real difference between a bug that breaks the primary use case and a bug that creates visual noise. Holding a release for the second type is how tools fall behind. I made the call to ship, log the remaining issues, and fix forward. That is what we did.

The decision that mattered most: The 2-word trigger

Of everything inside the Phoenix release, the change to the translation trigger logic has the biggest impact on how the AI translation tool feels to use — and it came directly out of a real problem Ofer (our CEO) surfaced in our June 18 post-launch review.

The previous logic required either a pause of 1.3 seconds or five words before the tool would send a translation request. For users who type slowly or pause to think, that worked fine. For users who type quickly and continuously (which, in our data, is a significant proportion), it created a frustrating pattern. They would write a full sentence, wait, and then watch the tool catch up. Or worse: auto-detect would fail silently, requiring a manual language selection before anything happened at all.

Ofer cited Google's data in that meeting: every additional millisecond of load time correlates with measurable drops in user engagement and conversion. A five-to-ten-second silent wait is not a milliseconds problem. It is an experience that tells the user the tool is not working.

The new logic triggers translation as soon as two words are entered in the source text, regardless of pause. Subsequent translations refresh every two seconds while new text is being added. Auto-detect fires on the same two-word threshold. Shashank clarified in the meeting that the development work had already been moving toward this approach, so the conversation was less a pivot than a confirmation.

That screenshot shows what the 2-word trigger produces: five AI models ran simultaneously on a four-word phrase, reached 100% agreement on the Filipino Tagalog output, and delivered that result in 751 milliseconds. The individual outputs from ChatGPT, Mistral AI, Claude, Qwen, and DeepSeek are visible beneath, each with a quality score. The SMART result (the translation the majority of models agreed on) is what surfaces at the top.

This is what AI translation consensus means in practice: not one model making a call, but multiple models independently translating the same text and being required to agree. The 2-word trigger means that process starts before the user has finished their thought, instead of after they have finished waiting.

What product-led growth looks like inside an AI translation platform

Product-led growth went live in English across all locale versions of MachineTranslation.com as part of the Phoenix release. Localization into other languages follows.

In the context of an AI translation platform, PLG is not a marketing strategy. It is a product design decision: the tool itself becomes the mechanism through which a user understands what they are getting and decides whether to upgrade. They do not need a feature comparison page. They translate a phrase, see the SMART panel, see which models ran and how fast they agreed, and understand the proposition directly from the experience.

The "Your translation, wrapped" panel in the screenshot above is part of that layer. It surfaces (in real time, after every translation) which AI models ran, what percentage agreed, the consensus speed in milliseconds, and where models diverged. It makes a back-end process that used to be invisible into something a user can read and evaluate.

The bug we identified before launch (PLG disappearing when a user re-accessed a unique URL) was resolved before Phoenix went live. 

What broke on day one

I will be specific, because vague post-launch summaries are not useful.

Auto-detect failure on single-word entries. When a user entered only one word, auto-detect did not fire. This was identified and resolved. The new threshold is two words, which aligns the auto-detect logic with the translation trigger and means the failure mode is addressed at the design level rather than patched around.

Text box focus loss. Under certain conditions the source text box lost focus during active typing, disrupting input. This is under active investigation.

File upload failures. Users uploading files for translation encountered errors in specific scenarios. This is in the development queue.

Language-switch visual misalignment. Minor display inconsistency in the language selector under certain locale combinations. Non-blocking, being addressed in the next push.

AI revision tool non-functional at launch. Clicking "Improve now" triggered no action. This is a known issue the development team is currently fixing, separate from the core translation flow.

The triage logic was straightforward: anything that blocked the primary use case was treated as urgent. Anything cosmetic or affecting secondary features was logged and queued. The core flow was working at launch. That was the bar we shipped against.

What I am watching next

Response time data. I asked Bryan (our Data lead) to start collecting detailed metrics on typing patterns and response times under the new flow. Prior data was built around translate-button usage, which is no longer how the tool works. We are effectively starting fresh on behavioral data, and that data will drive the next round of trigger logic decisions.

Server-side rendering. Engineers are working on SSR improvements to ensure new pages built under the Phoenix structure are properly crawlable. This matters for how the tool's indexed pages perform in search over the next few months.

The honest version of what comes next after any launch is this: we watch what users actually do, not what we expected them to do. The 2-word trigger made complete sense in a meeting. What matters is whether it makes sense when thousands of users type into the box across dozens of language pairs and device types.

I will report back when we have enough data to say.