Designing for simplicity at scale, from 0 to 1M users.

TL;DR

AR.IO replaced the permaweb's lone gateway with a network anyone can join. I led product and design for the surface that made that practical: one dashboard covering staking, node operations, retrieval, manifests, and ArNS names. The network went from 0 → 1M+ active users, picked up 20+ integrations (Meta, Solana Mobile, Metaplex, AO), and deploying an app onto permanent storage dropped from hours to minutes.

Team: 2 PM · 3 Design · 5 Eng · 2 QA
Scope: UX and UI for the dashboard, product strategy and roadmap, manifest and ArNS flows, observability, the design system, and a hand in the front-end build.

New to Web3?

To understand this design project, it is helpful to first embark on an unsolicited high-level history of the internet. ICYMI we are moving from company-owned internet platforms to community-owned internet platforms. Web1 (roughly 1989 to 2004) was characterized by users being in a "read-only" environment, whereby they could passively consume content online, and there were very few creators (developers).

Web2 (aka the internet we have largely participated in for the past two decades) has been characterized by a "read + write" dynamic — enabling user participation, interaction, and personalization. Applications — whether podcasting, social media, blogging, tweeting, e-commerce, etc. — gave users and participants the ability to contribute to each platform accordingly. The successes of a small number of software companies from Spotify to Shopify, and the FAANGs in-between, have helped us navigate the internet as seamlessly as possible. And we are hooked on that ease — even at the tradeoff of privacy, extortionate subscription schemes, platform-lock-in, censorship, security, and being at the mercy of advertising. Large tech firms went from focusing on user growth to monetizing users' activities, leading the internet to become highly centralized and dominated by a handful of monopolies.

Web3 is characterized by adding an "own" element to the read + write composition of a web2 world. This aims to solve a lot of these problems we find ourselves in now, with an emphasis on decentralization. The web3 paradigm generally aims to be community-driven, self-governed, and powered by blockchain technology. A common misconception that people often have when they hear or read the words "blockchain" or "web3" is that they often associate them with essentially being synonymous with cryptocurrency. But crypto is simply an application of the technology.

A mental model that helped demystify web3 for me early-on, was to understand that the first killer app for the internet was actually email. Before that, there was a general ambiguity of value. The email use-case is really what helped the technology go mainstream and opened up a sprawling entrepreneurial sandbox for technologists, designers, and engineers to begin to imagine all of the other opportunities that the technology could make possible. Similarly, the first killer app for blockchain technology was cryptocurrency (popularly Bitcoin). Ethereum added a computational dimension to the crypto use-case, laying the groundwork for other types of apps to be built on top of blockchains. We now have a similarly wide open landscape of possibilities of what can be built, or re-built better. In the words of Chris Dixon, a16z:

Blockchains solve the same problems that other digital services solve, but with better outcomes. They can connect people in social networks, while empowering users over corporate interests. They can underpin marketplaces and payment systems that facilitate commerce, but with persistently lower take rates. They can enable new forms of monetizable media, interoperable and immersive digital worlds, and artificial intelligence services that compensate — rather than cannibalize — creators and communities.

Context

Arweave is a global, permissionless data store. You pay once and the data stays. For years, though, nearly everything on it was reached through a single gateway: one point of failure, one queue, one operator's uptime. AR.IO's protocol lets anyone run a gateway that writes, indexes, and serves permanent data. Our job was to make that something a person could actually do, whether they were a community member with a Raspberry Pi or a company running cloud clusters.

Problem

1. One gateway carried the whole network. Reliability and choice both bottlenecked there.
2. Running a node took protocol expertise most people don't have.
3. Indexing, manifests, and name resolution were powerful but hard to use.
4. Operators wanted to know the economics were fair before staking real money. Users just wanted fast retrieval.

A gateway, in practice, is an API. Every node in the network serves the same HTTP surface over Arweave: fetch any transaction's data at its ID, query the index through GraphQL, resolve an ArNS name to its content, proxy new data in. That uniformity is the whole point — an app can talk to permanent storage like any web service, and swap gateways without changing a line of code. But standing one up used to mean assembling that surface yourself, from protocol internals most teams never touch. The product's job was to close that gap: keep the API powerful, and turn running it into configuration instead of expertise.

Strategy

We made five bets:

• Modular by default, so gateways could specialize without forking the product.
• One dashboard for everything an operator touches: staking, health, indexing, caching, pricing, rewards.
• Developer ergonomics over feature count: consistent APIs, manifest tooling, a short path from local dev to production.
• Staking and rewards transparent enough to earn trust from people risking their own money.
• Everything open source.

The dashboard

• Stake to operate, and watch balances, rates, and earnings move.
• Writes proxy through to Arweave mempools for reliable inclusion. Reads come back fast through configurable caches.
• Indexing progress you can actually see, plus targeted indexing for specialized datasets.
• Manifests turn a folder of assets into an app served from permanent storage, at one URL.
• ArNS resolves human-readable names to gateway subdomains.
• Health, latency, and error dashboards with alerts, and roles for team-run gateways.

For developers we kept the surface small: unified APIs, CLI and GUI flows for publishing and verifying manifests, and cookbook examples for the common stacks.

Design

The UI is dark-first and high-contrast: minimal chrome, generous spacing, type doing the hierarchy work. Wide numerals for telemetry, monospace for hashes and IDs, semantic color reserved for states that matter. Defaults are safe for someone on day one; the expert controls sit a click deeper. Motion exists to confirm what just happened, and it respects reduced-motion settings. Where trust is on the line, at publish, verify, and serve, the hash, size, and permanence status sit right in the flow. We held the whole thing to AA contrast, put focus rings everywhere, kept full keyboard paths through staking and publishing, and never let a status rely on color alone.

Execution

We started by interviewing the original gateway operators and instrumenting early node logs. The pain concentrated in three places: setup, indexing, and tuning. From there it was weekly release trains, a token and component library to keep ten screens feeling like one product, feature flags around the risky subsystems, and cohort rollouts held to SLOs on retrieval latency and write inclusion.

Architecture at a glance

• Write path: client → gateway proxy → Arweave mempools → durable storage.
• Read path: client → gateway → cache and index → blockweave.
• Manifests: build, bundle, publish, serve from a single URL.
• Names: ArNS record → resolver → subdomain routing.
• Every subsystem swappable: storage backends, caches, indexing strategies.

Results

• 0 → 1M+ active users across the network.
• 20+ integrations, including Meta, Solana Mobile, Metaplex, and AO.
• App deploys dropped from hours to minutes once manifests did the serving.
• No single point of failure left. Many gateways, faster and more predictable retrieval.

What was hard

Keeping the simple path simple while the expert controls multiplied. Designing staking UX that stayed honest while the token economics were still moving under it. And supporting a Raspberry Pi and a multi-region cluster with the same product, which sounds romantic and mostly meant testing everything twice.

What I wanted to do next

Policy packs, opinionated presets for archival, media, and testnet workloads. A discovery surface for finding gateways by performance and coverage. Indexing that tunes itself to the workload. Better cost forecasting for operators planning capacity.

My part

I owned product and design: strategy, roadmap, KPIs, the design principles and system, and the quality bar. Early on that meant hands-on UX and UI design and a share of the front-end implementation. Later it meant scaling the same standards through rituals, documentation, and contributor guidelines.