Progressive Centralization

Bruno Skvorc's WebSummerCamp talk on building decentralized apps from the bottom up, then adding usability where it does not erase resilience.

Progressive centralization is a way to build decentralized apps without lying to yourself about the stack.

Start with the part that actually needs decentralization: ownership, execution rules, recoverability, censorship resistance, or downtime resistance. Then add the convenient pieces around it: indexers, cached APIs, dashboards, hosted frontends, notifications, analytics, and support tooling.

The point is not that Web2 infrastructure is forbidden. The point is that every convenience layer should be optional, replaceable, or at least honestly labeled. If an indexer goes down and your "decentralized" app stops working, the indexer is not just infrastructure. It is part of the product.

Bruno Skvorc covered this idea in a WebSummerCamp talk. The examples are Web3-flavored, but the lesson applies to any product that claims resilience.

What the talk is useful for

separating protocol guarantees from UX shortcuts
deciding which parts of an app must keep working without your server
spotting when managed infrastructure has quietly become a trusted middleman
explaining why a clunky but resilient first version can be a better base than a polished centralized shell

The practical version

A progressively centralized app can start ugly but hard to kill: on-chain state, local verification, export paths, static fallbacks, and clear recovery options. Then you add the comfortable parts one by one.

That order matters. It keeps the product honest. Users can still get the speed and polish of a normal app, but the core promise does not vanish the moment a hosted API, dashboard, or vendor account fails.