When evaluating a dapp development company, verify that it can explain the proposed architecture, provide project-relevant testing and security evidence, and define who is responsible for deployment and ongoing operations. Compare providers against the same written requirements, and treat unresolved dependencies and unsupported assurances as open risks—not as proof of capability.

Define the dapp’s scope before contacting providers

A decentralized application, or dapp, combines a smart contract running on a decentralized network with a user-facing interface. A broader application stack may also include blockchain nodes, wallets, client libraries, indexing, storage, and other off-chain services. Not every dapp uses every component, and some may depend on centralized providers for parts of the stack. Start by recording which functions users need and which components the project expects to rely on. source source

Write down the intended users, workflows, supported networks, and integrations. Identify what must happen on-chain and what can happen through an interface, API, or other off-chain service. If the application needs facts that are not present in blockchain state, ask how they will enter the system: an Ethereum smart contract cannot directly obtain off-chain facts without an oracle or transaction mechanism. The design therefore depends on the chosen input path and its assumptions. source

Define success in observable terms: required user actions, expected integrations, documentation, and the responsibilities that must be covered after launch. Note expected administrative roles, permissions, and upgrade needs as questions for the proposal; do not presume that a particular architecture is necessary. This scope gives each company the same basis for describing its approach.

Assess a dapp development company’s technical approach

Ask the company to walk through how a user action moves from the interface to any wallet interaction, contract call, and supporting service. Request a diagram or written explanation that identifies which parts run on-chain and which depend on off-chain systems. The purpose is not to favor a specific stack, but to see whether the proposal makes its boundaries and dependencies understandable.

For each proposed network and integration, ask what project requirement it serves and what evidence supports the choice. If external data is involved, ask who supplies it, how the contract receives it, and which data-quality, freshness, availability, and trust assumptions remain. An oracle connects off-chain data or services to smart contracts; it does not make those inputs inherently correct or eliminate the need to examine their design. source

Clarify who controls and maintains repositories, deployment permissions, documentation, and third-party service accounts. Ask how the work will be handed over and what information another team would need to operate it. For projects that may change protocol-level behavior, distinguish application development from network governance: Ethereum protocol changes involve proposal, technical review, implementation, coordination, and adoption across network stakeholders. A project provider’s ability to build an application should not be treated as authority over a network’s upgrade process. source

Verify testing and security evidence

Ask for a testing and review plan tied to the project’s stated requirements. It should identify what components are covered, what kinds of tests or reviews are planned, how results and findings will be documented, and how unresolved findings will be handled. Request evidence relevant to the actual scope rather than a general statement that the code is “tested.”

If independent security review is proposed, clarify what is in scope, what is excluded, and whether fixes and follow-up review are included. The OWASP Smart Contract Security Verification Standard provides a structured framework for designing, building, and testing EVM-based smart contracts and decentralized applications. It is an early version and should be supplemented with project-specific threat modeling and review. A framework or audit report is evidence of a process within a defined scope, not a guarantee that a system is safe. source

Require specific support for claims about security, key management, or recovery. Ask which organization or role controls each relevant credential or permission, what recovery procedures are documented, and what conditions could prevent recovery. If the proposal does not provide enough detail to verify an assurance, record it as unresolved rather than inferring a security property.

Map deployment and post-launch responsibilities

Before selection, document who approves deployments, who holds or uses deployment permissions, and who maintains the application’s contracts and supporting services. Ask how proposed changes, upgrades, outages, and vulnerability reports would be handled, including the party responsible for each step. The answers should identify operational boundaries, not simply promise continuing support.

List external dependencies and ask what happens if each becomes unavailable, changes its behavior, or requires a different integration. For a system that relies on off-chain inputs, clarify who operates the input service and how its availability and trust assumptions are addressed. Avoid assuming that a contract can independently resolve external facts or that an on-chain component removes the need to manage off-chain services. source source

If a provider makes availability, fee, or service-level claims, request current, written evidence for the specific proposed service and circumstances. Do not treat marketing language as a universal commitment. Record what the provider has committed to, what remains dependent on third parties, and what has not been verified.

Identify the jurisdictions relevant to the organization, its users, the provider, and the application’s operation. Ask the provider to distinguish technical work from any legal or compliance support it claims to offer. Require current, project-specific evidence for those claims, and have qualified professionals assess obligations that depend on the facts and location. This guide does not determine whether a project complies with any law or regulation.

Similarly, verify geographic availability for the specific service rather than relying on a general statement. Record the relevant jurisdictional assumptions and any open questions for professional review. Do not treat a provider’s technical proposal as a substitute for that review.

Compare proposals against a documented decision record

Use the same scope, questions, and evidence requests for every proposal. A decision record can summarize each company’s proposed architecture, supporting evidence, maintenance boundaries, dependencies, exclusions, and unresolved risks. Separate confirmed documentation from statements that still need verification.

Before proceeding, identify conditions that must be met, such as clarifying an integration, documenting access responsibilities, or obtaining review of an unresolved security concern. If a company cannot explain a key dependency or support an assurance with relevant evidence, keep that item open and consider pausing the decision. A clear record helps the organization compare proposals without relying on rankings or marketing claims alone.

Sources and references