Skip to main contentSkip to main content
Where working software leaks money

Studio Notes

Where working software leaks money

Established products rarely fail from bad marketing; they lose users in the technical gaps between sign-up, payment, and first use.

Justin Tsugranes4 min read

In a standard PostHog project with active traffic, 14 percent of people who enter an email address leave the app the moment they are asked to check their inbox for a confirmation link.

That drop is not a messaging problem. Nobody leaves a sign-up screen because they suddenly changed their mind about needing the software; they leave because switching tabs on a phone to open a mail client interrupts momentum, triggers context switching, and often loses the session state entirely when the browser reloads in the background.

Where the drops actually happen

When a product is fresh off the bench, everyone watches the front door. You notice if the landing page takes three seconds to load or if the payment form looks weird on mobile. But once a product has active users and real traffic, the biggest leaks migrate deeper into the application, right where analytics tools stop tracking and web software takes over.

The most common point of failure in a working app is a broken handoff between systems. A prospective customer fills out a registration form on a desktop browser, receives a verification email, clicks the link on their iPhone, and lands on a generic login screen that has no record of what they were doing five seconds earlier. The authentication link worked cleanly on the server, but the user state vanished in the hop between devices. Out of ten people who hit that wall, six close the tab and never come back.

Another quiet place to bleed active users is the workspace invitation flow. A manager pays for a multi-user account through Stripe, types in four colleague email addresses, and assumes the setup is done. If those invitation emails land in a spam folder, or if accepting an invite requires a brand-new user to set up multi-factor authentication before showing them any workspace content, those invitees stall out. The account owner checks back two weeks later, notices nobody else has logged in, and cancels the subscription.

None of these drop-offs show up as bugs in an error tracking tool like Sentry. The code runs without throwing errors, the database records the user, and the server returns a 200 OK status. The product fails silently at the seams.

What tracking actually costs

Fixing these gaps starts with visibility, but off-the-shelf pageview trackers miss the details that matter. Google Analytics tells you how many hits hit /dashboard. It will not tell you that 8 percent of new accounts hang on a blank screen because a secondary background job failed to populate their default project template.

To see what is happening, you have to instrument state transitions directly in the codebase. That means firing explicit telemetry when a webhook delays workspace setup, when an auth token expires mid-checkout, or when an invited user drops off at a permission prompt.

This telemetry requires careful maintenance. Event schemas drift as features evolve. One engineer logs account_created on the frontend, while another logs user_signup_complete from the backend API. Six months later, your funnel report shows a massive drop-off that does not actually exist—it is just two different event names sitting in separate Mixpanel tables.

Logging every tiny event also adds browser overhead and inflates analytics bills. The point is not to log every cursor move or page click; it is to track the handful of exact moments where state passes from one system, browser, or API to another.

When the path becomes standing work

In early builds, the path to purchase gets built once, tested manually, and left alone while the team moves on to core features.

In a mature product, that path is living infrastructure that needs constant maintenance. Web browser vendors tighten cookie persistence rules. Mobile email clients rewrite destination URLs. Password managers obscure input fields. A sign-up sequence that worked perfectly six months ago slowly degrades as third-party software updates around it.

When keeping this path smooth becomes a regular part of maintainability rather than a one-off growth sprint, the fixes become technical and precise. You preserve active session state across magic-link verifications by routing tokens back to the original device over WebSockets. You automatically match domain names on email invites to eliminate manual approval steps for corporate accounts. You cut initial rendering times by pulling user preferences during the primary authentication call instead of waiting for a second network request after mount.

Fixing a leaky product path does not require launching new marketing campaigns or redesigning the homepage. It requires looking at the small, frustrating technical friction points sitting between a willing user and a working screen, and clearing them out of the way. A user who clicks a button in your app wants to see what happens next, and the job of the software is simply to deliver on that expectation without getting stuck.

Weekly Briefing

The studio briefing.

What we’re building across the portfolio, every Monday.

JT

Written by

Justin Tsugranes

Founder, Total Ventures

Solo-founder building and operating a multi-brand product studio with AI agents. Writing about building, operating, and shipping.

ShareXLinkedInFacebook
#funnel-architecture#user onboarding drop off#app drop off points#telemetry state transitions#sign up flow friction