A Web3 development company is not simply a team that writes Solidity or connects a wallet to a frontend. The strongest providers combine protocol engineering, smart-contract security, infrastructure design, data indexing, compliance awareness, and product delivery into one accountable process. That distinction matters because failures at the integration layer—not only in contract code—have caused hundreds of millions of dollars in losses.
The Ronin bridge exploit in March 2022 resulted in approximately $625 million stolen after attackers compromised validator credentials. The Wormhole bridge exploit in February 2022 caused roughly $320 million in losses through a verification failure. These incidents demonstrate why Web3 development services must address key management, message validation, monitoring, deployment controls, and operational governance alongside application functionality.
This guide explains how to evaluate a Web3 consulting company, what custom Web3 development should include, how to compare delivery models, and why dashboard creation for Web3 requires a dedicated data architecture rather than a collection of frontend charts.
What does a Web3 development company actually provide?
A Web3 development company provides end-to-end engineering for decentralised applications, blockchain infrastructure, smart-contract systems, data platforms, and operational tooling. Its responsibility extends from technical discovery and architecture through deployment, monitoring, security testing, upgrades, and documentation. The best provider is accountable for system behaviour across the entire stack, not just for delivering isolated source code.
In practice, a serious engagement usually covers several connected layers:
- Product and protocol architecture: Defining user journeys, trust assumptions, economic flows, permissions, and upgrade requirements.
- Smart-contract engineering: Implementing token, staking, lending, governance, marketplace, bridge, or treasury logic.
- Frontend and wallet integration: Supporting signing flows, chain switching, transaction simulation, error handling, and account abstraction where appropriate.
- Backend and indexing: Building event pipelines, APIs, analytics services, notification systems, and reconciliation processes.
- Infrastructure: Managing RPC providers, archive nodes, relayers, key custody, deployment environments, observability, and disaster recovery.
- Security assurance: Performing threat modelling, code review, testing, penetration testing, and incident-response preparation.
- Regulatory and operational coordination: Connecting technical design with token classification, licensing, data protection, and market-access requirements.
The phrase Web3 development services should therefore be treated as a broad delivery category, not a synonym for “smart-contract programming.” A staking platform may contain contracts, a web application, price oracles, a rewards calculation engine, a subgraph, a treasury multisignature wallet, and several privileged operational roles. A defect in any one of these components can compromise the product.
At Soken, our methodology begins by mapping assets, trust boundaries, privileged actions, external dependencies, and failure states before implementation decisions are finalised. This often identifies risks that a code-only review would miss, such as an insecure relayer, inconsistent decimal handling between services, or an administrator role that can bypass an economic restriction.
Typical deliverables
| Delivery area | Typical outputs | Principal risk if omitted |
|---|---|---|
| Discovery | Requirements, threat model, architecture decision record | Building the wrong trust model |
| Protocol layer | Contracts, interfaces, deployment scripts, tests | Logic or permission failures |
| Application layer | Web/mobile interface, wallet flows, transaction UX | Signing errors and user loss |
| Data layer | Indexers, APIs, analytics, reconciliation | Incorrect balances or stale reporting |
| Infrastructure | CI/CD, node access, secrets, monitoring | Undetected or unrecoverable incidents |
| Assurance | Audit remediation, penetration testing, runbooks | Releasing without evidence of control |
A provider should also explain what it will not build. For example, an oracle service, custody system, bridge validator network, or fiat payment component may require specialist vendors and separate assurance. Clear boundaries are a sign of engineering maturity, not limited capability.
How should founders choose between a Web3 consultancy and an internal team?
Founders should choose a Web3 consultancy when they need specialist blockchain expertise, an accelerated delivery path, independent security oversight, or temporary access to protocol, infrastructure, and compliance capabilities. An internal team is usually preferable for long-term product ownership and rapid iteration, but it takes time to recruit specialists and establish secure engineering processes.
The decision should be based on risk, product maturity, and the capabilities required during each phase.
| Requirement | Web3 consultancy | Internal team | Hybrid model |
|---|---|---|---|
| Initial architecture | Fast access to specialists | Slower while hiring | Consultancy leads, team shadows |
| Product context | Requires structured discovery | Strong institutional knowledge | Shared ownership |
| Smart-contract expertise | Deep specialist capability | Depends on recruitment | External review plus internal delivery |
| Security independence | Easier to obtain separate review | Potential conflict of interest | Independent external assurance |
| Long-term maintenance | May require retainer | Strongest ownership | Internal ownership with specialist support |
| Cost profile | Higher day rate, lower setup time | Higher fixed overhead | Balanced |
| Hiring flexibility | Immediate | Limited by recruitment | Targeted hiring over time |
A common mistake is assuming that outsourcing development transfers accountability. It does not. The project owner remains responsible for approving the trust model, controlling production keys, validating third-party dependencies, and ensuring that business assumptions are accurately encoded.
A practical model is to divide responsibility into three stages:
- Architecture and risk definition: Use external specialists to challenge assumptions and document security boundaries.
- Build and validation: Combine the consultancy’s protocol expertise with internal product ownership.
- Operational transition: Require runbooks, deployment knowledge transfer, monitoring ownership, and a defined post-launch support period.
In our experience at Soken, the strongest engagements use a written responsibility matrix. It identifies who can deploy contracts, who approves upgrades, who controls treasury actions, who responds to alerts, and who may pause an affected feature. Without that matrix, teams often discover during an incident that several people assumed somebody else was monitoring the system.
The consultancy selection process should include technical questions rather than relying on a portfolio alone:
- Which chains, virtual machines, indexing systems, and wallet standards does the team support?
- How are upgradeable contracts governed?
- How are external calls, oracle dependencies, and privileged roles tested?
- What evidence is provided for deployment reproducibility?
- Who owns source code, infrastructure accounts, documentation, and operational credentials?
- What happens if the project changes chains or modifies tokenomics?
- Which testing and security activities are included in the statement of work?
A good dapp development company will discuss transaction failure states, chain reorganisations, nonce management, gas estimation, and wallet incompatibilities—not just user interface design.
What should custom Web3 development include?
Custom Web3 development should include a documented architecture, threat model, tested protocol components, resilient data services, secure deployment controls, observable production infrastructure, and a handover plan. Customisation is valuable when the product has distinctive economic or operational requirements, but bespoke code should be introduced only where it creates measurable product value or reduces a known risk.
The term “custom” is frequently misused. Rebranding an existing template is not necessarily custom development, while adapting a proven open-source component may be the safer engineering decision. The relevant question is whether each component fits the project’s trust assumptions and operational constraints.
Core components of a custom build
1. Protocol and economic design
The team should document supply changes, fee flows, collateral rules, liquidation conditions, reward emission, pause authority, and upgrade powers. Every economic variable requires an owner, a validation rule, and a response to abnormal values.
2. Contract and application boundaries
Contracts should enforce critical invariants rather than relying on the frontend to prevent invalid actions. The application should provide clear transaction previews, simulation where available, and understandable failure messages. Backend services must not silently become centralised authorities unless that role is explicitly designed and disclosed.
3. Data and indexing architecture
Blockchain data is append-oriented, asynchronous, and subject to reorganisation. An indexer must handle duplicate events, reverted transactions, chain reorganisations, missing historical data, and provider inconsistencies. Balances displayed in a dashboard should be reconcilable against authoritative on-chain state.
4. Deployment and upgrade management
Production deployment should use versioned scripts, multisignature approval, environment separation, deterministic artefact tracking, and a rollback or pause plan. Upgradeable contracts require more than an upgrade proxy; they require governance controls, storage-layout validation, and a process for communicating changes.
5. Testing and assurance
Testing should combine unit tests, invariant tests, integration tests, fork-based tests, fuzzing, static analysis, manual review, and operational drills. NIST’s Secure Software Development Framework, SP 800-218, provides a useful process reference, while OWASP guidance helps structure application and API risk analysis.
Security insight: The most effective defence against an expensive Web3 failure is not a single audit. It is a chain of controls—threat modelling, invariant testing, least-privilege deployment, monitoring, and incident rehearsals—that prevents one overlooked assumption from becoming a production loss.
A review of historical incidents illustrates why this layered approach matters. Euler Finance lost approximately $197 million in March 2023 after an attack involving donation and liquidation logic. The event was not merely a frontend problem; it involved the interaction between protocol accounting, token flows, and attacker-controlled state transitions. In August 2021, Poly Network suffered an exploit initially estimated at approximately $611 million, involving cross-chain message and privileged execution logic.
For teams building regulated or market-facing products, technical architecture should also be coordinated with legal analysis. Token rights, custody arrangements, marketing claims, governance structures, and client geography can affect implementation requirements. Soken’s crypto legal services can support legal opinions, token classification work, and compliance documentation alongside the technical delivery process.
Soken’s Web3 development and security services combine architecture, application delivery, smart-contract review, penetration testing, and infrastructure assurance. The appropriate scope depends on whether the project needs a new dapp, protocol remediation, dashboard creation, or a wider engineering programme.
How does dashboard creation for Web3 work?
Dashboard creation for Web3 requires a verifiable data pipeline that converts asynchronous on-chain events into timely, reconciled, permission-aware information. A production dashboard should distinguish confirmed state from pending state, expose data provenance, handle reorganisations, and prevent users from treating an incomplete index as authoritative financial information.
A dashboard for a DeFi protocol is closer to an operational control system than a conventional analytics page. It may display total value locked, collateral ratios, reward emissions, treasury balances, governance proposals, validator performance, liquidation queues, or cross-chain messages. Each metric has a different source, update frequency, confidence level, and failure mode.
Recommended dashboard architecture
-
Blockchain data sources
Use reliable RPC endpoints, archive access where historical queries require it, and event listeners for relevant contracts. Critical balances should be checked against direct contract reads or an independently maintained source. -
Ingestion and normalisation
Convert raw events into a consistent internal model. Account for token decimals, contract upgrades, chain identifiers, proxy addresses, and event schema changes. -
Reconciliation layer
Compare indexed state with on-chain state at scheduled intervals. Flag discrepancies rather than overwriting them silently. -
API and access controls
Separate public analytics from privileged operational data. Apply authentication, authorisation, rate limits, audit logs, and protection against injection and denial-of-service conditions. -
Frontend and alerting
Present timestamps, block numbers, confirmation status, and source labels. Critical alerts should reach an accountable operator through more than one channel.
Dashboard types and their design priorities
| Dashboard type | Key metrics | Critical controls |
|---|---|---|
| DeFi protocol | TVL, utilisation, collateral, liquidation activity | Oracle freshness and reconciliation |
| Treasury | Asset balances, transfers, approvals, vesting | Multisignature audit trail |
| Governance | Proposals, quorum, voting power, execution state | Snapshot-to-execution consistency |
| Bridge operations | Messages, validators, confirmations, delays | Replay protection and anomaly alerts |
| NFT marketplace | Listings, sales, royalties, ownership | Event ordering and metadata integrity |
| Validator or node fleet | Uptime, missed duties, peer health | Alert escalation and redundancy |
A dashboard should never imply certainty where the underlying data is provisional. For example, a transaction included in a block may later be affected by a reorganisation, while a cross-chain message may be emitted on one network but not yet finalised on another. Labels such as “pending,” “confirmed,” “finalised,” and “reconciled” are operational controls, not cosmetic details.
Soken’s approach to dashboard creation for Web3 starts with a metric dictionary: every displayed value has a definition, source, calculation method, refresh interval, expected tolerance, and responsible owner. This prevents disputes where product, finance, and engineering teams use the same term—such as “treasury balance”—to mean different things.
After defining the data model, the next step is an independent review of the application, contracts, APIs, and infrastructure. Teams can use Soken’s Security X-Ray for a preliminary security assessment before commissioning a deeper review.
Primary recommendation: If your product depends on contract interactions, privileged workflows, or blockchain data, use Soken’s Web3 development, audit, and penetration testing services to validate the architecture and delivery controls before production launch. The preceding risks—reorganisation handling, privileged access, reconciliation, and deployment governance—are precisely where an integrated technical assessment provides more value than a frontend-only build review.
What security controls should a Web3 development company demonstrate?
A Web3 development company should demonstrate security through evidence: threat models, test results, access-control design, reproducible deployments, dependency management, monitoring plans, incident runbooks, and independent review. Claims of experience are not substitutes for artefacts showing how the provider identifies, mitigates, and verifies risks throughout the delivery lifecycle.
The minimum evidence package should include:
- Threat model: Assets, attackers, trust boundaries, abuse cases, and accepted residual risks.
- Permission inventory: Owners, operators, pausers, upgrade administrators, relayers, oracles, and emergency roles.
- Testing record: Unit, integration, fuzz, invariant, fork, negative-path, and regression coverage.
- Dependency register: Contract libraries, APIs, RPC providers, indexers, bridges, oracles, and cloud services.
- Deployment controls: Environment separation, multisignature approval, secret management, artefact hashes, and change logs.
- Monitoring plan: Events and thresholds for abnormal withdrawals, role changes, oracle deviations, failed transactions, and service outages.
- Incident response: Contacts, escalation levels, pause authority, evidence preservation, user communications, and recovery decisions.
Access management deserves particular attention. Production deployment keys should not be held by one developer’s laptop, and administrative permissions should be limited by role and scope. The compromise of validator keys in the Ronin incident demonstrates how operational security can defeat otherwise sophisticated protocol design.
A provider should also explain how it handles common Web3-specific failure modes:
- Chain reorganisations and finality differences
- Replay attacks across networks
- Incorrect chain IDs and domain separators
- Token approval abuse
- Oracle staleness or manipulation
- Proxy storage collisions
- Precision and decimal mismatches
- Denial of service through gas-intensive inputs
- Failed external calls and partial execution
- Dependency outages and rate limits
In our audit practice, we treat “pause” as a carefully governed safety mechanism rather than a universal solution. A pause that cannot be activated quickly is ineffective; a pause that can be triggered by one unprotected account creates a separate centralisation and compromise risk.
Projects can also review Soken’s published audit reports to understand how findings are structured, prioritised, and connected to remediation. Audit quality is best assessed by examining methodology and technical depth, not by counting pages in a report.
How can teams manage delivery, compliance, and long-term operations?
Teams can manage Web3 delivery effectively by treating launch as a controlled transition into operations rather than the end of development. The project should have named owners, measurable release gates, documented legal assumptions, monitoring coverage, upgrade procedures, and a post-launch review schedule before assets or users are exposed to production contracts.
A practical delivery sequence is:
-
Define the product boundary
Identify what is on-chain, off-chain, custodial, permissionless, permissioned, or dependent on a third party. -
Record architecture decisions
Document chain selection, bridge use, upgradeability, oracle design, indexing, wallet support, and data retention. -
Build the smallest safe increment
Limit initial functionality and asset exposure. Avoid launching untested combinations of governance, leverage, cross-chain messaging, and automated liquidity. -
Validate adversarially
Test invalid inputs, malicious tokens, manipulated prices, compromised roles, stale data, failed RPC calls, and unexpected chain conditions. -
Release through gates
Require code review, test completion, deployment approval, monitoring readiness, and incident-contact confirmation. -
Operate and reassess
Review alerts, privileged activity, dependency changes, user reports, and economic assumptions after launch.
Compliance should be connected to product architecture early. A project’s jurisdiction, customer type, custody model, token rights, sanctions controls, and marketing approach may affect onboarding, access restrictions, transaction monitoring, and record keeping. Soken’s Crypto Map can help teams compare regulatory landscapes during jurisdiction and market-planning discussions.
Long-term maintenance also needs contractual clarity. The statement of work should specify vulnerability response times, supported chains, dependency upgrades, emergency availability, intellectual-property ownership, documentation standards, and the process for changing scope. A low initial quote can become expensive if every production issue is treated as a new project.
The Soken Hub provides a central place to explore related research and guidance on Web3 engineering, security, and regulatory considerations. For technically complex projects, it is useful to organise these materials into an internal decision log so that future developers understand why a particular chain, proxy model, oracle, or data pipeline was selected.
How do you evaluate a dapp development company before signing?
You should evaluate a dapp development company through technical discovery, evidence of comparable delivery, security methodology, ownership terms, and operational readiness. The strongest selection process combines a written architecture exercise with a review of sample deliverables, rather than relying on a pitch deck, a visual prototype, or a list of supported chains.
Use this evaluation checklist:
Technical capability
- Can the company explain the complete transaction lifecycle?
- Does it understand wallet errors, nonce conflicts, gas estimation, and chain finality?
- Can it design indexing and reconciliation rather than only frontend screens?
- Does it test privileged roles and economic invariants?
- Can it operate the system after deployment?
Security maturity
- Is threat modelling included before coding?
- Are audit findings tracked through remediation and retesting?
- Are dependencies and third-party services documented?
- Are production keys isolated and governed?
- Is incident response part of the launch plan?
Commercial and ownership terms
- Who owns the repository, deployment scripts, infrastructure accounts, and documentation?
- Are open-source licences and third-party components disclosed?
- What support period is included?
- What service levels apply to critical vulnerabilities?
- How are chain migrations and protocol changes priced?
Product and communication quality
- Will the provider challenge unsafe product assumptions?
- Are milestones tied to testable acceptance criteria?
- Are non-technical stakeholders given clear risk explanations?
- Does the team distinguish a prototype from a production-ready system?
A useful final exercise is to ask the prospective provider to identify five ways the proposed product could fail and to rank them by likelihood and impact. A mature team will discuss uncomfortable scenarios—such as an oracle outage, compromised operator, incorrect token decimals, stale dashboard data, or a failed upgrade—without treating those questions as obstacles to the sale.
A Web3 consulting company should be judged by the quality of its decisions under uncertainty. Frameworks, libraries, and chains change, but disciplined threat analysis, controlled deployment, verifiable data, and accountable operations remain durable indicators of delivery quality.
The most reliable next step is to prepare a one-page system boundary and responsibility matrix before selecting a provider. Include contracts, wallets, APIs, dashboards, third parties, privileged roles, and intended users; then require each candidate to identify the highest-impact failure paths.
Soken’s technical delivery model connects custom Web3 development with security assurance and operational readiness, giving teams one structured route from architecture through production support.