Open almost any news app and time yourself. The feed scrolls without a bottom. Tap a story and it opens inside the app, in a reader view wrapped in the app’s own chrome, with three more stories stapled underneath it and a fourth sliding up as you reach the end. Nothing is broken. Everything is working exactly as designed. The design is a room — furniture arranged so that the easiest thing to do, at every moment, is stay a little longer. The number on the wall of that room is time-on-site, and every decision in it bends toward making that number bigger.
The Drudge Report is not a room. It is a page of links to other people’s pages — a switchboard, an index, a lobby with fifty doors and no chairs. Nobody has ever sat and read the Drudge Report; you scan it, you spot the one headline that matters to you today, and you leave through it to wherever the story actually lives. The page’s whole job is to end your visit well. And that one fact — that it’s a door and not a room — turned out to decide almost everything about how we built DReader.
The metric is inverted
When we started, the temptation was to build the room. Wrap each linked story in a clean in-app reader, keep the reader on our surface, stack the next headline underneath, and watch the session length climb. It’s the reflex every content product has, and there are whole frameworks that assume it’s what you want. But it’s the wrong shape for this object. A reader who came to the front page to find the one thing worth clicking is not served by being kept — they’re served by being sent, quickly and honestly, and then not made to pay a toll to come back for the next one.
Most content apps win when you stay. This one wins when you leave well and come back easily. The success metric isn’t the length of the visit — it’s the number of good round trips inside it.
Once you accept that, a pile of decisions that looked like polish turn out to be the product. Don’t trap the story in a reader view — hand it straight to the real page, because that’s where the reader was always going. Don’t stack an infinite feed — there’s a fixed front, and pretending otherwise just hides the thing they came to scan. Don’t measure the minutes — measure whether the trip out was fast and the trip back was faithful. The whole app collapses to one gesture done well, over and over: out to the story, and back to exactly where you were.
The trip out
The trip out is the easy half to describe and the easy half to get wrong. Getting it right means refusing to be clever. A headline is a promise about a specific page somewhere else on the web, and the most respectful thing DReader can do is keep that promise with as little of itself in the way as possible. So a tap resolves to the actual destination, not a proxied, re-hosted, ad-reinjected copy of it. There’s nothing to dismiss, no interstitial, no “continue to site.” The link is the link. That sounds like doing less, and it is — but doing less is the entire discipline of this thing, and every gram of app you leave out of the trip out is a gram the reader doesn’t carry.
The part worth engineering is speed. The reader has already told you where they’re going the instant the front paints — the lead is set enormous, the flash is set red, and the size is the story. So the destinations most likely to be tapped can be warmed before the tap ever happens, which turns the trip out from a cold navigation into something that feels like the story was already waiting. Fast isn’t a nicety here. On a switchboard, latency is the only real defect, because the whole reason you exist is to be a quicker way through than typing the URL yourself.
The trip back
The trip back is the half everyone forgets, and it’s the one that makes the difference between a tool you keep and a tool you tolerate. A person scanning the front doesn’t read one headline; they read one, go, come back, read the next, go, come back. If coming back drops them at the top of the page, or reloads a different front than the one they were reading, or forgets which stories they’ve already been through, then every round trip after the first starts with a small tax — re-scroll, re-scan, re-find your place. Ten trips in, the tax is the experience.
So DReader treats “back” as a first-class destination, not an accident of the browser. You return to the same front you left — not a freshly re-fetched one that reshuffled while you were gone — at the same scroll position, with the row you just visited quietly marked so your eye skips it and lands on the next unread thing. The list holds still so you don’t have to hunt. That’s the entire trick, and it is almost invisible when it works, which is exactly why it’s worth the work: a good round trip should feel like no trip at all.
Why a small studio builds the door
There’s a reason the big apps build rooms and a small studio like ours is happy building the door. A room has to justify its own existence every session; it needs you inside it, so it grows features to keep you, and the features grow chrome, and the chrome grows weight. A door has no such anxiety. It doesn’t need you to stay, so it can afford to be honest, fast, and nearly weightless — to do one thing, get out of the way, and be there again when you come back. That’s the kind of software we only ever want to build: the kind whose highest compliment is that you barely noticed using it, because it spent all its care on the trip and none on keeping you. DReader isn’t the page you look at. It’s the round trip you don’t.