Reading became the job. So we built a way to listen to it.

Most software gets built because the maker wanted a feature. Scroll got built because the maker had a problem they couldn’t out-work: there was simply too much to read.

This is the first entry in a build journal about how Scroll gets made — not the marketing arc, the decision arc. What we bet on, what we got wrong, what shipping taught us, and the methodology underneath the systems that make it work. It starts here, with why the thing exists at all and the constraints we accepted on day one.

The job nobody lists in the job description

If you build, sell, or analyze for a living, your real job is reading. Documentation. GitHub issues. API changelogs. Pricing pages. Customer emails. Competitor sites. Research papers. Contracts you should probably read before you click accept. Threads where the useful part is buried forty comments down.

Somewhere along the way the browser became a second IDE — and it had no debugger for attention. You can’t ship if you read everything front-to-back, and you can’t lead if you skip the one clause that mattered. The work around the work quietly becomes the work.

The gap between “read it” and “summarize it”

Two kinds of tools already exist, and neither closes that gap.

• Text-to-speech reads every word in order. It’s an audiobook of a contract — no judgment about what matters, and it takes as long as reading would have.
• Summarizers collapse everything into the same five bullets and throw away the exact paragraph, the exact error, the exact caveat — which, in high-stakes reading, are the only parts that matter.

The missing middle is this: most of the time you don’t yet know which part deserves a summary. You need to move through the page at normal human skimming speed and have the depth follow your attention — terse where you’re flying, thorough where you slow down.

The reframe: your scroll is the input

Here’s the idea the whole product hangs on. Scroll is not a conversational voice agent. There’s no microphone turn, no voice-activity detection, no back-and-forth. The “user turn” that every other voice app waits for is replaced by a non-verbal signal you already produce constantly: the scroll gesture itself.

That single reframing drives every design decision that follows in this journal. Because the input is a gesture and not a sentence, the system runs in a server-driven narration mode — it watches the screen, decides when you actually want to hear something, and requests speech, rather than waiting to be asked. And the interruption machinery built for “the user started talking” gets repurposed for “the user scrolled away.”

What we deliberately did not build

Picking the shape of a product is mostly picking what it isn’t. Three non-goals we committed to early, because each one is a different product that would have pulled us off course:

• Not a chatbot. The default interaction is ambient and hands-free. There is one explicit way to ask a question out loud, but the product’s job is to narrate what’s in front of you, not to hold a conversation.
• Not a summarizer-in-a-sidebar. Scroll never asks you to copy text into a box and leave the page. It reads the page you are already on, in place, and the page stays the interface.
• Not a single magic model. From the first commit, the narration engine sits behind a protocol, so the model that does the understanding and the voice can be swapped without touching the rest of the app. That one decision pays off repeatedly later in this journal.

Pick a fight you can win

Ordinary articles are a crowded, weak wedge: reader modes, read-aloud, podcasts, and summarizers already serve them. The sharper wedge is high-stakes skimming, where missing a section has a cost — contracts and filings, research papers, financial reports, long code reviews, dense product and compliance docs. That’s who we built the first version for, and it’s why “just give me the gist” was never the whole answer.

Coverage is a matrix, not a checkbox

A screen reader for “anything on your Mac” sounds like one feature and is really dozens. A clean news article in Safari, a contract in Preview, a thread in Slack, code in an editor, a canvas-rendered web app — each exposes its text to the system in a completely different way, and some barely expose it at all. So we never treated capture as solved or unsolved. We treat it as a compatibility matrix: tracked per app, scored for confidence, and tested target by target. The methodology behind that — accessibility first, on-device vision as a fallback, and a router that decides between them per capture — is the subject of the next post.

Permissions you have to earn

A tool that reads your screen is asking for two of the scariest permissions macOS hands out — Accessibility and Screen Recording. We decided from the start that trust is a precondition, not a polish item. That meant some hard rules baked into the architecture: text is extracted on your machine and only the narrated text leaves it; you can name apps — banks, password managers — that Scroll refuses to read; sensitive patterns are scrubbed before anything is sent; there’s a fully local mode that sends nothing at all; and a live inspector shows you the exact text before and after it leaves. We’ll get into how each of those is actually built later in the journal.

The law we wrote on day one

A voice that reads your screen is only useful if it stays locked to where your eyes actually are. The moment it drifts — narrating a paragraph you’ve already scrolled past — it stops being a help and starts being noise.

Stale narration is worse than sparse narration.

That sentence became the first product law, and it turned out to set the agenda for months. Most of the engineering went not into making the voice talk, but into deciding when not to. The next post is about the loop we built to keep the spoken word attached to the eye — capture, attention, pacing, and the unglamorous bookkeeping that makes interruption honest.