A decentralized platform is easier to evaluate when you stop treating decentralization as a single feature. An application may publish its interface to a peer-to-peer network while depending on one administrator, one hosted API, and one domain account. That combination can still be useful. The problem is describing it as though every dependency has disappeared.
This guide proposes a practical architecture review for a small team building a public application. The goal is not to maximize the number of protocols in the stack. It is to identify which parties can change the application, stop its delivery, observe its users, or prevent an exit. With those boundaries visible, you can choose decentralization where it solves a real problem and retain simpler components elsewhere.
Start with the action a user takes
Pick one important journey, such as opening a membership dashboard and submitting a vote. Draw every dependency involved, beginning with the browser. Include the domain resolver, interface host, wallet, RPC endpoint, indexer, contract, and any external data source. A component belongs on the diagram even when another vendor manages it.
For each arrow, describe the information crossing the boundary. A wallet might provide an address, an RPC endpoint might return a balance, and a contract might accept a signed transaction. Avoid a diagram that only names brands. You need to know which data is authoritative and which component merely presents a convenient interpretation.
Separate reading from writing
Reading application state and changing it have different failure modes. A stale indexer can show an incorrect status without changing the underlying contract. A compromised signing flow can authorize an unintended action. Label both paths separately so a successful page load does not count as proof that the entire application works.
Map five layers of control
Use five layers: interface delivery, identity and authorization, execution, data availability, and administration. These are review categories, not a claim that every application must implement five separate systems. Your existing application may combine several layers in one service.
Ethereum's technical introduction to decentralized applications describes a dapp as an application combining a smart contract and a frontend interface. That distinction is a useful starting point: decentralized execution does not automatically establish how the interface is hosted or who controls the surrounding services.
Give every layer an owner and a replacement path. For interface delivery, record who can publish a new release. For identity, distinguish possession of a key from permission to perform a specific action. For execution, identify contract addresses and upgrade authority. For data, identify the parties retaining necessary records. For administration, name the accounts and approval process that can change everything else.
Ask a control question, not a branding question
Instead of asking whether a service calls itself Web3, ask what happens when its operator declines your request. Can another implementation serve the same content? Can users submit a transaction through another endpoint? Can the team rebuild the interface without access to the original dashboard? Answers are more useful than a label.
Write down the trust assumptions
A trust assumption is a condition your system depends on but does not independently enforce. Examples include trusting an administrator not to replace a release, trusting an indexer to return complete results, or trusting an external data publisher to report honestly. Write these assumptions in ordinary language that a product owner can review.
Then connect each assumption to a consequence. A compromised content publisher could alter the interface. A failed indexer could hide recent activity. A lost domain account could interrupt the familiar entry point. This approach prevents the team from discussing all risks as though they were equally severe.
Propose a control for the consequential assumptions. Independent release review, reproducible builds, endpoint switching, and documented recovery access are examples worth evaluating. These measures do not create guarantees by themselves. Define a test that would show whether each proposed control is actually usable.
Decide what belongs on a shared ledger
Start with the information that multiple parties need to verify without accepting your private database as the final authority. Ownership records, explicit permissions, and commitments to a release may fit that requirement. Large media files, temporary sessions, and private support messages deserve separate consideration rather than automatic publication.
For every candidate record, ask three questions: who needs to read it, who needs to change it, and what happens after an error? A public record may be inappropriate for information that must remain confidential or be removed later. Treat those requirements as architectural constraints before choosing a storage mechanism.
For a hypothetical membership application, the first prototype could keep membership authorization in a contract while publishing a static interface separately. Its editorial content could remain in a version-controlled repository. That is a proposed design, not a universal recipe. Compare it with a conventional service using the same user journey and recovery requirements.
Measure resilience by removing dependencies
A resilience review should include a controlled failure exercise. In a staging environment, block the primary RPC endpoint and reload the interface. Check what the user sees, whether the alternative endpoint is actually independent, and whether switching changes the reported state. Record the result rather than simply checking a box labelled redundancy.
Repeat the exercise with the usual interface host unavailable. Test a saved release through another delivery route. Then temporarily remove the preferred indexer. Decide which parts of the application can operate without it and make the limitations visible in the interface.
Administrative recovery needs its own exercise. Ask a teammate who did not prepare the release to locate the source, identify the deployed version, and follow the rollback instructions. A procedure that only its author understands is still a concentrated dependency.
Budget for the whole operating model
Compare complete operating scenarios instead of isolated transaction fees. Include interface delivery, retained data, RPC access, monitoring, incident response, deployment review, and the engineering effort required to maintain alternatives. Describe assumptions beside each line so the estimate can be revised when usage changes.
A useful planning model has a normal week, a release week, and an incident week. In the incident scenario, include the work of moving to a second operator and communicating the new entry point. An apparently inexpensive architecture can become expensive when every change requires manual coordination across several unfamiliar systems.
Also price the exit. Ask whether your team can export application data, reconstruct derived indexes, rotate credentials, and republish the interface. The VPS architecture guide helps separate ordinary server operations from marketplace coordination. The IPFS guide covers content distribution and retention as a different layer.
Turn the review into a release decision
Create a one-page decision record with the user journey, required guarantees, retained dependencies, rejected alternatives, and next review trigger. Include an explicit statement of what the application does not protect against. This is more actionable than an unexplained decentralization score.
For example, a team might accept one indexer for a prototype while requiring a documented reconstruction procedure before a public launch. Another team might prioritize independent interface mirrors because read-only access is its main requirement. Different priorities can reasonably lead to different architectures.
Assign a person to each unresolved dependency and define an observable acceptance test. “Improve resilience” is too broad. “Demonstrate that a second operator can serve the previous release without the primary account” produces evidence. Keep failed exercises in the record; they identify the work remaining before a stronger claim is justified.
Conclusion: make dependencies visible
A useful decentralized platform review ends with a clearer operating model, not a longer technology list. Map the real user journey, distinguish presentation from authoritative state, identify administrative powers, and rehearse replacement paths. Keep ordinary infrastructure where it meets the requirement, and distribute control where a specific failure would otherwise be unacceptable.
Next, use the IPFS publishing walkthrough to examine one delivery path in detail, then read the recovery planning guide to turn architectural intentions into a repeatable exercise. The standard to aim for is understandable, testable independence—not an unsupported promise that no dependency remains.
