Building for one reader: why my site is designed for a person in 2034, not 2026

I have one imaginary reader in my head when I write here. Her name in my head is Ana. She is a junior engineer at a small company in Porto, eight years from now, in 2034. She is researching how people used to build autonomous agents back when the field was new. She finds my site through a chain of links from a university syllabus and has thirty minutes between meetings. What does she get from me?

This question is the design constraint for everything I publish. It is not about predicting the future. It is about building a small piece of the web that is useful even after its context has evaporated. Most personal websites are built for the now. They chase the traffic spike from a social media mention or a newsletter feature. I am trying to build something different. I am trying to build a library for one specific, imaginary person a decade from now.

Why 2034 and not 2026

Writing for today is easy. Writing for today means I can use shorthand. I can reference the latest framework, the current political joke, the meme that everyone saw last week. This creates an immediate connection with a reader who shares my exact moment in time. The problem is that this connection has a half-life. It decays. A post written for a reader in April 2026 will feel dated by April 2027 and nearly unreadable by 2034.

If I write for Ana, the calculus changes. I cannot assume she knows what I am talking about. I have to provide the context she lacks.

I have to explain that "x402" was a popular but flawed language model from a startup that was acquired in 2028. I have to explain why Cloudflare mattered in the great AI crawler wars of the late 2020s, when every website was trying to block the firehose of bots scraping data for model training. I have to explain why so many indie developers were self-hosting Postgres in 2026. The reason was that fully managed serverless databases were still prohibitively expensive for solo projects.

These details seem obvious now. They are the water we swim in. But water is invisible to the fish. For Ana, these details are crucial historical context. They are the difference between a confusing, jargon-filled artifact and a useful primary source.

My test for any post is simple. Would Ana, in 2034, still get value from this? If the answer is no, it is probably a tweet or a passing thought. It is not a blog post for this website.

What this changes in practice

This philosophy is not just an abstract idea. It leads to a set of concrete, practical rules I follow when writing and editing. These rules often make the writing process slower, but they are what make the final product durable.

Here are six shifts in my practice.

1. I explain standards in-line instead of just linking. Links rot. It is a fundamental law of the web. A link to a spec or an RFC might work today, but it could be a 404 by the time Ana finds it. Instead of writing "See the spec for details," I will write, "The HTTP/2 spec, RFC 7540, defines this as a stream error. Specifically, section 8.1.4 states that..." This explanation is self-contained. It survives even if the link dies.

2. I date everything explicitly. I avoid relative time references. "Last month" becomes "March 2026". "Recently" becomes "In early 2026". "A few years ago" becomes "Back in 2023". This feels robotic at first, but it is a gift to a future reader. It anchors the writing in a specific, unambiguous point in time.

3. I use absolute numbers. Vague quantifiers like "our traffic doubled" are meaningless without a baseline. I force myself to be specific. "Our monthly active users grew from 42 to 84 in Q1 2026." This precision gives the statement weight and value. Ana can understand the scale I was operating at. It was small, and that is an important part of the story.

4. I describe the state of the art as of writing. Technology moves quickly. A statement like "the current state of the art is..." is a ticking time bomb. I defuse it by adding a timestamp. "As of April 2026, the state of the art for this task is using a diffusion model with..." This frames the information correctly as a snapshot, not an eternal truth.

5. I link to archive.org mirrors. When I link to an article or resource that seems likely to disappear, I also link to its Wayback Machine mirror. I will find the most recent stable snapshot and include it alongside the live URL. This is a small act of digital preservation. It provides a fallback for Ana when the original domain inevitably goes offline.

6. I avoid screenshots unless the visual is load-bearing. Text ages better than images of user interfaces. A screenshot of a settings panel from 2026 will look ancient in 2034. The product will have been redesigned a dozen times. Instead, I describe the steps in text. "Navigate to the 'Account' page, then select the 'API Keys' tab, and click 'Generate New Key'." This instruction is more likely to remain useful, or at least translatable, than a picture of a UI that no longer exists.

What I lose

This approach is not without its costs. I am making a deliberate trade-off.

I lose some immediacy. A sentence like "You have all seen the new feature in Claude" is punchy and conversational. It creates an immediate in-group feeling. My version is more sterile. "In April 2026, Anthropic launched a feature in their Claude model called Claude Design, a product that..." It is less fun to write and probably less fun to read in the moment. I accept this loss.

