Tips from the Pros

Real advice from people who've shipped real apps on OPNet.

---

#On the plugin workflow

Use claudeyproj for the full autonomous experience.

The /buidl command is designed to run without interruption. 8 agents, working in sequence, handing off to each other. If you run it in interactive mode (claudey), you'll be approving every single step. That's 50+ approvals for a medium-complexity app. Use claudeyproj. Trust the pipeline.

The /buidl command does the whole pipeline — don't micromanage.

When you run /buidl "idea", don't try to intervene. Let it run. The agents are coordinating. If you jump in mid-pipeline with "wait, also add X," you'll interrupt the handoff sequence and potentially break the state. Wait for the pipeline to complete, then iterate.

The auditor agent catches real bugs — trust the process.

The 27 audit patterns aren't theoretical. They're based on actual bugs that were found in production OPNet codebases. When the auditor flags something and sends it back for a fix, that's not the pipeline being slow — that's the pipeline saving you from deploying broken code. Let it work.

Run /buidl-spec first for complex ideas.

For anything with financial mechanics (staking curves, fee distributions, AMM math), run /buidl-spec "idea" before the full build. Review the spec carefully. The spec is fast to change. The implementation is not. Get the economics right before writing a line of code.

---

#On building good apps

Your frontend should look production-ready, not like a hackathon demo.

Users judge apps instantly. If your app looks unpolished, users assume the contracts are unpolished too. Spend 20% of your effort on making the frontend look real. Dark theme, proper typography, loading states, smooth transitions. Ask Claude explicitly: "make this look like a production DeFi app."

State your visual requirements upfront.

Don't wait until after the build to say you want a dark theme. Put it in the initial /buidl prompt: "dark background, OPNet orange accent, glassmorphism cards." Changing the design after the build is possible but costs more iterations than starting with a clear direction.

Design for mobile from day one.

OPNet users are on mobile. Build mobile-first. Ask Claude: "make this fully usable on a 375px wide screen." Desktop should be comfortable but mobile is the primary target.

Empty states aren't empty — they're prompts.

When a user hasn't done anything yet (hasn't staked, hasn't claimed, has no history), what they see matters. A blank screen makes them wonder if something's broken. A well-designed empty state tells them what to do next. Ask Claude to design empty states for every view.

---

#On getting unstuck

Paste the full error, every time.

Don't paraphrase errors. Don't say "there's some kind of transaction error." Copy the full error message and stack trace. Claude reads error messages, not summaries of error messages. The specific wording often tells Claude exactly what went wrong.

If three patches haven't fixed it, ask for a rewrite.

When Claude makes three attempts to fix something and it's still broken, the thing is fundamentally broken in a way that patches can't fix. Say: "Rewrite the [component/function] from scratch. Here's what it should do: [describe]. Don't patch the existing code, start fresh."

The nuclear option is not giving up — it's a fresh start.

Asking Claude to audit and repair the entire codebase is not admitting defeat. It's a legitimate move that often finds the root cause instead of patching symptoms. Use it when things are tangled.

---

#On shipping

Deploy to testnet first, always.

Even if you're confident everything works, deploy to testnet first. Run through the full user flow with test BTC. Catch any deployment-specific issues before they happen on mainnet.

Get a .btc domain for your app.

It takes 5 minutes and makes your app feel real. yourappname.btc instead of a random IPFS hash or someone else's domain. Use the opnet-cli to set it up.

Write one paragraph about what your app does.

Before you tell anyone about it, write the pitch paragraph. What does it do? Who is it for? Why should someone use it? If you can't write this paragraph, the app isn't ready to ship. If you can, use it everywhere: competition submission, Discord post, README.

---

#On the bigger picture

Ship something small first.

Your first vibecoded app doesn't need to be a full DEX. Build the faucet. Build the NFT mint page. Get comfortable with the pipeline, understand how deployment works, learn the iteration cycle. Then build bigger.

The plugin knowledge is your unfair advantage.

When you vibecode with the buidl-opnet-plugin, your Claude knows things that generic AI tools don't. Real OPNet patterns. Real bugs to avoid. Real deployment flows. Other builders are working without this. You're not.

The best time to ship was last week. The second best time is now.

Don't wait until the app is perfect. Ship when it works. Iterate in public. Build a reputation for shipping.