Three surfaces. Three readers. Three separate ways to lose them.
A protocol marketing site, a documentation set and an application front end are different products with different jobs, and most teams ship them as one. We build all three, we build them to survive a traffic spike and a red day, and we do not pretend the hero image is the hard part.
The site, the docs and the app are not the same thing.
They get conflated because one designer made all three in the same file the weekend before a launch. Each has a different reader, a different definition of success and a failure mode that does not overlap with the others at all.
The marketing site
The reader arrived from a link and knows nothing. Success is a claim they can repeat to somebody else an hour later.
The failure mode is explaining the mechanism before the point. They leave understanding your architecture and not your purpose, which is the most expensive kind of bounce because it looks like engagement.
The documentation
The reader already believes you and now needs to act. Success is a working integration without them asking a human anything.
The failure mode is drift. Docs get written once at launch, the contracts move, and every stale snippet becomes a support ticket, then a trust problem, then a reason somebody integrates a competitor.
The dApp front end
The reader has funds and is about to do something irreversible. Success is that the irreversible thing feels legible and under their control.
The failure mode is designing only the happy path. The interface is beautiful until a transaction hangs for four minutes, and then it is silent, and silence is where users decide you are not serious.
The consequence is that these three should share a design system and very little else. Different cadences, different hosting, different dependency policies. A marketing copy change should never be able to take down a swap interface, and it can.
What a protocol site has to do in eight seconds.
Eight seconds is generous. Most visitors arrive from a post, on a phone, mid scroll, deciding whether to keep reading rather than whether to buy.
The most common failure is the hero that says nothing. The liquidity layer for the onchain economy describes about four hundred projects and commits to none of them. If a competitor could paste your headline onto their own site and have it still be true, it is not a headline, it is decoration.
The second is no proof. Crypto readers have been lied to for a decade and they scan for verifiable things: an audit report, a live contract address, a dashboard, a repository with recent commits, an explorer link. One real artifact above the fold outperforms three paragraphs of adjectives.
Name the category
A perps exchange, a restaking protocol, a tokenized credit platform. Readers file you before they evaluate you, and if you refuse to be filed they file you as noise.
Name the reader
Traders, developers, treasuries, collectors, allocators. Saying who it is for is also saying who it is not for, which is the line most teams cannot bring themselves to write.
Make one claim
One sentence about the outcome, not the mechanism. Nobody repeats your architecture. They repeat what it lets them do that they could not do before.
Show proof
Audit status, addresses, live numbers pulled from chain, code, backers. Anything a skeptic can independently check in under a minute.
Offer one action
Launch app, read docs, join the community. One primary action per audience, not six buttons that look equally important and therefore are not.
Documentation is a growth channel. Almost nobody funds it like one.
Docs are the highest intent surface a protocol owns and the lowest line in its budget. The developer reading your quickstart at two in the morning is closer to integrating than anyone who ever clicked an ad, and the page they are reading was last accurate two releases ago.
What good docs do
They carry long tail search traffic for years at no marginal cost, and they are increasingly the material language models quote when a developer asks an assistant how to integrate with you. Accuracy is a distribution question now, not just a support one.
They also remove you from the loop. Every question the docs answer is one that does not arrive as a midnight direct message, and every question they fail to answer arrives twice.
What we build into a docs set
A quickstart that reaches a working call in under ten minutes. Snippets tested in CI so drift breaks the build instead of the reader. A canonical addresses page listing every deployment and its chain. A revert reason and error reference, which almost nobody writes and every integrator wants. Versioning that keeps old releases readable, and a public changelog with dates on it.
Docs belong in the same repository as the code and should be reviewed in the same pull request, because that is the only mechanism anyone has found that keeps them true. Written by the engineer who built the thing, edited by someone who did not. The second half is what gets skipped and what makes them readable.
The craft is in the states nobody puts in the demo video.
Anyone can design a swap card. The work is what happens when the wallet is the wrong one, the chain is the wrong one, the RPC is down, the estimate is wrong, or the user closed the tab and came back. This is the list we build against.
Connect, and the multi wallet reality
Several extensions fight over the same injected provider, mobile users arrive through in app browsers and deep links, smart accounts behave differently from externally owned accounts, and hardware wallets sign slowly enough to break naive timeouts. Support the standards, remember the last wallet used, and never fire a connect prompt on page load, because that prompt asks for trust before giving a reason for it.
Chain detection and switching
Detect the connected chain, say plainly when it is wrong, and offer to switch rather than blaming the user. Handle the wallet that has to add the chain first, and the user who declines the prompt and should land back in a working read only view rather than an empty screen.
Read only before connect
Pools, prices, positions by address and a plain description of what the interface does can all render before a wallet is near the page. Read only mode is a trust device and a conversion device at once, and it gives the interface a purpose for the many visitors who never connect.
Pending, confirming, failed, dropped
Idle, simulating, awaiting signature, submitted, pending with a confirmation count, succeeded, reverted, dropped or replaced by a competing nonce, and stuck long enough to justify a speed up. Show the hash the moment it exists, link it to an explorer, and persist the state so a refresh does not destroy the user's only record of it.
Communicating cost
Show the estimate in the native asset and a fiat equivalent, and say that it is an estimate. Simulate before signing where the chain allows it, and refuse to send a transaction you already know will revert. Where fees move fast, say so. An unexplained spike between quote and confirmation reads as a bug or a scam.
Approvals and slippage
An unlimited approval as the silent default is a security decision made by a designer. Show the current allowance, offer an exact amount, support permit style signatures, and give people a visible way to revoke. Set a sensible slippage default, explain in one line what it does, and warn loudly on high price impact.
When the RPC is down
Public endpoints rate limit and fail, especially in the hour you are trending. Run multiple providers with failover, degrade to a labeled stale state with a timestamp rather than showing confidently wrong numbers, and disable write actions instead of letting someone sign against data you cannot verify.
Errors that name the actual problem
Transaction failed is not an error message, it is an apology. Insufficient ETH for gas, you need about 0.004 more is an error message. Map revert reasons and wallet errors to plain sentences saying what happened, whether funds moved and what to do next. That gap is most of your support load.
A launch page that dies under traffic is a marketing failure, not an engineering one.
Web3 traffic does not arrive as a curve. It arrives as a five minute vertical line because one large account posted your link, and that five minutes is the entire return on the campaign that bought it.
Static first, edge hosted, no origin in the hot path. That is the default for anything with a launch date on it. Heavy client side frameworks are usually the wrong choice here, and the argument is not ideological: shipping a megabyte of JavaScript so a static page can hydrate itself back into the same static page costs you the slowest devices in your audience, and in a global crypto audience those are a large share of the total.
Reserve the framework for the application front end, where component state, live data and wallet sessions justify the weight. On the marketing side the wins are unglamorous: subset the fonts, serve modern image formats at the size they render, defer everything non critical, and audit the analytics, chat and pixel scripts a growth team quietly added. That is usually where the load time is hiding.
A legal question before it is a design question.
In the United States, accessibility claims against websites under the Americans with Disabilities Act are a steady category of litigation, and having a token does not exempt you. In Europe, the European Accessibility Act brought obligations into effect for many consumer facing digital services in June 2025.
We build to WCAG 2.2 AA. Keyboard operable navigation and modals, visible focus states that were not deleted for looking untidy, contrast that survives a dark interface full of gray on gray secondary text, text that reflows at 200 percent zoom, motion that respects a reduced motion preference, and status changes announced to assistive technology rather than only animated.
One crypto specific point: never encode meaning in color alone. A price that is only green or red, or a status that is only a colored dot, is invisible to a meaningful share of your users. Add the sign, the arrow, the word.
Keyboard and focus
Every wallet modal, dropdown and confirmation reachable and escapable without a mouse, with focus trapped correctly and returned where it started.
Contrast on dark
Dark interfaces are where contrast failures hide. Secondary text, disabled states and chart labels are the usual offenders and the easiest to fix.
Announced state
A transaction moving from pending to confirmed belongs in a live region, not communicated only by a spinner that stops turning.
Most user losses start at the front end, not in the contract.
This is the awkward part of the industry conversation. Enormous attention goes to contract audits, which matter, while a large share of real losses trace back to hijacked domains, compromised front ends, malicious dependencies and approval phishing. We do not audit contracts. We harden the surface the attacker actually uses, because it is the surface we build.
Policy and dependencies
A real content security policy rather than one loosened until the console went quiet. Integrity checks on anything external. A small, pinned, lockfile committed dependency tree, because a package that reaches the wallet path is a package that can drain it, which is the route recent supply chain attacks have taken.
We never touch keys
Nothing we build asks for, stores or transmits a private key or a seed phrase. Signing happens in the wallet. No custody, no clever recovery feature. An interface that asks for a seed phrase is either compromised or built by someone who should not be building it.
Registrar and DNS lockdown
Registrar lock, DNSSEC where the registry supports it, hardware backed two factor on registrar and DNS accounts, and those accounts on addresses that are not the shared inbox half the Discord already knows. Domain takeover is the cheapest attack in this industry and the one most teams have done nothing about.
Phishing resistant conventions
One canonical domain, repeated until it is boring. Contract addresses in a single authoritative place. A public rule that the team never sends the first direct message, so a fake one is self evident. Monitoring for lookalike domains and impersonation accounts, with a rehearsed process for reporting them.
Deployment discipline
Protected branches, reviewed merges, no direct pushes to production, no secrets in client bundles, and access reviewed when someone leaves. Most compromised front ends were not clever attacks. Somebody simply kept their access after they stopped working there.
An incident plan that exists
Written before you need it. Who can take the site down, who posts, where the status update lives if the domain itself is the problem, and what the first message says. Six hours of silence during an incident costs more trust than the incident.
Measure enough to learn. Not enough to become a liability.
Crypto users are unusually hostile to tracking and unusually right to be. A wallet address is a permanent, public, cross referenceable identifier, so pushing one into a third party advertising pixel is not analytics, it is deanonymising your own users for someone else's benefit.
We default to cookieless or self hosted analytics, define the event taxonomy before launch instead of bolting it on later, and keep product analytics separate from anything that could join a wallet address to a personal identity. The questions worth answering are which entry points produce connected wallets, where the funnel drops between connect and first transaction, and which failure state users hit most. None require knowing who anyone is.
You own all of it.
Domain, registrar, DNS, hosting, repository, design files, component library, content and analytics, in accounts registered in your name from day one rather than sitting in ours until a transfer at the end. No proprietary CMS you have to keep paying us to use, no build step only we can run.
Handover includes a written architecture note, the deploy process, the dependency policy, the design system documentation and a session with whoever takes it on. If you want us to keep maintaining it we are available. That should be a decision you make, not a position we put you in.
Questions we get, answered properly.
Do you write or audit the smart contracts behind the front end?
No. We do not write contracts, deploy them or audit them. We build the interface that reads from them and writes to them, working against your ABIs alongside your engineers or your audit firm. Where you still need contract work we introduce firms we have watched deliver, and we hold the schedule so the interface and the code are ready in the same week.
Should the marketing site, the docs and the app share one codebase?
Almost never. They have different readers, different release cadences and different risk profiles. The marketing site changes weekly and should be static at the edge. The docs change with every release and belong beside the code so they get reviewed with it. The app carries real user funds and needs a stricter dependency and content security policy. Share the design system across all three. Share a deploy pipeline and a copy change can take down the swap interface.
What transaction states does a serious dApp front end handle?
At minimum: idle, simulating, awaiting signature, submitted with a hash, pending with a confirmation count, succeeded, reverted with a reason, dropped or replaced by a competing nonce, and stuck long enough to justify a speed up. Most interfaces demo the happy path and go silent when something hangs. The hash should appear the instant it exists, the state should survive a refresh, and a revert should name the requirement that failed.
How do you handle security if you do not touch the contracts?
By hardening the surface attackers actually use. Most user losses in this industry trace to front end compromise, domain and DNS takeover, malicious dependencies and social engineering rather than to a flaw in an audited contract. So we ship a real content security policy, keep the dependency tree small and pinned, never handle a private key or seed phrase, lock the registrar, enable DNSSEC, and publish contract addresses in one canonical place.
Is accessibility really a requirement for a crypto product?
Yes, on two counts. Accessibility claims against websites under the Americans with Disabilities Act are a live category of litigation in the United States, and the European Accessibility Act brought obligations into effect for many consumer facing digital services in June 2025. Practically, WCAG 2.2 AA work fixes problems every user has: visible focus states, keyboard operable menus, contrast that holds on a dark interface, and status announced rather than only animated.
What do we own at the end, and how long does a build take?
You own all of it. Domain, DNS, registrar, hosting, repository, design files, component library and content, in accounts registered in your name from day one rather than transferred out of ours at the end. There is no proprietary CMS you have to keep paying us to use. A marketing site is typically three to five weeks with docs alongside it. An app front end depends on how many contract interactions it exposes. You get one fixed number after a scoping call.
Nothing on this page is financial, investment, legal or tax advice. Orca Web3 provides brand, design, content and front end engineering services. We do not write, deploy or audit smart contracts, we do not provide market making, and we do not offer or promote any token or investment.
Send us the thing you are about to launch.
A scoping call is thirty minutes and ends with a straight answer on what the site, the docs and the front end should each be, what they cost as one fixed number, and whether we are the right team to build them. If we are not, we will say so and point you at someone who is.