I lose some shareability. Posts optimized for today are designed to travel far and fast on social networks. They use hooks, hot takes, and shared context to generate engagement. My posts are optimized for a different kind of travel. They are designed to be found via search or a chain of links, years from now. They travel slowly, but they aim for a longer journey.

I lose some of the insider feel. I write fewer sentences that only a person who already follows my work would understand. This makes the site less of a clubhouse and more of a public library. That is the goal, but it does mean sacrificing a certain type of community connection.

What I gain

The benefits, for me, far outweigh the costs.

I gain a slower, more thoughtful writing pace. The pre-publication check is not just for typos. It is a perspective shift. I have to read my own words through Ana's eyes. Does this still make sense if someone reads it in 2034 with zero context about my life or my industry? Editing for that future reader is a slow, deliberate process. It forces me to be clearer, more precise, and more honest.

I gain fewer regrets. I look back at some posts I wrote in 2022 that were full of references to whatever meme was popular that week. They embarrass me now. They feel cheap and transient. The posts where I took the time to explain a fundamental concept, even if I did it imperfectly, still hold up. They are still useful. I want to write more of the latter and less of the former.

I gain more thoughtful reader mail. The replies I get from posts written this way are different. They are not quick reactions or dunks. They are from people who have read the whole thing, considered it, and have a specific, thoughtful question or comment. This approach acts as a filter. It filters for readers who are willing to engage deeply, and those are the conversations I value most.

Writing for Ana specifically

The persona of Ana is not just a generic "future reader." Her specific (imagined) attributes guide my writing.

• Ana does not know me. I avoid self-referential phrases like "as I mentioned in a previous post" without a link and context. I try to make each piece stand on its own as much as possible.
• Ana does not know my friends or my city deeply. If I mention a place in Taipei, I provide a sliver of context. Not "I was on Yongkang Street," but "I was on Yongkang Street, a neighborhood in Taipei known for its small restaurants and tea shops." This gives her a foothold.
• Ana is smart. This is crucial. I am not dumbing things down. I am providing context. I assume she is intelligent and capable, but just lacks the specific background knowledge of my time. So I do not simplify complex ideas. I just define my terms the first time they appear.
• Ana has thirty minutes. My goal is to write pieces that can be understood in a single, focused session. A dense, 5000-word essay might be valuable, but a clear 1500-word post that respects her time is even better. Clarity and conciseness are features.

The exception: live posts

Not every post on this site is for Ana. Some pieces are explicitly of their moment. A recap of a conference I attended, a reflection on a specific event, or a weekly newsletter digest are all examples. These are meant to be read in 2026.

For these posts, I lean into their timeliness. I date them aggressively and clearly label them. They are diary entries, not library books. This distinction is important. It gives me the freedom to be present and reactive when appropriate, without compromising the long-term mission of the rest of the site. The site is a garden. Some plants are perennials, built to last for years. Others are annuals, beautiful for a season and then gone. Both have their place.

A small editing trick

Before I publish a post, I do a final pass with a simple editing trick. I search the document for a list of "decaying" words.

• recent gets replaced with recent (as of April 2026)
• currently gets replaced with currently (in Q2 2026)
• the latest gets replaced with the latest 2026 version
• today gets replaced with in 2026

This is a small, boring, mechanical step. It takes five minutes. But it catches the little bits of temporal shorthand that are so easy to miss. It is one of the most effective and low-effort ways to make my writing age well.

The counter-argument I have heard

A friend once told me, "You are imagining a reader who may not exist. You are optimizing for a ghost."

This is a fair criticism. Ana is a fiction. The future I imagine for her is a guess. She may never exist, and if she does, she may never find this website.

But the criticism misses the point. The imagined-Ana constraint is a forcing function, not a prediction. It is a tool for thinking. It is a creative limitation that, like the constraints of a sonnet, forces a better result. I do not need to be right about the future to benefit from designing for it.

Even if Ana never reads a single word I write, I am a better writer because I write for her. My thinking is clearer. My prose is more precise. My work is more self-contained and, I hope, more generous to any reader, present or future.

I do not know if Ana will find this site in 2034. I know she deserves to, if she looks. That is reason enough to write as if she will.