A practical evaluation of a web3 dapp development company starts with a defined project brief, then checks the proposed architecture, delivery evidence, security process, and post-launch responsibilities. Treat claims about experience, security, availability, and compliance as items to verify—not as guarantees. The goal is to establish what the company will build, what evidence it will provide, and which responsibilities remain with your organization.

Define the dapp problem before choosing a company

Describe the user need and the workflow the application should support before discussing a preferred technology. Identify the people or organizations involved, what each needs to do, and what a successful workflow looks like. Record assumptions and unresolved decisions, including who may change application rules or handle exceptional cases.

A decentralized application, or dapp, is more than a smart contract. In the Ethereum model, a dapp combines a smart contract running on a decentralized network with a frontend user interface. A broader application stack can also include wallets, client libraries, data indexing, storage, and other off-chain services. Those parts may introduce dependencies outside the contract itself. Ask a prospective company to distinguish the contract’s responsibilities from the responsibilities of the interface and supporting services. (source ; source )

For each workflow step, ask whether it needs on-chain execution or a persistent on-chain record, or whether an off-chain component can handle it. This is a product and architecture decision, not a presumption that every function belongs in a contract. When the design depends on facts that exist outside blockchain state, ask how those facts reach the contract. An Ethereum contract cannot directly obtain off-chain facts without an oracle or transaction mechanism; an oracle design adds assumptions about data quality, freshness, availability, and trust. Record those assumptions instead of leaving them implicit. (source )

Convert the workflow into acceptance criteria: observable conditions that determine whether each deliverable is complete. For every criterion, state what should happen, what evidence will demonstrate it, and what is explicitly excluded. For example, distinguish an interface that lets a user initiate an action from a requirement that the application display a resulting state. The criteria should help both parties identify an incomplete deliverable without relying on a broad phrase such as “the dapp works.”

Also separate product requirements from open governance and operating decisions. Note who is expected to administer the application, who may approve changes, and which decisions have not yet been made. If the organization has not selected an approach, ask the company to identify the options and consequences rather than presenting an unreviewed assumption as settled scope.

Turn requirements into an architecture and scope brief

Ask each prospective company to describe the proposed system in terms of contracts, user interface, wallets, data services, and external dependencies. Request a diagram or written component list showing how a user action moves through the application and which components read, submit, or process information. The purpose is to make responsibilities and dependencies visible, not to prescribe one technology stack.

For each component, ask who builds it, who operates it, and what the organization should expect if it becomes unavailable or changes. Separate contract behavior from wallet interactions, application behavior, and provider or data-service functions. This distinction helps prevent a proposal from attributing a wallet’s or provider’s behavior to the contract itself.

If a company proposes a network, wallet, or service, ask why it fits the documented requirements and request current evidence for any availability or supported-feature claim. Availability can depend on the specific network or service and may change; a proposal is not verification. The organization should confirm relevant claims against current documentation at the time it makes a decision, while noting which parts of the proposed design depend on those claims.

Keep the initial delivery distinct from later features. List integrations, additional networks, administrative tools, and future changes as included, excluded, or dependent on a separate decision. Ask the company to document assumptions, exclusions, external dependencies, and the process for proposing and approving scope changes. This makes it easier to determine whether a later request is a correction to agreed work or a new requirement.

A useful brief also records unresolved questions and assigns an owner for answering each one. For example, if the organization has not determined who will operate a data service or approve an application change, mark that as an open decision rather than allowing it to disappear from the scope discussion. Ask the company to identify dependencies that must be resolved before design, testing, or launch can proceed, without assuming that the company will take on an operational role it has not agreed to perform.

Assess a web3 dapp development company through evidence

Request examples of relevant work that can be independently checked, and ask what the proposed team—not simply the company—did on each example. A case study, credential, client reference, or claimed result is a statement to verify. It does not by itself establish an individual’s contribution or show that a similar result will occur in a different project. Where references are available, confirm their relevance and scope rather than treating a logo or broad experience claim as sufficient evidence.

Identify the people expected to handle product design, contract engineering, testing, deployment, and maintenance. Ask who makes technical decisions, who reviews work, and how responsibility changes if a named contributor is unavailable. If work will be shared with subcontractors or other parties, ask the company to state which deliverables and controls remain its responsibility and which are assigned elsewhere.

