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
Hi, Kei and Kazuki here.
When people find out how small Glasp is, the question is always the same. There is usually a slight pause before it, as if they are checking whether they heard us correctly.
Two people?
Two people. Between us, we maintain browser extensions, a web app, native mobile apps, a separate AI product, and a research pipeline that has produced about a dozen papers in roughly three months.
Across our browser extensions, the current installed base is about 3.5 million installations.
That definition matters. This is an installation count, not a count of unique people or devices, not monthly active users, and not cumulative downloads. It excludes extensions that have been uninstalled, and somebody running two of our extensions appears twice.
The usual answer to the two-person question is that we automate a lot. That answer is true and almost useless.
The interesting part is not the volume of work we hand to machines. It is the shape we force the work into before we hand it over, the things we deliberately keep in human hands, and the work we refuse to create because its operational cost would remain with us forever.
This issue is about that shape.
We are publishing this field note as a three-part series. This first issue follows one product-growth loop. We do not treat Marketing Ops, Content Ops, Analytics Ops, and product development as separate functions. Product use and distribution create signals. Analytics helps us decide which signals are real. Those findings shape what we build, what content we create, and which relationships we prepare to pursue. The outcomes return to the same measurement system and start the next cycle.
The second issue will cover how we build, support, and study the products with AI. The third will focus on DevOps: how the products are deployed, monitored, and kept running over time.
The loop every system has to fit
Most of our internal systems are built from the same five parts. We did not design them all at once. We arrived at this pattern after enough things went wrong that the systems that survived began to look alike.
A signal. Something actually happened, and it was recorded somewhere we can query. A user hit a video with no transcript. A crawler requested a page that did not exist. A product metric moved outside its expected range. Work begins with evidence, not a content calendar or a vague belief that something might be useful.
A queue. The signal becomes an ordered item with a state and enough context to act. A useful queue records what needs to happen, why it entered, what happened last time, how many times it has been tried, and whether it is finished.
A bounded worker. Code or an AI agent takes an item and performs one narrow task. It has a hard limit on how much it can change, spend, send, or process. A worker without a ceiling is not automation. It is an open tap.
A verification step. A worker reporting success does not prove that the user received the intended result. Something separate has to inspect the outcome and be able to return no.
A retirement rule. Whatever the system creates, the system must also know when to stop, archive, reverse, or remove. We did not take this seriously enough in the first few years. It is one of the first things we would install if we started again.
That is the operating model: signal, queue, bounded worker, verification, retirement.
A script that creates output is a shortcut. A system that detects demand, acts within a limit, verifies the outcome, and stops when the value disappears is infrastructure.
This is the first time we have put anything behind the subscribe button. Some of you have been paying for a while and receiving exactly what everyone else receives. That was never the deal we meant to offer, and this is us starting to fix it.
We are not turning every Glasp newsletter into a paid post. The regular newsletter will remain public. We will publish deeper paid field notes occasionally, when we have a concrete system, real implementation detail, and lessons worth showing rather than summarizing.
Below, we show how product signals, AARRR, daily analytics, paid-user behavior, public pages, tutorials, newsletters, and outreach move through one operating loop.
