How to Build a Web3 MVP

MVPs have become standard practice in startups. Launch a barebones version, validate demand, iterate, then scale. In 2022, this is super easy, with no-code tools like Draftbit, Airtable, Zapier, etc.

Launching a crypto product is a little different. Smart contracts are uneditable. You’re moving real people’s money. And the icing on the cake — contracts are publicly viewable. So there’s no hiding your crafty Google Sheet-powered backend. Right?

Backstory

Prior to Brydge, we built a mining optimization platform called Cloudfarm. 6 months of nonstop building our “MVP”. This was different from a web2 concept. Our MVP “had” to be air tight.

We were hyped for launch. Our users would literally make free money by repurposing their idle computers to mine altcoins. Best value prop ever!

Then, we launched. Could barely get 10 folks to give us a try. 9 of them churned within a week. The 10th only stuck around because he was roommates with my cofounder.

Silver lining!

We had this random feature (user payouts on Layer 2, which was novel at the time) that we included last minute. Didn’t think much about it ourselves. But, 40% of our initial (10) users flagged it as super helpful.

So, we built a new (read: bad) site around the feature and drafted this Reddit post. Relaunched in 3 days. Did $75k in transaction volume just from that single post.

Lesson: launch yesterday!

How We Did It

By actually building an MVP.

Brydge v1 was a bridge aggregation platform. Users deposited funds into a smart contract on source chain, waited for other users to do the same, then the batch would be bridged to destination chain and distributed back to users. Gas (network fee) was super high at the time, so users would save up to ~$125/transaction by using Brydge.

The catch — we didn’t actually have any smart contracts.

We ran the system using a pairing of wallets, managed by us. Sending tokens to a wallet looks identical to interacting with a smart contract for users. We actually didn’t have a single smart contract built for 4 months.

But the product filled a need. So users didn’t care.

Lesson: web3 MVP’s aren’t too different from web2

How You Can Do This Too

Doxx Yourself

Faces make people more comfortable. Getting someone to try your sketchy MVP is hard. Doing so with linked socials is easier.

Think Through Security

The easiest way to torpedo your beautiful idea/protocol/career = a hack.

If you lose someone’s $$, your reputation will take a hit. Spend $50 on a hardware wallet if you’re holding funds. Better yet, use a multisig. Seek risk everywhere else. Mitigate risk here.

Rip as Much as You Can

Web3 is open source. You’re creating an MVP. Minimize work, maximize output. Find a simple site already built out with web3.js, clone their front end, and go to work.

Tune out the Noise

Some folks will hate your MVP. They’ll badger you about your source code, audit, landing page responsiveness, you name it. That’s ok. They’re not your target customer right now.

Focus on those willing to try your product. Listen to them, then iterate.

Win over the hesitants later.