There is a certain irony in writing quickly about slowness. But that is the world we inhabit — one where the pressure to ship, iterate, and move on has become the background noise of creative work.

Slow Design is not a manifesto against productivity. It is a recalibration. It asks a different set of questions before the work begins: Who is this for? What problem does it truly solve? What happens to it in ten years?

## The Origins of a Movement

The term borrows from the Slow Food movement that emerged in Italy in the late 1980s as a direct response to the opening of a McDonald's near the Spanish Steps in Rome. Carlo Petrini's protest was not anti-progress — it was pro-intentionality.

When Dieter Rams enumerated his ten principles of good design in the 1970s, he was already arguing for restraint in an era of plenty. "Good design is as little design as possible," he wrote.

## What Slow Looks Like in Practice

A slow design process does not mean a slow timeline. It means the time spent is directed differently. More of it goes toward understanding, less toward producing.

They write before they wireframe. Putting an idea into prose forces a clarity that sketching can disguise. If you cannot explain what you are building in a paragraph, you do not understand it well enough to design it.

They visit the problem in different contexts. A product used at a hospital nurses' station requires different thinking than a product imagined only at a desk.

They measure durability, not just delight. The best designs are ones that users barely notice after a while — not because they are boring, but because they have become fluent.

## The Business Case Nobody Talks About

Slowness has an ROI that is genuinely difficult to quantify. The brands with the longest design legacies — Braun, Muji, Apple at its best — did not get there by moving fast and breaking things.

## A Personal Practice

The simplest version of this: before opening any design tool, I write three sentences. What is this for? Why does it matter? What would make it fail? The answers are often uncomfortable. That discomfort is the point.

The Quiet Revolution of Slow Design

The phrase "local-first" gets used in a lot of ways. Sometimes it means "works offline." Sometimes it means "your data stays on your device." It is worth being precise, because the implications for how you build software are significant.

The canonical definition comes from a 2019 paper by Martin Kleppmann and colleagues at Ink & Switch: local-first software prioritizes the local copy of your data over any server copy, while still enabling real-time collaboration. The server, in this model, is a convenience — not an authority.

## Why This Matters Now

Most software today is cloud-first by default. Your documents live on Google's servers. Your notes live on Notion's servers. This works beautifully when you have an internet connection and when those companies continue to exist.

Neither of those conditions is guaranteed.

## The Technical Challenges Are Real

The core challenge is conflict resolution: what happens when you edit a document on your laptop while someone else edits the same document on their phone, and neither device has internet access?

This is where CRDTs — Conflict-free Replicated Data Types — enter the picture. They are data structures designed to merge automatically without conflicts, no matter the order in which changes arrive.

## What a Local-First Stack Looks Like

A local database on the device — SQLite is the common choice for mobile and desktop. A sync layer that handles conflict resolution. A server that stores a copy for backup and sharing — a peer, not a master.

## The Trade-offs Nobody Advertises

Local-first is not free. You give up the simplicity of a single source of truth. You take on the complexity of eventual consistency. The point is not that local-first is always better — it is a genuine alternative with genuine advantages.

What Local-First Software Actually Means

I read three books in January. I read one in June. The difference between those months was not the availability of time — it was the availability of attention.

This is not a confession about personal failing. It is an observation about an environment. The systems we interact with daily are not neutral. They are engineered, with considerable sophistication, to keep us engaged.

## What the Research Actually Shows

The statistic you have probably heard — that human attention spans have dropped to eight seconds — is not real. It originated from a Microsoft Canada report in 2015 that itself was based on dubious methodology.

What is real is context switching. Our capacity for sustained attention has not biologically diminished. What has changed is that we have filled every available gap with stimulation.

## The Specific Difficulty of Long-Form Reading

Reading a book is a cognitive mode. It requires holding a thread across sessions, across days, sometimes across weeks. It requires accepting that you will not understand the argument until you have finished it.

These are skills. They atrophy when unused.

## A Few Things That Have Helped

Treating reading as a commitment rather than a leisure activity. I schedule it. This felt absurd at first and now feels obvious.

Physical books when possible. The research on this is mixed, but the behavioral reality for me is clear: I do not get notifications from a paperback.

Reading for a reason. Having something I am trying to understand gives the reading a destination.

## What We Are Actually Defending

