Lokalise Flow — Onboarding / Setup

Flow, or as we called in the beginning - Autopilot, was pure PLG product that was never supposed to have any form of sales driven by humans cold-calling. In that case our priority was very simple, from the very beginning - ensuring our future users immediately understand value, need to spend very little time to get to it, and find the experience delightful. I mentioned already in the previous post about how was Lokalise Flow created that the beginnings were quite hectic, and then it never slowed down. One of the first real projects within that product, however, was onboarding and setup experience.

Our goal was to have an AI-driven product that’s ready to use within minutes, without any prior knowledge in localisation. You know, one of these magical one-button experiences where the user clicks on a big button and everything happens in the background for them.

Ultimately, we were focused on short time to value, immediately understanding product value and quickly reaching the wow-moment for ensured conversion. No-code automated solution in minutes after installation, and after that the user would only see our logo on the invoice, while smoking cigar on their yacht because internationalisation brought them success they never dreamed of. So, in short, perfect PLG onboarding.

There were, however, a few interesting problems to be solved:

Since setup experience was such a complex piece of user journey, it was one of the most scrutinised pieces we built.

At first, I created 4 revisions by myself using only feedback from key engineering and product stakeholders who were connected to the project from the beginning. While 4 revisions might sound like a lot, it took probably around 2-3 weeks, along with prototypes, guerilla research and interim changes.

By revisions I mean “I’m starting pretty much from zero”. Reasoning for such quick and big changes was that as I was working on system logic from user perspective, other stakeholders were performing discovery on tech, business, potential, USP etc., creating new knowledge and assumptions with every passing day we collected more data, feedback and ideas. With that much constant change and potential even if the 3rd version already made a ton of sense, the 4th iteration addressed even more potential.

1. The activation number flatters us. The thing that actually mattered was “first useful output,” and that was hours behind activation. PLG activation usually means “the user took the action.” For an AI product where the value lives 12–18 hours after that action, the gap between activation and outcome is a chasm. We hit 97.4% activation. The graph for “users who came back when the AI was done” was much messier. If you ship AI, instrument the moment the user actually sees value — not the moment they finished setup.
2. Compounding delay was a design problem masquerading as an engineering one. Every post-install change to glossary or style guide restarted processing — and we found users edit settings in clusters during onboarding because that’s when they’re learning the model. The naive flow let them sit through three full reprocessing rounds before output. We batched setting changes into a single commit-and-process gate. The fix was a UI pattern, not a backend change.
3. Set expectations before the user gives you the input — not while they’re waiting. A loading spinner doesn’t fix “I thought this would be seconds.” The story has to start at the install screen: this takes hours, here’s why, here’s what’s happening, here’s when we’ll come find you. Once users have done the math themselves, the wait stops feeling broken.
4. Four resets in three weeks isn’t chaos — it’s the cheap iteration window. Each reset cost about two days of design time. Each one removed weeks of engineering risk that a downstream pivot would have cost. Reset early, reset cheaply, and protect the team’s ability to pivot while foundations are still in pixels rather than code.