When outputs become easy, the future rewards judgment, taste, and the discipline to finish.
Previous · Part 6
The Rise of the One-Person Company: How to Build a Real Business Without a Team
Next · Part 8
Interfaces Are the New Gatekeepers: How to Get Heard in a Platform-First World
This builds on Part 6: The Rise of the One-Person Company: How to Build a Real Business Without a Team
Continue with Part 8: Interfaces Are the New Gatekeepers: How to Get Heard in a Platform-First World
Software Is Becoming Literature
Software used to be judged like machinery: fast, reliable, correct.
Now it’s being judged like writing—by what it communicates, how it frames a world, and what it leaves behind in the reader’s mind.
The shift: from functionality to authorship
When users interact with an app, they’re not only executing tasks. They’re interpreting intent.
A calendar that nudges.
A feed that prioritizes.
A settings screen that hides friction—or invites it.
Each choice is editorial. Each decision is narrative pacing.
Why this matters right now
The barrier between “code” and “content” is thinning. Language models can draft, rewrite, and respond. Interfaces increasingly behave like characters. And software is expected to be conversational, contextual, and emotionally intelligent.
That doesn’t mean everything becomes fiction.
It means software is being held to the same standard as prose: clarity, voice, coherence.
What “literature” changes in how you build
Treating software as literature changes three things:
- Craft becomes visible. Small choices add up to an aesthetic and a rhythm.
- Meaning becomes testable. You can evaluate whether users “get it,” not just whether they complete the flow.
- Emotion becomes design material. Trust, calm, urgency—these are not effects. They’re outcomes of structure.
The overlooked component: reader experience
In writing, the reader carries meaning across sentences.
In software, the “reader” carries meaning across screens, states, and timing.
Pay attention to:
- Onboarding as opening chapter (promise + stakes)
- Empty states as authorial restraint (what you refuse to pretend)
- Error handling as tone (apology, blame, clarity, repair)
- Undo and recovery as narrative permission (“try again” without shame)
A practical model: the three layers of software-as-text
Use this mental stack to evaluate any experience:
- Surface (voice): labels, microcopy, visual rhythm
- Structure (grammar): navigation, interaction patterns, state changes
- Subtext (theme): what the system implicitly believes about the user’s goals and constraints
Diagram: Surface: Voice leads to Structure: Grammar; Structure: Grammar leads to Subtext: Theme; Subtext: Theme leads to User Interpretation: What this means; User Interpretation: What this means leads to Behavior: What they do next.
Diagram: Surface: Voice leads to Structure: Grammar; Structure: Grammar leads to Subtext: Theme; Subtext: Theme leads to User Interpretation: What this means; User Interpretation: What this means leads to Behavior: What they do next.
Tabs for how to apply the idea
Map your key flows to a “chapter outline.” For each step, write one sentence: what promise this moment makes, and what feeling it earns.
Steps to start writing with your software
Takeaway
If software is becoming literature, then your job isn’t only to build features.
It’s to author meaning—through structure, voice, and the experience of reading your system.
If this resonates, see how to apply it to your own work with the interactive Dispatch agent.
Be first to like this dispatch