The thinking that happens in the middle of a long book, when the argument has built enough that you start finishing the author's sentences — that thinking does not happen any other way. It is worth protecting.

The Attention Economy and the Art of Reading

A type annotation is a note to the future. When you write that a function accepts a UserId rather than a string, you are telling every developer who reads that code something important about what this value means.

This is the part of type systems that gets undersold. The pitch is usually about catching errors at compile time, and that is real and valuable. But the deeper value is communication.

## The Difference Between Types and Validation

Types and validation are treated as alternatives in many codebases. They answer different questions. Validation answers: is this data what I expect right now, at runtime? Types answer: what does this data mean, and what can I do with it?

The value of a type like UserId over string is not that it prevents you from receiving an invalid user ID at runtime. It is that it prevents you from accidentally passing a PostId where a UserId is expected.

## Making Illegal States Unrepresentable

The most powerful use of a type system is making certain states impossible to represent. A discriminated union eliminates invalid states at the type level. The bugs in your authentication logic simply cannot exist.

## The Cost of Expressiveness

More expressive types require more thought upfront. The trade-off is real, and the right balance depends on the codebase, the team, and the rate of change.

What I am arguing against is treating types as purely defensive. At their best, types are a design tool. They force you to articulate what things are before you write the code that handles them.

## A Practice

When I write a new module, I often write the types first and leave the implementations empty. The types become a sketch. They tell me whether the design makes sense before I have invested hours in the implementation.

Type Systems as Communication

My notes folder has 340 entries. My drafts folder has 47. This piece began as an entry in the notes folder before becoming a draft, before somehow — improbably — becoming finished.

The ability to finish things is not a personality trait. It is a skill, developed through practice and degraded through avoidance.

## Why We Stop

The moment most creative projects die is predictable: it is when the gap between what the thing is and what you imagined it could be becomes visible.

In the early stages, a project is full of potential. A headline, a sketch, a first chapter — these are the promise of the thing. The promise can be anything.

Then you start making it real, and reality is limiting. Most people, at this point, abandon the project or start a new one.

## What Finishing Actually Requires

They separate creation from evaluation. When writing, they write. They do not edit while writing. The inner critic is scheduled for later.

They have a definition of done. Vague projects do not get finished because there is no finish line.

They have a tolerance for good-enough. A finished thing with flaws exists in the world. An unfinished perfect thing does not.

## The Accumulation Problem

Each unfinished project occupies a small but non-zero amount of cognitive space. The single most effective thing I have done for my creative output was finishing or formally abandoning old projects.

Abandonment counts as finishing. The problem is not incomplete projects — it is incomplete decisions about incomplete projects.

## What I Actually Do

When I notice I have been avoiding something, I give myself a deadline of one week to either finish a rough version or write one sentence explaining why I am abandoning it. Both outcomes are acceptable. Avoidance is not.

On Finishing Things

The CDN was a workaround. You had servers in one place, users everywhere, and latency was the tax. Edge computing is a different idea — running actual code in data centers distributed globally, close to users.

This sounds like a performance optimization. It is also an architectural shift.

## What Running Code at the Edge Actually Means

Edge functions run in a lightweight runtime — typically V8 isolates rather than full Node.js. You do not get the full Node.js API surface. No filesystem access, limited crypto, no native modules.

What you do get: fast startup, global distribution, and the ability to run logic before you decide where to send the request.

## The Database Problem

The thing that limits edge architectures most is data. If your edge function needs to query a database, you are back to the latency problem.

The solutions emerging are interesting: edge-compatible databases that replicate globally, read replicas near edge nodes, caching layers that can be invalidated from the origin.

## When the Tradeoffs Make Sense

Edge is not the answer for every application. Edge shines where the work at the edge is lightweight and the win from global distribution is real. API gateways, middleware logic, request routing — these are native edge workloads.

## The Broader Shift

What I find most interesting about edge computing is not the performance story. It is the implication that the internet's architecture is still being negotiated. We are building infrastructure as if the network is a constraint to route around. Edge computing is one answer to that constraint. It will not be the last.

Inkwell

The Quiet Revolution of Slow Design

The Quiet Revolution of Slow Design

What Local-First Software Actually Means

The Attention Economy and the Art of Reading

Type Systems as Communication

On Finishing Things

Building for the Edge