Skip to content

tiago@guedes: man faster-funnel

~ $ man faster-funnel

FASTER-FUNNEL(1) FASTER-FUNNEL(1)

Name

faster-funnel — Faster funnel, quieter alerts

Synopsis

faster-funnel --client "subscription ecommerce, Shopify" --role "Audit, fixes and tooling" --when 2026

--stack Vue 3, TypeScript, Playwright, Lighthouse, Error monitoring

Description

A front-end audit, race-condition fixes in the sign-up funnel, error monitoring that only alerts when something is really wrong, and an end-to-end checkout test.

Context

For a subscription brand, the sign-up funnel is the business: every slow step or lost tap is a customer who doesn’t subscribe. The storefront had grown quickly and needed a proper look end to end.

My role

I ran the audit, fixed most of what it found, and added checks to keep it fixed.

What I did

A front-end audit, shipped as small pull requests

  • Lazy-loaded rarely used screens and prefetched the next funnel step while the customer is still on the current one.
  • Moved work from the browser to build time, and loaded error tracking after the page becomes interactive.
  • Split a large state store into focused modules, and merged several data transformers into one after checking it produced identical output on real data.
  • A Lighthouse review showed most of the mobile slowdown came from third-party scripts rather than our own code, which changed where the effort went.

Race conditions in the funnel

  • A pre-filled discount code appeared late, because it waited on several network calls in a row. It now shows immediately and the rest happens in the background.
  • Product choices locked the screen while the cart updated, so quick taps were dropped. The lock was there to stop the cart going out of sync, so I replaced it with a queue where the latest choice always wins and the next step waits for the cart to catch up. It’s fast and still correct.
  • An invalid email slipped past validation. The validator was fine; the form sent values read after validation, while the field was still editable. It now sends exactly what was validated.

Error monitoring you can trust

A week of triage showed most of the error volume came from automated link scanners, not real customers. I quietened that noise and turned a confusing failure into a clear, typed error.

With the noise gone, the alerts caught a real problem within days: a modal was silently hiding a refusal from the backend, so customers kept retrying. The fix, which tells customers what happened, shipped the same week.

Tests that click through the funnel

I built a Playwright test that walks from the landing page to checkout on staging in about 20 seconds, with a lighter version planned to run on every pull request.

Trade-offs

The audit flagged contrast issues on colours chosen by the brand. I left the colours alone, since they are the brand’s call, and fixed the accessibility problems that don’t change the look, such as missing labels on controls.

Outcome

  • Error noise cut by more than half, so real customer problems stand out.
  • The funnel no longer drops taps or waits on avoidable network calls.
  • One command tests the path that makes money, end to end.

What I’d do differently

Measure before guessing. When CI felt slow, the linter got the blame; timing it showed the time was going somewhere else entirely.

See also

experiments(1), one-codebase(1), tiago(1)

November 2026 FASTER-FUNNEL(1)

(END) press q to return

© 2026 Tiago Guedes · Astro on Cloudflare Pages · source