Valha works inside the AI sessions your team already runs and turns the work worth keeping into a page people act on, the context an agent needs to continue, and a Blueprint for the next case.
Claude
CodexChatGPTYour best work ends in chat.
You solve it inside the assistant you already use, and the answer stays in a session nobody else can open.
CLAUDE86 MESSAGES · 12 QUERIES · AUTO SCROLLING ↓Audit the account-creation funnel for the last 30 days. Compare Google SSO, email + password, verification, and recovery. Keep user details private.
Mapped the account-creation paths and source systems
I’ll rebuild the funnel from raw events instead of trusting the aggregate signup rate. That lets us see whether the loss happens before authentication, during verification, or after the account exists.
Plan:
Start from Metabase card #1842, then verify every step against prod_analytics.events_* in BigQuery.
Joined the business funnel to raw warehouse events
First pass: 124,800 signup page views split into two primary paths. Google receives 72,410 starts. Email + password receives 52,390 starts.
The 41-point gap is real enough to investigate, but not clean enough to explain yet.
Resolve anonymous IDs after OAuth redirects. Remove internal users, automated tests, bots, duplicated callbacks, and clock drift.
Rebuilt identity and removed invalid sessions
I joined pre-auth device IDs to server-side account creation and deduplicated retries inside a 30-minute window. That excludes 3,842 sessionsfrom the comparison.
Google remains stable at 84% completion. Email + password lands at 43%, so the difference is not an identity artifact.
Break the password path into form submit, verification delivery, verification click, and final account creation.
Reconstructed the password branch event by event
From 52,390 starts, 39,180 people submit valid credentials. The email provider reports 38,460 verification emails delivered.
The dominant loss sits between delivery and a successful verification return.
Confirm that against the email delivery logs. Quantify users who received the message but never verified.
Matched delivery logs to verification returns
15,520 users received the verification email but never completed verification. That is a 40% loss after confirmed deliveryand the largest controllable leak in the signup funnel.
Delivery failures matter, but they are not the main constraint. The return path, link context, and reminder behavior deserve the next intervention.
Password resets use the same email infrastructure. Check them, but do not mix recovery into signup conversion.
Separated password recovery from account creation
Recovery shows 11,430 requests, 11,120 delivered messages, and 6,280 completed resets. It confirms that returning from email is difficult, but it remains a separate funnel with a different user intent.
Stress-test the leak by device, region, and verification delay. Did reminder copy materially fix it?
Stress-tested the leak across enterprise cohorts
Completion improved from 55.8% to 61.7% after reminder copy changed. The same delivery-to-verification drop remains the largest loss across desktop, mobile, North America, and Europe.
The evidence supports prioritizing verification. It does not yet prove which UI or email change will recover the loss, so the next move should be instrumented.
Give me the decision, the caveat, and everything the next engineer needs to reproduce this analysis.
Condensed the investigation into a reproducible decision
Key finding: Password verification is the signup funnel’s largest controllable leak.
Decision: fix the verification return path before redesigning Google SSO. Keep recovery separate, preserve the query jobs, and revalidate the result after the intervention.
The answer stays in a private chat.
No page keeps the answer, the evidence, or how it was done.
The next person rebuilds the context from zero.
These eight are real pages, not screenshots. A data report, a client proposal, an annual report, an incident review, a board update, a travel plan, a campaign wrap-up, a site decision. Open one and check the evidence under it.
Each one is a Valha page, rendered by the product. The companies, people, and figures in them are invented; the places and the photographs are real.
Example 1 of 8.
EXAMPLE01 / 08
You finish the work in the assistant you already use.
Each section can carry its own provenance: the question that was asked, what was counted, what was excluded, and where the data came from.
A page can keep the repeatable part: the sequence, the checks, the caveats, with the private inputs stripped out.
What your team opens. A composed page with the conclusion at the top, in a form somebody outside the work can act on.
Enough published context that a person or an assistant can pick the work up later: queries, definitions, sources, caveats.
The approach on its own, separated from the case that produced it, so the next run does not start from nothing.
When a piece of work is worth doing again, keep it as a Blueprint: the sequence, the queries, the checks. Your assistant searches the library and loads one before it starts.
A Blueprint belongs to the workspace that made it. Nothing is shared outside it, and the case that produced it stays behind.
Every revision is kept, so a Blueprint that changes can still be read the way it ran last quarter.
A Blueprint records when it was loaded and when someone reports it worked, so the library reflects practice rather than intentions.
valha runs as a hosted MCP server. Point the tool you already work in at it, sign in once, and every session after that can publish and recall.
Available on every plan. Free is limited to one custom connector, and on Team or Enterprise an owner adds it for the organization.
In settings, under Customize, choose Connectors. The Add button sits at the top right.
Two fields: the name shown in your connector list, and the remote MCP server URL. Advanced settings stay empty.
Authorize once in your browser. valha answers from the next message on.
https://valha.link/mcpWith workspace access, an assistant searches published pages and fetches their evidence. Valha receives only the tool requests, arguments, and content you authorize it to read or change.
We are building this next: surfacing the relevant Blueprint, the conflicting decision, or the duplicated effort while the work is happening, once that can be done without guessing. It is not in the product today.
Valha gives teams a new kind of company document. Each page captures useful AI work so it can be read, checked, and reused. Together, those pages make AI's contribution tangible across the organization.
Published pages show the decisions, analyses, reports, and Blueprints people chose to preserve, not the private sessions behind them.
Pages and validated Blueprints show which useful work can support the next project instead of disappearing with the chat.
Gaps in shared, reusable work can start an organization-level conversation about blockers and support without scoring individuals.
Valha does not monitor private conversations or rank employees. Any organization-level view would stay private and use only the work people deliberately publish.
Team is the first paid plan. Enterprise is quoted.
For one person publishing their own work
Per person
For teams that need the work to travel
Per user / month, billed annually. €19 monthly.
For organizations with security and access requirements
Quote based
A page exists because its author validated it. Private work is never promoted by default.
Assistants reach Valha through an OAuth-protected remote MCP endpoint, scoped to the workspaces you allow.
When a page runs code, it runs in a network-isolated sandbox. It can read the data published to that section and reach nothing else.
Everything Valha does is downstream of one promise, and every feature is built so the promise keeps holding.
What is real today, what is not, and where the boundary sits.
No. Valha receives only the tool requests, arguments, and content you authorize it to read or change. The assistant keeps the rest of your conversation private, and nothing is published without your instruction.
Connect a compatible assistant, create and update pages, publish links, work inside accessible workspaces, and search or fetch published pages through Valha's remote MCP tools.
No. Valha does one thing: it turns finished AI work into a page you can send. Everything else your team writes stays where it already lives.
A method you decided was worth keeping: the steps, the queries, the checks, and the caveats, without the case that produced it. Your assistant can search the library and load one before it starts a similar task.
No. The author decides what deserves to be retained. A page can preserve the repeatable steps, queries, checks, and caveats, but private work does not become company knowledge automatically.
With access to the workspace, yes: it searches published pages and fetches the evidence under them through Valha's remote MCP tools. It cannot reach a private session, an unpublished draft, or a workspace it was not given.
It works today with Claude, Codex, ChatGPT, and Gemini. Valha connects over OAuth-protected remote MCP rather than a provider-specific import, so any assistant that supports remote MCP connectors can publish.
A minute for the account. Then add one remote MCP connector, https://valha.link/mcp, and sign in through it. Where you paste that URL differs by assistant. After that you publish from the chat you were already in.
Then that assistant cannot publish to Valha yet, and there is no workaround worth pretending otherwise. Connector policy usually sits with whoever administers your AI subscription. Reading and sharing published pages needs no connector at all.
Only inside a network-isolated sandbox. It can see the data published to that section so it can render it, but it cannot send that data anywhere or reach anything else. Most pages never need it.
Something you would otherwise have to explain again in a meeting, or retype for one teammate. A report, an incident review, a decision, an analysis.
The listed price is the launch price: €15 per user per month billed annually, or €19 billed monthly. Team is being installed with founder-led pilots first, so what is early about it is the onboarding, not the pricing.
Bring one AI-assisted workflow your team already runs. In 30 minutes we show how its useful outcome becomes a controlled page, then review access, provenance, and what Valha can do today. It is a product evaluation, not a commitment.
It opens with the brief already written: read Valha as a CTO would, say where it creates value, and name the risks worth checking first.
Connect an assistant and publish the next thing you finish. One message, and your team has the page.
Free, no card
