Glasp’s note: This is Hatching Growth, a series of articles about how Glasp organically reached millions of users. In this series, we’ll highlight some that worked and some that didn’t, and the lessons we learned along the way.
If you want to reread or highlight this newsletter, save it to Glasp.
Popular Episodes at a Glance
#3: How We Rode the AI Wave with Side Projects Before It Exploded
#17: How We Grew ChatGPT Traffic 37x Using Our Own Server Logs
#18: How a Two-Person Team Uses AI to Run Multiple Products With 3.5 Million Current Installs
Hi, Kei and Kazuki here.
Glasp is two people. Between us we maintain browser extensions, a web app, native mobile apps, a separate AI product, and a research practice. About 3.5 million browsers currently have a Glasp extension installed.
In #18, we described the loop most of our systems share: a signal, a queue, a bounded worker, a verification step, and a retirement rule, and applied it to growth, content, and measurement. Last time, we covered our research. This issue keeps the rest of the promise from #18.
It applies the same loop to two kinds of work that are usually handed to separate teams, answering users and rebuilding products, and ends with the agent workflow underneath both.
In this issue:
Customer support as a product system. How feedback from Chrome Web Store reviews, App Store and Google Play reviews, and support email becomes one queue, what Claude drafts, and what a person still decides.
Rewrites that are not finished when the code ships. What rebuilding both native mobile apps taught us about measuring a rewrite and updating the world’s memory of a product, and why human patches, not AI-written code, became the technical debt in our Chrome extension.
The agent workflow underneath. Contracts instead of standing instructions, why we stopped relying on written rules and built a harness, Claude Code and Codex reviewing each other, more workspaces than people, how an idea reaches the right session from a phone, and how we keep old Macs running agents all day without overheating.
The first section is open to everyone. The rest is for paid subscribers.
* This spot is open for your product.
Hiring? Post a job in the Glasp Newsletter
Put your open role in front of 550K+ subscribers: founders, builders, students, and knowledge workers, with 250,000+ views per send across email and web. $199 per post, at most three roles per issue, and every listing is reviewed before it runs.
Support is a product system, not an inbox
At our scale, customer support cannot mean two founders reading every message from the top of an inbox and replying faster. There is not enough time, and even if there were, speed is the wrong goal.
The first layer of our support is not a model, and it was never about keeping people away from us. Between our first 100 and first 1,000 users, we ran more than 750 onboarding calls on Zoom, 15 to 20 minutes each, as we wrote in Hatching Growth #1. Getting through onboarding was the part we protected most, because a user who gets past it usually stays. When someone is stuck, we still send a Zoom link or a calendar invite and walk through it together. When something breaks, we ask by email, in detail, how to reproduce it: which browser, which page, what they clicked, what they saw. Even when a problem first appears in a public review, we move the conversation to email, because a review cannot tell us how to reproduce the bug. The result is a lot of email. That volume is a choice, and it is the reason the next layer exists.
The second layer is a queue. Feedback reaches us through several doors: Chrome Web Store reviews, App Store and Google Play reviews, support email, Reddit, and YouTube comments. Each arrives in a different format, in many languages, about different versions of different products. Before anyone can answer well, each item has to become the same kind of object.
A useful support item carries more than the message:
product, platform, and version;
language;
the kind of problem;
account and payment state, when it matters;
the evidence already collected;
whether the reply will be private or public;
the next action the system is allowed to take;
and the person responsible for the final decision.
Once feedback has that shape, it stops being a stream of individual complaints and becomes something we can sort, group, and learn from.
The part of this that changed how we think was a failure.
A user wrote a public review that said, roughly, that we had taken their money and never replied. The refund had in fact already been issued. The payment system had done its job. But nobody had told the person, so from their side nothing had happened, and the review said so to everyone who read it.
The backend action was complete. The trust loop was not.
That changed our definition of done. A support case is closed only when three things are true: the user has been told what happened, the external state matches what we told them, and the underlying cause has somewhere to go so it does not come back as the next message.
The last condition is the one that makes support scale. Ten messages about the same confusion should not become ten separate replies. They should become one issue that produces a product fix, a clearer screen, a help article, a new event we can measure, or a decision not to build the thing that caused the confusion.
This is our third paid field note. The regular newsletter remains public, and we will keep publishing these when we have a concrete system and real implementation detail worth showing.
Below, we share how Claude reads and drafts replies to feedback and where a human has to step in, how we handle refunds and disputes, what rebuilding both mobile apps and the Chrome extension taught us about finishing a rewrite and about technical debt, and the agent workflow that connects all of it: the loop, the harness, Claude Code and Codex reviewing each other, always-on Macs, and a small tool called session-baton.
