Fork
The branch that doesn't merge back. Hard opinions for designers, founders, and builders who chose the other path. The one without the deck, the raise, or the exit plan.
Start here
These are principles for building things that matter in a space that often doesn’t.
Web3 is full of noise. Announcements about announcements. Roadmaps that never ship. Communities that are just group chats. Tokens that exist to create tokens.
Somewhere in all that noise, real things are being built. Protocols that solve real problems. Products that people actually use. Teams that ship and stick around.
These principles are for those builders. They’re not rules. They’re signals—patterns we’ve seen work, mistakes we’ve seen repeated, truths that survive market cycles.
Read them. Disagree with some. Apply what fits. Ignore what doesn’t. The goal isn’t to follow a playbook. It’s to build something that lasts.
Protocol > Product
Most Web3 projects ship products when they should ship principles. A protocol is a promise. A product is just software.
Products solve problems. Protocols define how problems get solved. The difference matters.
A product can change with every update. A protocol creates expectations. It’s a contract with everyone who builds on top of it. Break that contract and you break trust. Break trust and you break everything.
The projects that last understand this distinction. They know that the interfaces will evolve, the features will change, but the protocol—the core promise of how things work—stays stable.
Before you ship features, ship principles. Before you build products, define protocols. Everything else flows from there.
The DAO delusion
Decentralized doesn’t mean unorganized. Someone’s making decisions. Pretending otherwise just hides who.
Every DAO has a shadow org chart. There are people who actually make things happen, and there’s everyone else voting on proposals that don’t matter.
This isn’t a criticism of DAOs. It’s a reality check. Coordination requires leadership. Progress requires decision-makers. Decentralization doesn’t eliminate hierarchy—it just makes it less visible.
The honest DAOs acknowledge this. They know who the builders are. They know who sets direction. They’re transparent about power while distributing it where it makes sense.
The delusional DAOs pretend everyone’s equal while a handful of people run the show. That’s not decentralization. That’s obscured centralization with extra steps.
Pick your structure intentionally. Be honest about who decides what. Governance theater helps no one.
One wallet
Your users have one wallet. They don’t care about your chain, your bridge, or your multi-sig. They care if the thing works.
We build for infrastructure. Users live in interfaces.
Nobody opens their wallet excited to bridge assets across four chains. Nobody celebrates another network switch. Nobody wants to think about which L2 has their funds today.
The best Web3 products hide the complexity. They meet users where they are—one wallet, one action, one outcome. Everything else is machinery that should stay invisible.
Every time you expose a technical decision to users, you’re asking them to care about something they don’t want to care about. Stop making your architecture their problem.
Gas is UI
Transaction fees aren’t a backend problem. They’re the first thing users feel. Design around them or design users away.
Every transaction has a cost. That cost is part of the experience, not separate from it.
High gas fees feel like punishment. Unpredictable gas feels like gambling. Failed transactions feel like theft. These aren’t technical inconveniences—they’re emotional experiences that shape how users feel about your product.
The best Web3 interfaces design gas into the experience. They set expectations before the transaction. They batch when possible. They time operations intelligently. They make costs predictable and transparent.
If your interface surprises users with costs, you’ve failed at the most basic level. Gas is part of the UI. Design it accordingly.
Slower ships
Web3 moves fast and breaks everything. The projects that last move deliberately and fix what they break.
Speed is overrated. Survival is underrated.
The crypto timeline compresses everything. A week feels like a month. A bear market feels like a decade. This warped time creates pressure to ship faster, announce sooner, pivot quicker.
But the projects still standing after multiple cycles aren’t the fastest shippers. They’re the most deliberate. They ship when things are ready. They fix what breaks. They think in years, not sprints.
Moving fast only matters if you’re moving in the right direction. Slow down. Get it right. The market will still be there when you’re ready.
Roadmaps are lies
In crypto, a roadmap is marketing dressed as planning. Ship what’s ready. Announce what’s shipped. That’s it.
Every Web3 roadmap follows the same pattern: ambitious Q1, optimistic Q2, vague Q3, and a Q4 that never arrives as planned.
Roadmaps aren’t plans. They’re promises you probably can’t keep to people who will definitely hold you to them. Every item on a public roadmap becomes a commitment, and missed commitments become broken trust.
Here’s a better approach: ship things, then tell people you shipped them. Work on the next thing. Ship that too. Let your history of shipping speak louder than your promises of future shipping.
The best roadmap is a changelog. It’s honest. It’s verifiable. It’s impossible to fake.
Community ≠ Discord
A Discord server isn’t a community. It’s a group chat. Community is shared identity, shared stakes, shared outcomes.
Every project has a Discord. Very few have a community.
A Discord server is just infrastructure—a place where people can talk. Community is what happens when people actually care about the same things, when they have skin in the game, when they show up even when nobody’s watching.
You don’t build community with channels and roles and bots. You build community by creating something worth caring about, then giving people ways to contribute that matter.
The test is simple: if your Discord went offline tomorrow, would people find each other somewhere else? If yes, you have a community. If no, you have a chat room that will empty out the moment something shinier appears.
Anti-announcement
Stop announcing what you’re going to build. Build it. Then show it. The gap between announcement and delivery is where trust dies.
The crypto industry has perfected the art of announcing announcements. Teasers for teasers. Countdowns to countdowns. Hype without substance.
Here’s what actually happens: you announce something. Expectations rise. Time passes. Expectations drift into something different than what you’re building. You ship. Reality disappoints the fantasy. Trust erodes.
The alternative is radical: don’t announce. Build in the open if you want, but don’t promise. When it’s ready, show it. Let the work speak. Let people react to what exists, not what might exist someday.
Announcements are borrowed excitement. Shipping is earned credibility. One of these compounds. The other depletes.
Tokenomics theater
Most tokenomics decks are fiction written to justify fundraising. Real economics happen after launch. Everything else is cosplay.
Tokenomics documents are the business plans of Web3—elaborate fictions that rarely survive contact with reality.
They’re filled with charts showing perfect emission curves, balanced incentives, and growth projections that only go up. They assume rational actors, stable markets, and adoption curves that follow the model.
None of that happens. Markets are irrational. Users game systems. Whales distort incentives. The beautiful curves crash into ugly reality.
Real tokenomics emerge from actual usage. They’re discovered through iteration, not designed through spreadsheets. The honest approach is to launch simple, observe behavior, and adapt. Anything else is theater—impressive to look at, but fiction all the same.
Design is trust
In Web3, users are handing you their money with one click. If your interface feels sketchy, you feel sketchy. There’s no second chance.
Every pixel is a trust signal.
When someone connects their wallet to your site, they’re not evaluating your smart contract audits. They’re evaluating how the button looked. How the page loaded. Whether the typography felt professional or thrown together.
This isn’t superficial—it’s survival instinct. Users have been rugged by sites that looked exactly like scams. They’ve learned that presentation correlates with intention. Sloppy design suggests sloppy security. Amateur interfaces suggest amateur teams.
In Web3, design isn’t decoration. It’s the first and sometimes only proof that you know what you’re doing. Invest in it like your users’ trust depends on it—because it does.
Docs-driven
If you can’t explain it in documentation, you don’t understand it. Good docs aren’t for users. They’re proof you’ve thought it through.
Documentation is thinking made visible.
When you can’t write clear docs, it’s not a writing problem. It’s a clarity problem. The concepts are muddled. The boundaries are unclear. The system is more complicated than it needs to be.
The best teams write docs before they write code. Not elaborate specs—simple explanations of what they’re building and why. The act of writing forces clarity. It exposes assumptions. It reveals complexity that should be simplified.
Your docs are a mirror. If they’re confusing, your product is confusing. If they’re clear, you might actually know what you’re building.
The airdrop trap
Free money attracts free people. They’ll leave the moment someone else offers free money. That’s not adoption. That’s tourism.
Airdrops are the junk food of growth metrics. They look great on dashboards and create nothing lasting.
The wallets that show up for free tokens aren’t users. They’re collectors. They’ll connect, claim, and disappear. They’ll never use your product. They’ll sell the moment they can. They’ll leave your Discord the day the airdrop ends.
Real users come because you solve their problem. They stay because you keep solving it. They tell others because the product is genuinely useful.
If your growth strategy depends on giving away value, you haven’t created enough value to attract people on your own merits. Airdrops don’t fix that problem. They mask it until the tokens run out.
Copy your own homework
Your best work comes from solving your own problems. Every successful Web3 tool started as something the builder needed themselves.
The best products come from frustration, not market research.
Uniswap started because Hayden needed a way to swap tokens. Etherscan started because someone needed to explore transactions. The pattern repeats: builder has problem, builder solves problem, solution becomes product.
When you build for yourself, you have an unfair advantage. You understand the problem completely. You know what good looks like. You can test instantly because you’re the user.
Building for imaginary users means guessing what they want. Building for yourself means knowing. Start with your own problems. Expand from there.
Brand isn’t vibes
A logo and color palette isn’t a brand. A brand is what people say about you when you’re not in the Discord.
Brand is reputation. Everything else is packaging.
You can have perfect visual identity and zero brand. You can have inconsistent aesthetics and a powerful brand. The difference is what people believe about you, not what they see from you.
Brand is built through actions. Do you ship what you say you’ll ship? Do you handle problems honestly? Do you treat users like people or like metrics? Every interaction either builds or erodes the brand.
The visual stuff matters—it’s how people recognize you. But recognition without reputation is just familiarity. Build the reputation first. The visuals are just how people find you.
Simplify or die
Every feature you add is debt. Every option you offer is confusion. The winning products do one thing so well that nothing else matters.
Complexity is the default. Simplicity is the achievement.
Every product starts simple and grows complicated. Features accumulate like sediment. Options multiply to serve edge cases. Soon, the simple thing that worked becomes the complex thing that confuses.
The discipline is subtraction. What can you remove? What can you combine? What can you hide until it’s needed? Every feature has a cost—in maintenance, in cognitive load, in surface area for bugs.
The products that win aren’t the ones with the most features. They’re the ones where every feature earns its place. If you can’t explain why something exists, it probably shouldn’t.
The founder gap
Technical founders undervalue design. Design founders undervalue tech. The gap between them is where most projects fail.
Every founder has blind spots shaped by their expertise.
Technical founders see the architecture, the elegance of the code, the sophistication of the protocol. They underestimate how much interface quality affects adoption. They ship brilliant backends with mediocre frontends and wonder why users don’t get it.
Design founders see the experience, the flow, the emotional impact. They underestimate implementation complexity. They design interactions that are impossible to build or unsustainable to maintain.
The best teams have both perspectives in genuine dialogue. Not designer as service provider to engineers. Not engineers as executors of design specs. Real collaboration where each discipline shapes the other. The gap between them is where understanding lives—or where products go to die.
Consultancy economics
Hourly billing punishes efficiency. Fixed pricing rewards expertise. Charge for outcomes, not attendance.
The better you get, the less time things take. Hourly billing punishes that expertise.
If you can solve in two hours what used to take you ten, hourly billing means you earn 80% less for being better at your job. That’s backwards. Your value increased. Your compensation decreased.
Fixed pricing flips the incentive. You quote based on the value of the outcome, not the time it takes. Get faster, and you earn more per hour without charging more. Your expertise becomes leverage instead of liability.
The client cares about what they get, not how long it took you. Price accordingly.
Client says vs. client needs
What clients ask for is rarely what they need. Your job is to hear the ask, understand the need, and deliver the solution.
Clients describe solutions. Your job is to find the problems.
“We need a new website” might mean “our conversion rate is terrible.” “We need a rebrand” might mean “we pivoted and the old identity doesn’t fit.” “We need it faster” might mean “we’re scared and need reassurance.”
Taking requests literally is lazy. Digging deeper is the work. Why do they think they need this? What would success actually look like? What’s the real problem underneath the stated request?
Sometimes the answer is exactly what they asked for. Often, it’s something different. Always, your job is to understand before you execute. Deliver what they need, not just what they said.
Pitch decks are not design
A pitch deck gets you the meeting. Design gets you the outcome. Stop treating mockups like strategy documents.
Pretty slides don’t ship products.
There’s a disease in startups where pitch deck design becomes a proxy for actual design capability. Teams spend weeks perfecting presentations while their actual product looks like an afterthought.
Pitch decks serve one purpose: getting the next conversation. They’re not products. They’re not strategies. They’re not proof that you know how to build.
The work that matters is what users actually touch. The interfaces they navigate. The experiences they have. That’s design. Everything else is decoration for meetings.
One page, not one hundred
The best brand guidelines fit on a single page. The worst ones are PDFs nobody reads. Constraints create consistency.
Brand guidelines are often measured by weight instead of usefulness.
The 100-page brand book is a monument to thoroughness that nobody reads. It covers every edge case, every application, every theoretical scenario. It sits in a folder, referenced never.
The one-page version forces choices. What actually matters? What are the two or three principles that, if followed, make everything work? What can people actually remember?
Constraints create consistency better than comprehensive documentation. A few clear rules, followed everywhere, beats extensive guidelines followed nowhere.
Fire fast
Bad-fit clients cost more than no clients. The relief of ending a wrong engagement always outweighs the fear of starting it.
Every consultant has clients they should have fired months ago.
You know which ones. The ones who drain your energy. The ones where every interaction feels like a fight. The ones who pay late, demand more, respect less. You keep them because revenue feels safer than uncertainty.
But bad clients have hidden costs. They take time from good clients. They kill your motivation. They warp your work to serve dysfunction. The revenue isn’t worth the damage.
Fire them. Do it professionally, but do it quickly. The relief is immediate. The space you create gets filled by better work. Every consultant who’s done this wishes they’d done it sooner.
Positioning is choosing
You can’t be for everyone. Choosing who you’re not for is more important than choosing who you’re for.
Positioning isn’t about claiming territory. It’s about abandoning it.
When you say “we’re for serious DeFi teams,” you’re also saying you’re not for NFT projects, not for meme coins, not for casual builders. That exclusion does the positioning work. It tells the right people they belong and the wrong people they don’t.
The anxiety is that you’ll miss opportunities. You will. That’s the point. Every opportunity you miss is attention saved for the opportunities that actually fit.
Being for everyone means being memorable to no one. Choose your people. Release everyone else.
Rate math
Charge what makes the work sustainable. If you resent the rate, you’ll resent the work. Resentment shows up in the output.
Pricing isn’t just economics. It’s psychology.
When you charge too little, you resent the client before the project starts. That resentment poisons everything. You cut corners because why bother at this rate. You deprioritize them because the work doesn’t feel valued. You deliver less because you’re getting less.
The right rate is one where you’re genuinely motivated to do great work. Where you feel fairly compensated. Where delivering excellence feels like a good deal for both sides.
That number is different for everyone. Find yours. Charge it without apology. The clients who can’t afford it aren’t your clients.
Solo scale
You don’t need a team to do great work. You need systems. The best consultants look like agencies with one person.
Teams are expensive. Systems are leverage.
The solo consultant with great systems outperforms the agency drowning in coordination costs. They move faster because there’s no alignment overhead. They deliver consistently because the process is documented. They scale through efficiency, not headcount.
The trick is building systems before you need them. Templates for deliverables. Processes for intake. Automation for the repetitive. Documentation for decisions.
One person with systems looks like a team. A team without systems looks like chaos. Build the systems. Scale yourself.
Strategy is expensive
Execution is cheap. Everyone can build. Few can decide what to build. Charge accordingly.
The market has commoditized execution. Templates, AI, offshore teams—getting things made has never been cheaper. But knowing what to make? That’s the scarce skill.
Strategy is deciding. It’s saying this, not that. It’s understanding trade-offs well enough to choose between them. It’s taking responsibility for direction, not just delivery.
If you can do strategy, charge for it separately and significantly. Don’t bundle it with execution where it gets lost. The strategic recommendation that shapes the next year of work shouldn’t cost the same as the mockups that follow.
Strategy is where the value lives. Price it like it matters.
Portfolio theater
Most portfolios show the work. The best portfolios show the thinking. Process beats polish.
A gallery of final outputs tells the client almost nothing useful.
It shows you can make things that look nice. It doesn’t show how you think, how you collaborate, how you handle constraints, how you solve problems. The pretty pictures are the least interesting part of the story.
The best portfolios show the journey. Here’s where we started. Here’s what we learned. Here’s why we made these choices. Here’s what we’d do differently. That’s the conversation clients want to have. They’re not hiring pixels—they’re hiring judgment.
Show your thinking. The work only proves you can execute. The thinking proves you can lead.
NDA red flags
If a client needs an NDA before the first call, they either have nothing worth protecting or everything to hide. Both are problems.
NDAs before conversations are a signal.
Sometimes they signal inexperience—founders who think their idea is so unique that anyone who hears it will steal it. (They won’t. Execution is the hard part. Ideas are cheap.)
Sometimes they signal something worse—clients preparing to share information they shouldn’t share, or setting up legal infrastructure for a difficult engagement.
Either way, an NDA demand before you’ve even spoken suggests a client who doesn’t understand how business relationships work. That’s a red flag about everything that follows.
Professional clients discuss confidentiality after there’s something confidential to discuss. The ones who lead with legal documents often end up being the hardest to work with.
Scope creep is design failure
When scope keeps changing, the problem wasn’t defined. Creep isn’t a client problem. It’s a process problem you allowed.
Scope creep doesn’t happen by accident. It happens because someone—usually you—didn’t establish boundaries clearly enough.
When a client keeps asking for more, it means they didn’t understand where more ends. When requirements keep shifting, it means they weren’t solid to begin with. When projects expand beyond recognition, it means the original scope was fantasy.
The fix isn’t better contracts or stricter boundaries during the project. The fix is better discovery before the project. Defining the problem precisely. Getting agreement on what done looks like. Creating shared understanding before work begins.
Creep is a symptom. Unclear scope is the disease. Treat the disease.
Feedback is data
Client feedback isn’t an attack. It’s information. Take the data, ignore the tone, and use it to get closer to right.
Feedback feels personal because work feels personal. Separating the two is a skill.
When a client says “I hate this,” what they mean is “this doesn’t match my expectations.” That’s useful information. It tells you there’s a gap between what you delivered and what they envisioned. Your job is to close that gap, not to defend your choices.
The tone doesn’t matter. The data does. What specifically doesn’t work? What was expected instead? What would success look like?
Get curious instead of defensive. Use feedback to understand, not to argue. The best work comes from iteration, and feedback is just iteration fuel.
Revisions vs. iterations
Revisions fix what’s wrong. Iterations explore what’s possible. Know which one you’re doing and price them differently.
These are two different activities with different costs and different values.
Revisions are corrections. The work missed the target, and you’re adjusting to hit it. This is typically included—it’s the cost of getting to done.
Iterations are exploration. The work hit the target, but now we’re exploring other targets. This is new work. It expands the scope. It should expand the budget.
The confusion happens when clients frame iterations as revisions. “Can we try something different?” feels like feedback but is actually a new direction. Recognizing the difference—and naming it—protects both your time and the relationship.
Show your work
The final design is 10% of the value. The thinking that got there is 90%. Clients who only see deliverables undervalue you forever.
If clients only see the output, they’ll only pay for the output.
The logo looks simple? That’s because you made a hundred decisions to make it simple. The interface feels obvious? That’s because you explored a dozen alternatives that felt wrong. The strategy seems straightforward? That’s because you eliminated the complicated options.
All of that work is invisible unless you make it visible. Show the exploration. Explain the trade-offs. Walk through the decisions. Let clients see the iceberg, not just the tip.
When clients understand what goes into the work, they understand the value. When they only see the final artifact, they wonder why it costs so much for something that looks so simple.
Retainers over projects
Projects end. Retainers compound. Recurring relationships beat one-time wins every time.
Projects create feast and famine. Retainers create stability.
With projects, you’re always hunting. Finish one engagement, find the next. Every gap is unpaid time. Every new client is a new relationship to build from scratch.
With retainers, the relationship deepens over time. You understand the client’s business. They trust your judgment. The work gets better because context accumulates. Revenue becomes predictable. Energy goes into work instead of sales.
Not every client fits a retainer model. But the ones who do become the foundation of a sustainable practice. Prioritize them. Nurture them. Build a business on relationships, not transactions.
Small bets
Don’t build the big thing first. Build the smallest thing that proves the big thing might work. Scale what survives.
Big bets feel bold but are usually just expensive ways to be wrong.
The smarter approach is small bets. Build the smallest version that tests the core assumption. Ship it fast. See if anyone cares. If they do, build more. If they don’t, you’ve learned something cheap.
This isn’t about lacking ambition. It’s about efficient ambition. Every big success started as a small success that earned the right to grow. The products that skipped that step are the ones you’ve never heard of.
Start small. Validate fast. Scale what works. Kill what doesn’t. This is how things that last get built.
Opinion is differentiator
Neutral design is forgettable design. Have a point of view. Some people will hate it. The right people will love it.
Playing it safe is the riskiest choice you can make.
Neutral work offends no one and excites no one. It sits in the vast middle where everything looks the same and nothing stands out. It’s the safest way to be completely forgettable.
Having an opinion means making choices that some people won’t like. It means designing for someone specific instead of everyone general. It means saying “this is what we believe” and accepting that others believe differently.
The people who share your opinion will find you remarkable. The people who don’t weren’t your people anyway. Strong opinions attract strong alignment. Neutrality attracts nothing.
Tools aren’t taste
Figma didn’t make anyone a better designer. Your tools multiply your talent, they don’t create it.
New tools are exciting. They feel like shortcuts to better work. They’re not.
Figma in unskilled hands produces bad design faster. AI in undiscerning hands produces more mediocrity. The tool amplifies what’s already there. It doesn’t add what’s missing.
Taste, judgment, understanding—these come from study and practice, not from software subscriptions. The best designers could work in any tool because the tool isn’t where the magic lives.
By all means, use good tools. But never confuse tool proficiency with design skill. They’re different capabilities, and only one of them actually matters.
Steal structure
Every good design system started by copying someone else’s. Originality isn’t invention. It’s combination.
Original work is a myth. Everything is built on something.
The designers you admire learned by copying the designers they admired. The systems you use evolved from systems that came before. Creativity isn’t conjuring from nothing—it’s combining existing elements in new ways.
Give yourself permission to steal structure. Take the grid from here, the type system from there, the interaction patterns from somewhere else. Make them yours by making them work together.
The goal isn’t to be original. It’s to be effective. Use whatever works. Credit where appropriate. Build on the shoulders of everyone who came before.
Ship scared
If you’re comfortable when you ship, you played it safe. The best work makes your stomach turn right before you hit publish.
Comfort is a warning sign.
When shipping feels easy, it usually means you stayed in familiar territory. You did what you know works. You avoided the edges where interesting things happen. You optimized for safety over impact.
The work that matters feels risky because it is risky. You’re putting something into the world that might fail, might be misunderstood, might be rejected. That vulnerability is the cost of doing something new.
The stomach-turn before shipping? That’s not a bug. It’s the feeling of caring about something enough to be scared. Embrace it. Ship anyway. That’s where the good stuff lives.
Thank You :)