Influxx bundles dozens of agent CLIs, parallel git worktrees, a notes system, automations, skills, an embedded browser, computer-use, and dictation into one cockpit — and none of that is obvious from a blank window on day one. The tempting fix is a single first-run product tour that walks a new user through everything; we considered that approach and ruled it out, because a tour long enough to cover a product this deep either overwhelms someone in their first five minutes or explains features so far ahead of when they're needed that nobody remembers them by the time they matter. What we shipped instead is three separate onboarding mechanisms, each with one narrow job, all governed by a single rule: never show a user something they've already found.
Why One Tour Can't Teach a Product This Deep
Every part of Influxx is real surface area a new user eventually needs. Task management, code review, workspace and worktree management, the core workbench where agents actually run, the embedded browser, and multi-agent orchestration are the headline areas; underneath them sit automations, skills, notes, computer-use, and dictation. That's not a product you can walk someone through in a single sitting and expect them to retain.
Try to explain all of it up front and you run into one of two failure modes. Either you cover everything and nobody remembers anything past the fourth or fifth card, or you quietly scope the tour down to "the basics" — which in practice means automations, skills, and computer-use never get introduced to anyone at all.
There's a second failure mode that's less obvious than information overload: teaching a feature before it's relevant. Explain the automations panel to someone before they've run a single agent, and you've spent their attention on something they can't use yet and won't remember once they can. Onboarding for a product this deep isn't really a sequencing problem — it's a timing problem. The right explanation delivered at the wrong moment does about as much good as no explanation at all.
Three Mechanisms, Each Doing One Job
Once we accepted that timing was the actual constraint, the shape of the solution followed: an upfront map for orientation, moment-specific guidance for when a feature becomes relevant, and light single-fact nudges for capabilities that don't need a full walkthrough. We call these the Feature Wall, Contextual Tours, and Feature Tips. Keeping them narrow and separate — instead of one system trying to flex across all three jobs — turns out to matter as much as anything we put in the content itself.
The Feature Wall: A Map, Not a Tutorial
The Feature Wall is the first thing a genuinely new user sees: an animated set of cards introducing the major areas of the product, paired with a setup checklist. It covers ground at a high level:
- Task management: where work gets tracked across whatever agents are running against it.
- Code review: reviewing what an agent produced before it lands anywhere.
- Workspace and worktree management: how parallel git worktrees keep multiple agents from colliding on the same branch.
- The core workbench: the sidebar and tab strip where agents actually run.
- The embedded browser: checking a live preview without leaving the cockpit.
- Multi-agent orchestration: running more than one CLI against the same project at once.
The setup checklist sitting next to the cards is the action-oriented counterpart to the map: while the cards explain what exists, the checklist points toward doing the first few things that make the rest of the product make sense. The point of the Feature Wall isn't to teach any of these areas in depth — it's to make sure a new user has a mental map of where things live before they ever need to go looking. Someone who's seen the wall knows Influxx has a worktree manager and an embedded browser even if they don't touch either in their first session. That's enough. When they do need one of those later, they're not discovering it cold; they're remembering where it was.
Contextual Tours: Guidance That Waits for the Right Moment
Contextual Tours solve the timing problem the Feature Wall deliberately leaves alone. Instead of explaining the automations panel on day one, we wait until a user is looking at something automations would actually help with, then point directly at the real, live automations panel in their own UI — not a screenshot, not a help article, the actual element sitting on their actual screen at that moment. The same logic applies to the workspace board: a tour that points at the board only fires once a user's context makes the board relevant, and when it does, it's pointing at the exact instance in front of them, not a generic mock of what a board could look like.
That distinction matters more than it sounds like it should. A static screenshot goes stale the moment the UI changes, and it forces a user to translate between what a help article shows and what they're actually looking at. Pointing at the live element removes that translation step entirely — there's no ambiguity about what "this" refers to, because "this" is highlighted right there.
Feature Tips: The Lightest Touch
Not everything needs a tour. Some capabilities are a single fact away from being useful — a user just needs to know they exist. The universal jump/search palette is the clearest example: nobody needs a guided walkthrough of a search palette. They need one callout, at a moment when jumping between things by hand is getting tedious, telling them the palette exists and roughly what it does. That's what Feature Tips are for: smaller than a Contextual Tour, narrower than the Feature Wall, a single-fact nudge instead of a walkthrough.
"We kept trying to design one onboarding flow that was appropriately deep for every feature, and it doesn't exist. A worktree switcher and a search palette don't deserve the same amount of explanation. Once we stopped trying to force one mechanism to do three different jobs, the rest of this got a lot easier to reason about."
— Sofia Reyes, Head of Product at ETAPX
The Rule That Keeps Three Mechanisms From Becoming Noise
Three onboarding systems running independently is a recipe for redundancy — the Feature Wall mentions the automations panel, a Contextual Tour points at it again a week later, and a Feature Tip chimes in about it a third time. We avoid that with one governing rule: every mechanism checks a local record of what a specific user has already discovered or dismissed before it shows anything. If you've already seen something — whether you completed it, dismissed it partway through, or just found the feature on your own without any help from us — it does not show up again.
That record deliberately never leaves the user's machine. It exists to answer one narrow question, locally — has this person already seen this? — and nothing more. There's no server-side profile of "how this user behaves" being assembled from onboarding activity; there's a local checklist consulted before a tour is allowed to render, full stop. Keeping that record local isn't incidental — it's the decision that makes the rest of this trustworthy.
New Users Get Tours. Everyone Else Gets Left Alone.
Automatic, unprompted tours are restricted to genuinely new users. We don't fire a Contextual Tour at someone who's been running Influxx for six months just because they opened a panel they don't visit often. The reasoning is deliberately conservative: the least surprising, least annoying default for an existing user who already knows their way around is to leave them alone, rather than interrupt an established workflow with a tour for a feature they may already use just fine.
That sounds obvious written down, but it's easy to violate in practice. It's tempting to reason that a user hasn't opened automations in three months, so maybe they forgot it exists, so a gentle reminder would help. We don't do that. Forgetting is not the same as never having discovered something, and treating the two the same way means interrupting exactly the experienced users who most need to be left alone — the ones who opened Influxx to get work done, not to be taught the product again.
"I rolled Influxx out to a team of six in the same week. Two people had never run more than one coding agent at a time and genuinely needed the map. The other four had been using it for months already, and the honest feedback from them was that nothing happened — no tour fired, nothing asked for their attention. That's exactly what I wanted for that half of the team."
— Maya Lindström, staff engineer rolling out Influxx to her team
What We Measure About Onboarding — and the Line We Don't Cross
The local discovery record isn't analytics; it never leaves the machine, so there's nothing to measure from it centrally. Separately, we do collect a small amount of telemetry about the onboarding system itself — how the mechanisms are performing in aggregate, not what any individual is doing — and we're deliberate about keeping it narrow. It amounts to a handful of generic, scoped events: a tour was shown, a tour was completed versus dismissed. We cap that set deliberately, and we treat the cap as a permanent design constraint rather than a temporary limit waiting for a bigger budget later.
We also hold a standing rule against treating "was it seen" as success on its own. Any new tour we add needs a real reason tied to an actual downstream product outcome — fewer people getting stuck at a specific step, faster time to a working setup, something concrete — not just a raw impression count. A tour that gets shown a lot and dismissed a lot isn't proof of anything except bad timing.
The Hard Line: What Never Appears in Telemetry
One rule in this system has no exceptions: prompts, file paths, URLs, hostnames, and branch names are banned from ever appearing in any telemetry the onboarding system produces. Not behind a debug flag, not in an internal diagnostic build — banned, period. Onboarding telemetry exists to answer "did this tour get seen and did it help," and none of those answers require knowing what a user typed, what they named a branch, or what host they're connected to.
"If an onboarding event needs a file path or a prompt to make sense, that's a sign the event is scoped wrong, not a reason to carve out an exception. We designed the schema so that the question 'did this tour get seen and finished' never has to touch anything that looks like user content, even for debugging."
— Ryan Chase, Security Engineer at ETAPX
Frequently Asked Questions
Why not just use one onboarding tour like most apps do?
Because Influxx is deep enough that a single tour forces a bad tradeoff. Cover everything and a new user retains almost none of it; scope it down to "the basics" and features like automations, skills, and computer-use never get introduced at all. Splitting onboarding into a first-run map, moment-specific guidance, and light nudges lets us teach each part of the product at the moment it's actually useful to know, instead of trying to cram all of it into day one.
What's the actual difference between a Feature Wall, a Contextual Tour, and a Feature Tip?
The Feature Wall is a one-time, first-run map of the major areas of the product, shown alongside a setup checklist. Contextual Tours are narrower and arrive later: they show up when a specific feature becomes relevant and point at the real, live UI element rather than a screenshot or help article. Feature Tips are the lightest of the three — a single callout about one capability, like the universal jump/search palette, dropped in at a fitting moment instead of a full walkthrough.
Will Influxx keep showing me a tour I've already dismissed?
No. Every one of these mechanisms checks a local record of what you've already discovered or dismissed before it shows anything, and once something has been seen it doesn't resurface. The explicit design goal is that nothing in onboarding repeats itself for a given user, regardless of whether you finished it, closed it early, or found the feature on your own.
Does any of this onboarding activity get uploaded or tracked against my account?
The record of what you've personally seen or dismissed stays on your machine. It exists purely to answer "has this person already seen this" and nothing else gets built from it. Separately, we collect a small, capped set of generic events about the onboarding system as a whole, like whether a tour was shown or completed versus dismissed — and prompts, file paths, URLs, hostnames, and branch names are never allowed to appear in that telemetry, with no exception for debugging.
Why don't I see tours anymore now that I've been using Influxx for a while?
That's intentional. Automatic, unprompted tours only fire for genuinely new users. Past that window, the default is to leave you alone rather than interrupt a workflow you've already built with a tour for something you may already use fine. We'd rather under-explain to an experienced user than nag one.
What stops the team from adding more and more tours over time?
A standing rule: any new tour needs a real reason tied to an actual downstream product outcome, not just "people should probably know about this." An impression count or a completion rate isn't success by itself — if a tour gets shown constantly and dismissed constantly, that's a sign it's timed wrong, not a metric worth celebrating.
None of this is really about tours. It's about accepting that a product with this much surface area can't be taught in one sitting without either overwhelming someone or teaching them things long before they're ready to use them. A map on day one, guidance that waits for the moment it's relevant, light nudges for everything in between, and a strict local-only memory that keeps any of it from repeating — that's the whole system. The bar for adding to it stays simple: it has to make the product easier to find your way around, not just easier to claim we introduced something.