Request a sample of technical documentation, such as a component description, interface specification, test summary, or handoff checklist. Use it to assess whether the team can explain system boundaries, assumptions, unresolved issues, and the relationship between components. The sample is evidence of the documentation format the company can provide; it is not proof that the proposed project has already been designed or reviewed.

The OWASP Smart Contract Security Verification Standard offers a structured framework for designing, building, and testing EVM-based smart contracts and decentralized applications. The published standard is an early version and should be supplemented with project-specific threat modeling and review. Ask whether the company uses a defined verification framework, how it adapts that framework to the project, and what records it will deliver. A framework can organize work and questions; citing one alone does not establish that the project has been reviewed or is secure. (source )

When reviewing capability claims, ask for evidence that matches the claim. A description of a team’s process is different from project-specific records showing that the process was applied. A reference may establish that a past engagement occurred, but it does not establish that the same team or scope will be used in your project. Make the distinction explicit in procurement notes so that credentials and examples are not mistaken for project deliverables.

Check contract security and testing responsibilities

Before engagement, ask the company to explain its security process: what it reviews, what test evidence it provides, how findings are recorded, and who decides whether a finding is fixed or remains an accepted risk. Request written documentation of unresolved issues and their implications. Define review scope precisely, including which contracts, versions, integrations, and deployment configurations are covered and which are not.

Distinguish internal testing and review from an independent audit. If external review is proposed, ask who performs it, what material is in scope, what report or other evidence will be shared, and how fixes and follow-up findings are tracked. Avoid treating “audited,” a test suite, or a verification framework as proof that every relevant risk has been found. The available evidence supports the use of structured verification as a framework; it does not establish that any particular company follows it or that a specific project is safe. (source )

Clarify responsibility for security decisions. A development company may produce code and review materials, while the organization engaging it must assess whether the documented scope and remaining risks fit the intended use. Ask who can authorize deployment, what access is needed, and who is responsible for incident handling and remediation. If the proposal refers to a recovery mechanism or incident-response capability, request project-specific documentation describing its operation, scope, limitations, and responsible parties. Do not infer that the presence of a process guarantees recovery or prevents future vulnerabilities.

Make the evidence trail part of the proposed delivery. Ask how the company will identify the version of the code and configuration reviewed, connect findings to their resolution status, and communicate exceptions. These requests help the organization evaluate whether a report relates to the work being delivered. They should not be framed as a substitute for project-specific technical review or as proof that a vulnerability cannot occur.

Agree on delivery, operations, and accountability

Put deliverables, milestones, acceptance criteria, and change-control steps in writing. State what the organization receives at handoff, including source code, technical documentation, deployment materials, and access or permissions needed for ongoing work. Confirm ownership and access arrangements explicitly rather than assuming they follow automatically from completion of development.

Define post-launch work separately from initial delivery. Ask who is responsible for maintaining the application, monitoring its components, evaluating proposed upgrades, reporting incidents, and coordinating remediation. The application stack may include off-chain services as well as contracts, so the handoff should identify those dependencies and the parties responsible for them. A contract delivery alone does not specify who will operate a supporting interface, data service, or other component. (source )

Review fees and any service-level claims in the proposed agreement. Ask which work is included, what may trigger additional charges, and how a stated response or availability commitment is defined. Do not assume that providers use standard terms or that a general availability statement applies to the exact network, service, or deployment in the proposal. Record any promised service conditions in the agreement rather than relying on informal descriptions.

Treat regulatory, tax, licensing, and compliance representations as questions requiring current, relevant evidence and qualified review where appropriate. No jurisdiction-specific conclusion follows from a company’s general assertion. If such matters affect the project, identify the relevant jurisdictions and ask what documentation supports the representation, while keeping legal and tax decisions with appropriately qualified advisers.

Before authorizing work, assemble the requirements brief, architecture and dependency description, verifiable delivery evidence, security scope and findings process, and written responsibility boundaries. Check that the documents agree: a component shown in the architecture should have an identified owner, and an acceptance criterion should map to a deliverable and its evidence. If key assumptions, access rights, operational duties, or unresolved risks remain unclear, ask for clarification before engagement. This process does not select a provider for you; it makes the basis for the organization’s decision explicit and reviewable.

Sources and references