Ship It Live — $1,999 flat
Design + build + deploy · kickoff in 24h · limited slots
Ship It Live · web3 sprint
A web3 product normal people can use, live in 30 days.
Wallets, signing and gas explained in the interface instead of assumed. Most web3 products fail on usability, not on chain.
Quick answer
A crypto or web3 app can be designed, built and live in 30 days for a fixed $2,500, covering wallet connection, on-chain reads, transaction flows with clear cost and confirmation, and a portfolio or activity dashboard. Writing and auditing new smart contracts is a separate, specialist engagement.
The plan
Day one to day 30, written down.
You get this schedule before you commit, not after. If a phase slips, that is mine to absorb — the price and the date were agreed before anything started.
- 1
Days 1–3
Scope and chain
Which chain, which contracts, and what the user is actually trying to do. Also what happens when a transaction fails, which is where the design work really is.
- 2
Days 4–12
Design
The transaction flow first, because irreversibility changes every rule about confirmation. Then the dashboard and onboarding for people who have never held a wallet.
- 3
Days 13–24
Build
Wallet integration, contract reads and writes, and the state machine around a pending transaction. Testnet throughout, with real signing tested early.
- 4
Days 25–28
Break it deliberately
Rejected signatures, wrong network, insufficient gas, dropped transactions, replaced nonces. Users will hit all of these, so they get designed rather than discovered.
- 5
Days 29–30
Launch
Mainnet, monitoring on, and a handover covering what to watch for in the first week.
What $2,500 gets you
Everything needed to launch — nothing padding the invoice.
Who books this
Built for
Web3 teams whose protocol works and whose front end scares people off
Founders building on existing contracts who need a real product around them
Projects whose users are currently interacting through a block explorer
Real situations
Five ways this shows up, and what actually fixes it.
Not hypothetical — the shape of the problem before someone books this sprint, and the specific part of the build that resolves it.
Situation 1
A protocol that works, a front end that scares people off
A web3 team has functioning smart contracts, but the interface around them assumes users already understand wallets, gas and signing — which most potential users don't.
Wallet connection, plain-language on-chain reads, and transaction flows that explain cost before signing make the protocol usable by non-experts.
Situation 2
Users interacting through a block explorer because nothing else exists
A project's only current interface is a raw block explorer, forcing users to interpret contract calls and hashes directly instead of a real product experience.
A proper dashboard renders holdings and activity in plain language, replacing the block explorer as the actual user-facing product.
Situation 3
Transactions fail silently and users think the app is broken
A previous web3 app left users staring at a spinner when a transaction was rejected, dropped, or ran out of gas, with no explanation of what happened.
Pending, replaced, reverted and rejected states each get their own explicit message — the design work most web3 apps skip, then feel broken.
Situation 4
Building on audited contracts, but no product around them
A team has contracts that have already been through audit, but no application layer that lets a real user safely interact with them.
The product layer — wallet connection, reads, transaction flows, dashboard — is built on top of contracts that already exist and are audited, not from scratch.
Situation 5
New-to-crypto users abandoning at the wallet-connect step
A product's onboarding assumes familiarity with wallets and network switching, and newcomers drop off before ever reaching the actual product.
Network switching is handled for the user automatically, and cost is explained before commitment — hiding the machinery a newcomer shouldn't need to see.
The honest part
When 30 days is the wrong answer.
A fixed deadline only works when the scope genuinely fits inside it. These are the cases where I will tell you so rather than take the booking.
Writing new smart contracts, and certainly not auditing them. Contract security is a specialist discipline where mistakes are permanent and expensive — I build the product around audited contracts.
Custodial products holding user funds, which is a regulated activity before it is a technical one.
Launching a token. That is a legal and market-structure question, not a design sprint.
Inside the 30 days
- Wallet connection across the common wallets, with a sane fallback
- On-chain reads: balances, positions, history, rendered as plain language
- Transaction flows that state the cost and the consequence before signing
- Clear pending, confirmed and failed states — the ones most apps skip
- A dashboard for holdings or activity that a non-expert can read
- Network switching handled for the user rather than demanded of them
- Responsive and fast, because most wallet traffic is mobile now
- Source code, design files and 30 days of support at handover
Quoted as one number before day one. A week running long is mine to absorb.
Outside the line
- Writing new smart contracts, and certainly not auditing them. Contract security is a specialist discipline where mistakes are permanent and expensive — I build the product around audited contracts.
- Custodial products holding user funds, which is a regulated activity before it is a technical one.
- Launching a token. That is a legal and market-structure question, not a design sprint.
Real work, sized and priced separately. You hear it before you book, not at handover.
Questions
Before you book
The application layer, yes — wallet connection, reads, transaction flows, dashboard — on top of contracts that already exist and are audited. If the contracts still need writing, that is a separate engagement with a specialist and I will say so.
Other sprints
30 days from now, this could be live.
A 30-minute call decides whether the scope fits. If it doesn't, I'll tell you what would.