How Ownership of the Full Onboarding Funnel Drove a 12x Activation Improvement at Galileo AI

Galileo is an AI evaluation and observability platform for GenAI applications. It gives teams tooling to measure, monitor, and improve LLM-powered systems in production — covering evaluation metrics, hallucination detection, and runtime monitoring. 

When they opened its platform to the public for the first time, it faced a problem that no amount of engineering talent could solve in isolation: users were signing up, landing on the home page, and leaving. Within weeks of launch, it was clear the activation rate still had significant room to grow.

The starting point: No onboarding, no activation 

Before the platform opened to the public, access was invitation-only. New users were walked through the product in dedicated onboarding calls. It worked — because it had to. There was no self-serve flow, and there didn't need to be.

When the platform launched its 2.0 version to the public, that model broke immediately. Users created accounts, landed on the home page, and dropped off. There was no flow to guide them, no signal to orient them, no clear path to the product's core value. 

Our embedded team into Galileo's Developer Onboarding pod inherited exactly this situation. Non-existing onboarding and low activation. Over the following 6 months, the numbers increased 12x. The task wasn't to improve something — it was to build it from the ground up, and then keep improving it until the numbers moved.

The method: Small increments, run often 

The approach wasn't to redesign everything at once. It was to move in small increments, frequently, and let the data determine what stayed.

One example was the decision to introduce email verification to eliminate duplicate users who were not engaging with the application, helping filter the target audience more effectively and ensuring activation data reflected genuine users. 

The cycle was: watch user session recordings, identify friction points, form a hypothesis, run a test, measure the result, and start again. This loop ran several times a week across multiple fronts simultaneously — progress bars, CTAs, step ordering, email verification, Playground simplification for first time users, and more. 

What made it work wasn't any single change. It was the discipline of not guessing. As our team put it:

Session recordings and funnel analytics turned subjective instinct into actionable signal. Only changes that demonstrably moved the needle survived. The ones that didn't — including ideas that seemed logically sound — were discarded. 

That last part turned out to be one of the hardest aspects of the work. 

The hardest part: Killing your own good work 

In a fast iteration cycle, you ship a lot. You also cut a lot. 

Our team identified this as the most difficult ongoing challenge: the discipline of removing something you built — something you believed in — after the experiment shows it didn't work. Sometimes the logical change doesn't convert. Sometimes the thing you were convinced would improve activation, doesn't. 

The willingness to discard it anyway, learn from why it failed, and move on is what kept the cycle productive. And over time, understanding what didn't work became one of the most reliable signals for understanding what did.

Full-stack ownership as a competitive advantage 

The onboarding work spanned frontend, backend, and analytics — and the decision to own all three wasn't planned from the start. It emerged from necessity. 

Early in the engagement, some improvements required backend changes. Waiting for support from another team would have introduced multi-week delays. For an experimentation cycle running several times a week, that lag would have been fatal to the momentum.

The solution was to absorb the backend work directly. A potential two-week dependency became two additional days of focused effort. The cycle continued uninterrupted.

This is what full-stack ownership looks like in practice: someone sees what needs to be done, has the range to do it, and does it. No handoff, no delay, no ticket. It's a decision that's only available to a team with the range to make it — and the context to know when it matters. 

On the analytics side, the team built PostHog deeply into the onboarding workflow — designing experiments, tracking activation funnels, building dashboards, and managing feature flags. The work became a visible example of PostHog best practices within the organization, referenced in broader team discussions as a model for how to instrument and run experiments effectively. 

Our team reflected on what fragmented ownership would have cost:

What the onboarding looks like today 

The current experience is the result of months of layered iteration. Users move through a structured, step by-step flow: they set up an organization, identify their primary goal with the platform, choose their AI provider, install the SDK, configure their environment, and reach working code all before they ever navigate to the main product. 

Pre-populated sample projects across Playground, LogStreams, and Experiments give new users immediate hands-on context. The Playground was redesigned specifically to reduce friction for first-time users encountering the interface cold.

The result is that users who previously dropped off at the home page now reliably reach the product's core value. Activation improved 12x. 

The most meaningful metric wasn't the number itself. It was watching users navigate a complex flow without dropping off.

What this engagement demonstrates 

For any company evaluating whether to bring on an augmentation team, the Galileo onboarding engagement illustrates something specific: the difference between contractors who execute defined tasks and who operate as core team members. 

The 12x activation improvement didn't come from a single brilliant idea. It came from ownership of the problem end-to-end — building the analytics infrastructure to understand user behavior, working on frontend changes based on evidence, extending into backend work when speed required it, and maintaining the discipline to keep iterating through failures as well as wins.

That kind of contribution requires context, continuity, and genuine ownership. It's what Eversynced is built to provide.