What You Can Skip at 0→1
Stop polishing and start shipping
You’re building your first version.
The product barely works. You have zero users.
And you’re debating color palettes.
I see this constantly: founders at 0→1 treating design like they’re at 1→100. Obsessing over polish that doesn’t matter yet. Delaying launch for things nobody will notice.
After working with 10+ web3 startups over 5 years, here’s what I’ve learned: most founders over-design at 0→1. They’re following advice meant for growth stage and applying it to proof-of-concept.
This post tells you exactly what you can skip when you’re just trying to prove it works. And what you absolutely cannot skip.
Ship faster. Polish later.
The 0→1 Reality Check
First, let’s be clear about what 0→1 actually means:
0→1 is:
Proving core concept works
Getting first 10-100 believers to use it
Validating you’re solving a real problem
Testing if anyone cares enough to try
0→1 is NOT:
Building for scale
Optimizing conversion
Growing to thousands of users
Creating polished brand
Your goal is proof, not perfection. Design accordingly.
What Actually Matters at 0→1
Only three things matter for design at this stage:
1. Does it work?
Can users actually complete the core action? Does the product function?
Not “does it work beautifully.” Just: does it work?
2. Can users figure out what to do?
Is the core flow comprehensible? Can someone use it without you explaining?
Not “is it intuitive for everyone.” Just: can your target user stumble through it?
3. Does it feel legitimate?
Does it look real enough that people don’t think it’s a scam?
Not “does it feel premium.” Just: does it pass basic trust threshold?
That’s it. Three things. Everything else is optional at 0→1.
What You Can Absolutely Skip
Here’s your permission list. Skip all of this at 0→1:
Visual Design You Can Skip
❌ Custom color palette
Use: Default Tailwind colors or steal from a product you like
Why: Colors don’t prove concept
When to do it: When you have product-market fit and need brand differentiation
❌ Custom typography
Use: System fonts (SF Pro on Mac, Roboto on Android, Arial/Helvetica on web)
Why: Typography doesn’t affect whether product works
When to do it: When you’re redesigning for growth
❌ Logo design
Use: Wordmark in default font or free logo from Figma community
Why: Nobody remembers your logo when you have 50 users
When to do it: When brand recognition actually matters
❌ Consistent spacing system
Use: Whatever looks okay in the moment
Why: Spacing precision doesn’t validate demand
When to do it: When you’re scaling design across features
❌ Design system
Use: Copy components from Chakra/Shadcn/Ant Design
Why: You’ll change everything anyway based on feedback
When to do it: When you’re building second or third major feature
❌ Custom illustrations
Use: Nothing, or free illustrations from unDraw/Blush
Why: Illustrations don’t prove product value
When to do it: When you have budget and brand to express
❌ Animation and micro-interactions
Use: Default browser/framework behaviors
Why: Smooth animations don’t validate concept
When to do it: When polish becomes competitive advantage
❌ Dark mode
Use: Light mode only
Why: Supporting two themes doubles work for zero validation
When to do it: When users actually request it
❌ Responsive design perfection
Use: Works on desktop or works on mobile, not both perfectly
Why: Pick one platform, nail that
When to do it: When you’re growing and need both platforms
❌ Empty states
Use: Blank screen or “No items yet”
Why: Users will have items soon if product works
When to do it: When onboarding and first-use experience matter
Copy You Can Skip
❌ Polished marketing copy
Use: Functional descriptions that explain what it does
Why: Clever copy doesn’t prove product value
When to do it: When you’re optimizing conversion
❌ Error message perfection
Use: Technical errors are fine if they show what broke
Why: Errors shouldn’t happen often if product works
When to do it: When error handling affects conversion
❌ Educational content
Use: Just answer questions as they come
Why: You don’t know what needs explaining yet
When to do it: When same questions repeat 10+ times
❌ About page, Terms, Privacy Policy
Use: Bare minimum legal coverage if needed, otherwise skip
Why: Believers don’t read this stuff
When to do it: When legal risk increases or you need to look legitimate
Features You Can Skip
❌ User accounts/auth
Use: Wallet connection only (web3 advantage)
Why: Auth doesn’t validate product concept
When to do it: When you need persistent user data
❌ Search
Use: Just show everything, or basic browser search
Why: Search only matters with lots of content
When to do it: When you have 50+ items to search through
❌ Filters and sorting
Use: Single default view
Why: Complexity without enough data to filter
When to do it: When users actually need to narrow results
❌ Settings
Use: Hardcode sensible defaults
Why: Configurability doesn’t prove concept
When to do it: When different users need different configurations
❌ Onboarding flow
Use: Jump straight to product
Why: Believers will figure it out
When to do it: When conversion rate on first-use matters
❌ Notifications
Use: None, or manual reach-out when needed
Why: Notification system is infrastructure overhead
When to do it: When you need to bring users back
❌ Analytics dashboard
Use: Mixpanel free tier or Amplitude, track basics only
Why: Deep analytics don’t help at 50 users
When to do it: When you need to understand user behavior at scale
❌ Mobile app
Use: Web app, use progressive web app if needed
Why: Native apps are 3x the work
When to do it: When mobile-native features are essential or distribution requires it
Infrastructure You Can Skip
❌ Database optimization
Use: Most basic setup that works
Why: Performance doesn’t matter with 100 users
When to do it: When queries are actually slow
❌ Caching
Use: None
Why: Not enough traffic to need it
When to do it: When things are slow due to load
❌ CDN
Use: Host assets wherever is easiest
Why: Speed doesn’t validate concept
When to do it: When you have global users or slow load times
❌ Automated testing
Use: Manual testing
Why: Everything will change anyway
When to do it: When you have core flows that break repeatedly
❌ CI/CD pipeline
Use: Deploy manually
Why: Not shipping fast enough to need automation
When to do it: When deploying multiple times per day
❌ Staging environment
Use: Deploy to production and fix forward
Why: Not enough users to worry about breaking things
When to do it: When breaking production actually hurts users
What You Cannot Skip
Now the critical stuff. Don’t skip these:
Must-Have Design Elements
✅ Clear core action
Users must understand what the product does and how to do it.
Why: If they can’t use it, they can’t validate it.
✅ Functional core flow
The main thing must work reliably.
Why: Broken products teach you nothing.
✅ Basic visual hierarchy
Important things bigger/bolder, less important things smaller.
Why: Without hierarchy, everything looks equally important (nothing is).
✅ Readable text
Sufficient contrast, legible size, reasonable line length.
Why: If they can’t read it, they can’t use it.
✅ Trust signals
Something that proves you’re real (GitHub, Twitter, wallet address that has history).
Why: Without trust, nobody tries it.
✅ Mobile responsiveness for your platform
If mobile-first: must work on mobile. If desktop-first: must work on desktop.
Why: Unusable on target platform = no validation.
✅ Working links and buttons
Everything clickable must work.
Why: Broken interactions = users leave before testing value.
Must-Have Copy Elements
✅ What it does (one sentence)
Clear description of product purpose.
Why: Confused users don’t try things.
✅ How to start (obvious next action)
One clear CTA telling users what to do first.
Why: Unclear entry point = no usage.
✅ Contact method
How to reach you when something breaks.
Why: You need feedback. They need support.
Must-Have Features
✅ Core functionality
The one thing your product must do.
Why: This is what you’re validating.
✅ Feedback mechanism
Way for users to tell you it’s broken/confusing.
Why: You need to learn what’s wrong.
✅ Basic error handling
Don’t crash. Show something when it breaks.
Why: Silent failures teach you nothing.
Real 0→1 Examples
Let’s look at what successful products actually launched with:
Uniswap V1
What they had:
Two input fields
Swap button
It worked
What they didn’t have:
Logo (just text)
Custom colors
Token search
Charts
Analytics
Marketing site
Result: Proved AMM concept. Everything else came later.
Friend.tech (Initial Launch)
What they had:
Core mechanic (buy/sell keys)
Basic chat
Invite codes (exclusivity)
What they didn’t have:
Polished design
Mobile app (PWA only)
Extensive features
Professional branding
Result: Proved demand. Scaled from there.
Farcaster (Initial)
What they had:
Working protocol
Basic client (Earchive)
Could post and read
What they didn’t have:
Multiple clients
Rich features
Polished UI
Extensive documentation
Result: Proved protocol worked. Better clients came later.
The Pattern
Launch with:
Core mechanic working
Barely sufficient UI
Way to get feedback
Skip everything else. Add based on what users actually need.
The Minimum Viable Design Checklist
Here’s your 0→1 design checklist:
Visual (30 minutes - 2 hours)
[ ] Use component library (Chakra, Shadcn, Ant Design)
[ ] Pick one primary color from defaults
[ ] Use system fonts
[ ] Make text readable (16px+, good contrast)
[ ] Basic visual hierarchy (headings bigger than body)
[ ] Works on your target platform (mobile OR desktop)
Copy (30 minutes - 1 hour)
[ ] One sentence: what it does
[ ] One sentence: who it’s for
[ ] One clear CTA
[ ] Way to contact you
Features (Varies by product)
[ ] Core action works
[ ] Basic error handling (show something, don’t crash)
[ ] Feedback method (Discord, Twitter, email)
Technical (Varies by product)
[ ] Deployed somewhere
[ ] Works reliably enough to test
[ ] You can fix it quickly when it breaks
Total time investment: ~1-5 days for design/polish
Not weeks. Not months. Days.
When to Stop Skipping
You graduate from 0→1 when:
✅ Core concept is validated
People use it repeatedly. They tell others about it. Demand is clear.
✅ You have product-market fit indicators
Retention is good. Growth is organic. Users would be upset if it disappeared.
✅ You’re ready to scale
Need to onboard hundreds/thousands of users. Current design limits growth.
At this point, invest in design properly:
Brand identity
Design system
Polish and refinement
Optimization
Multiple features
But not before. Premature polish wastes time you need for iteration.
The Founder Traps
Watch out for these:
Trap 1: “I’ll launch when it’s ready”
The problem: Ready keeps moving. You keep adding polish.
Reality: It’s ready when core mechanic works. That’s it.
Fix: Set launch date. Ship on that date regardless.
Trap 2: “First impressions matter”
The problem: At 0→1, you’re not making first impression on mainstream. You’re testing with believers.
Reality: Believers care if it works, not if it’s pretty.
Fix: Focus on function. Polish for mainstream comes later.
Trap 3: “I need design to compete”
The problem: You’re not competing yet. You’re proving concept.
Reality: Competition is irrelevant if concept doesn’t work.
Fix: Prove demand first. Compete second.
Trap 4: “I’m a technical founder, I need designer”
The problem: Hiring designer delays launch and adds communication overhead.
Reality: You don’t need designer for 0→1. You need component library and taste.
Fix: Use pre-built components. Ship. Hire designer when scaling.
Trap 5: “Design shows we’re serious”
The problem: Believers judge on utility, not polish.
Reality: Working product shows you’re serious. Pretty mock-ups don’t.
Fix: Build working thing with basic design. That’s credibility.
The Practical Reality
Here’s how 0→1 design actually works:
Week 1-2: Build core function
Focus: Make it work. Design = whatever gets it working.
Week 3: Make it usable
Focus: Can someone use this without you explaining? Minimum UI to enable that.
Week 4: Ship it
Focus: Get it in front of 10 people. Get feedback.
Week 5+: Iterate based on feedback
Focus: Fix what’s broken. Add what’s needed. Polish nothing else.
Notice: Design is never the focus. Function is always the focus.
What This Means for You
If you’re at 0→1 right now:
Look at your current progress.
Are you spending more time on design than function? Red flag.
Look at your todo list.
How many items are polish vs core features? If >30% polish, you’re over-designing.
Look at your timeline.
Delaying launch for design reasons? Stop. Ship now. Polish later.
Make the cut.
Go through your design todos. Ask: “Does this prove the concept?” No? Cut it.
The Permission Slip
You have permission to:
Use default colors
Use system fonts
Copy someone else’s layout
Skip the logo
Ship ugly
Fix bugs in production
Not have mobile app
Skip onboarding flow
Not write perfect copy
Launch before it’s “ready”
Your job at 0→1 is proving it works and people want it. Not making it pretty.
Pretty comes later, if and only if the concept works.
The Bottom Line
At 0→1, skip almost everything except:
Core function working
Basic usability
Minimum trust signals
Use component libraries. Copy layouts. Ship fast. Polish later.
Most founders waste months polishing at 0→1. That polish doesn’t validate demand. It just delays learning.
The products that win at 0→1 are the ones that ship fast, learn fast, iterate fast. Not the ones that look best at launch.
Focus: Does it work? Can users figure it out? Does it solve their problem?
Everything else is premature optimization.
Ship the thing. Learn if anyone cares. Then, and only then, make it pretty.
Thank you :)
If your project needs design, brand, product, strategy, and leadership,
let’s talk, hi@dragoon [dot] xyz | Follow: 0xDragoon