Tweet
Most projects get built and never used by anyone except their creator. Not because they're bad, but because nobody understands what problem they solve or why they should care.
The difference between a project that gets traction and one that dies quietly often comes down to how it's presented, not how it's built. Let's talk about making projects that people actually care about.
Problem-First Framing
Start with the problem, always. "I built a todo app" is not interesting—there are ten thousand todo apps. "I kept missing deadlines because my tasks were spread across email, Slack, and sticky notes" is a problem people recognize.
Your project overview should follow this structure:
Y Combinator's startup pitch format works for projects too - clarity over cleverness.
Showing vs. Telling
"Fast and easy to use" means nothing. Everyone claims that. Show it instead:
Demo video solving a real problem in 30 seconds. Use Loom or Screen Studio for high-quality screen recordings.
Before/after comparison. "This took 10 steps, now it takes 2" with side-by-side demonstration.
Real data if you have it. "Reduced my weekly admin time from 3 hours to 20 minutes" is concrete.
Rocket Sim for creating beautiful app store screenshots if you're building mobile apps.
The Right Amount of Polish
Too polished too early signals you over-invested before validation. Too rough signals you don't take it seriously. Find the middle:
Core functionality should actually work. People will forgive ugly design, they won't forgive broken features.
Visual design can be basic but shouldn't be broken. Use Tailwind UI components or Chakra UI to avoid design decisions while looking clean.
Copy should be clear. Doesn't have to be clever, but should be understandable. Run it through Hemingway App to catch complexity.
Don't apologize for what's not done. "This is an MVP focused on X, Y and Z coming next" is confident. "Sorry it's ugly and incomplete" makes people dismiss it immediately.
Positioning for Different Audiences
Technical audience (****** News, Dev.to):
Product audience (Product Hunt, Indie Hackers):
Creative audience (Dribbble, Behance):
Know where you're sharing and adjust framing accordingly.
Building in Public Strategy
Sharing regularly while building creates audience before launch. By the time you "finish," people are already invested.
What to share:
Twitter/X is still the main platform for building in public. Daily or weekly updates work better than sporadic posts.
WIP.co - Community specifically for makers sharing daily progress
Indie Hackers - Milestones and revenue updates resonate well here
Tools for sharing: Typefully for writing and scheduling Twitter threads Hypefury for Twitter automation and growth Buffer for multi-platform scheduling
Getting Your First Users
Launch on multiple platforms, don't rely on one:
Product Hunt - Tuesday-Thursday launches, prep your network ****** News Show HN - Technical projects, honest framing Reddit - Niche subreddits, follow self-promotion rules Indie Hackers - Product-focused community BetaList - Specifically for pre-launch and beta products
Direct outreach works better than you think. If you built something for a specific use case, find 10 people with that problem and message them personally.
LinkedIn outreach to people in your target profession Twitter/X DMs to people tweeting about related problems Email to people who write about the problem your project solves Comments on relevant blog posts, Reddit threads, forums
Measuring What Matters
For early projects, vanity metrics don't matter. Focus on:
Do people understand what it does? If 50% of visitors ask clarifying questions, your positioning is broken.
Do people come back? One-time curiosity isn't validation. Repeat usage is.
Do people tell others? Unprompted mentions mean you solved something real.
Do people pay (if monetized)? Price is the ultimate validation of value.
Use Plausible or Fathom for privacy-friendly analytics.
Hotjar or Microsoft Clarity (free) for session recordings to see where people get confused.
Iterating Based on Feedback
Most feedback is noise. Look for patterns:
If 10 people request the same feature, pay attention. If one person has a weird edge case, probably ignore it. If multiple people don't understand something, rewrite it.
Distinguish between "I want this to be different" and "I can't use this because X is broken." Former is preference, latter is critical.
Respond publicly to feedback when possible. Shows you're listening and active. Future users see your engagement.
Canny or FeedBear for collecting and organizing feature requests
When to Pivot vs. Persist
Pivot signals:
Persist signals:
Most projects *** from neglect, not from being bad ideas. If you're getting any traction at all, keep going longer than feels reasonable.
Open Sourcing Your Project
Making code public has benefits even if you don't want contributors:
When to open source:
Choose a License - Quick guide to picking appropriate open source license
Add a good README: Make a README - Template and guidelines README.so - Visual editor for creating READMEs
Projects That Work Long-Term
The projects that last solve problems their creators have. You use it, so you keep improving it. Others with the same problem find it useful.
Perfect example: side projects that start as tools for the creator's own workflow, then get discovered by others doing similar work.
Build for yourself first. If it's useful to you, it's probably useful to people like you. Find those people and share it with them.
Don't overthink it. Most successful projects started small, stayed small for a while, then gradually found their audience. The key is keeping them alive long enough to be discovered.
Share progress regularly. Consistent small updates beat rare big announcements. Shows momentum and keeps you accountable.
And if a project doesn't work? That's fine. You learned something, you made something, you shared it. That's the whole point. Start the next one.
The difference between a project that gets traction and one that dies quietly often comes down to how it's presented, not how it's built. Let's talk about making projects that people actually care about.
Problem-First Framing
Start with the problem, always. "I built a todo app" is not interesting—there are ten thousand todo apps. "I kept missing deadlines because my tasks were spread across email, Slack, and sticky notes" is a problem people recognize.
Your project overview should follow this structure:
- The problem (relatable, specific)
- Why existing solutions don't work (validates you've looked)
- Your approach (what makes it different)
- Current state (where you are now)
- What you need (feedback, users, contributors)
Y Combinator's startup pitch format works for projects too - clarity over cleverness.
Showing vs. Telling
"Fast and easy to use" means nothing. Everyone claims that. Show it instead:
Demo video solving a real problem in 30 seconds. Use Loom or Screen Studio for high-quality screen recordings.
Before/after comparison. "This took 10 steps, now it takes 2" with side-by-side demonstration.
Real data if you have it. "Reduced my weekly admin time from 3 hours to 20 minutes" is concrete.
Rocket Sim for creating beautiful app store screenshots if you're building mobile apps.
The Right Amount of Polish
Too polished too early signals you over-invested before validation. Too rough signals you don't take it seriously. Find the middle:
Core functionality should actually work. People will forgive ugly design, they won't forgive broken features.
Visual design can be basic but shouldn't be broken. Use Tailwind UI components or Chakra UI to avoid design decisions while looking clean.
Copy should be clear. Doesn't have to be clever, but should be understandable. Run it through Hemingway App to catch complexity.
Don't apologize for what's not done. "This is an MVP focused on X, Y and Z coming next" is confident. "Sorry it's ugly and incomplete" makes people dismiss it immediately.
Positioning for Different Audiences
Technical audience (****** News, Dev.to):
- Lead with interesting technical decisions
- Include tech stack and architecture choices
- Explain performance optimizations or novel approaches
- Link to code if open source
Product audience (Product Hunt, Indie Hackers):
- Lead with user value and use cases
- Show the interface and user flow
- Explain business model or monetization
- Share metrics if you have them
Creative audience (Dribbble, Behance):
- Lead with visual design and aesthetics
- Show process and iterations
- Explain design decisions and inspirations
- Include high-quality images/videos
Know where you're sharing and adjust framing accordingly.
Building in Public Strategy
Sharing regularly while building creates audience before launch. By the time you "finish," people are already invested.
What to share:
- Design decisions and rationale
- Technical challenges and solutions
- Feature additions and why they matter
- Metrics and growth if you have users
- Failures and pivots (people love authentic struggle)
Twitter/X is still the main platform for building in public. Daily or weekly updates work better than sporadic posts.
WIP.co - Community specifically for makers sharing daily progress
Indie Hackers - Milestones and revenue updates resonate well here
Tools for sharing: Typefully for writing and scheduling Twitter threads Hypefury for Twitter automation and growth Buffer for multi-platform scheduling
Getting Your First Users
Launch on multiple platforms, don't rely on one:
Product Hunt - Tuesday-Thursday launches, prep your network ****** News Show HN - Technical projects, honest framing Reddit - Niche subreddits, follow self-promotion rules Indie Hackers - Product-focused community BetaList - Specifically for pre-launch and beta products
Direct outreach works better than you think. If you built something for a specific use case, find 10 people with that problem and message them personally.
LinkedIn outreach to people in your target profession Twitter/X DMs to people tweeting about related problems Email to people who write about the problem your project solves Comments on relevant blog posts, Reddit threads, forums
Measuring What Matters
For early projects, vanity metrics don't matter. Focus on:
Do people understand what it does? If 50% of visitors ask clarifying questions, your positioning is broken.
Do people come back? One-time curiosity isn't validation. Repeat usage is.
Do people tell others? Unprompted mentions mean you solved something real.
Do people pay (if monetized)? Price is the ultimate validation of value.
Use Plausible or Fathom for privacy-friendly analytics.
Hotjar or Microsoft Clarity (free) for session recordings to see where people get confused.
Iterating Based on Feedback
Most feedback is noise. Look for patterns:
If 10 people request the same feature, pay attention. If one person has a weird edge case, probably ignore it. If multiple people don't understand something, rewrite it.
Distinguish between "I want this to be different" and "I can't use this because X is broken." Former is preference, latter is critical.
Respond publicly to feedback when possible. Shows you're listening and active. Future users see your engagement.
Canny or FeedBear for collecting and organizing feature requests
When to Pivot vs. Persist
Pivot signals:
- Nobody uses it despite understanding it (problem isn't real)
- People try once and never return (solution doesn't actually solve problem)
- Users request fundamental changes to core concept (you built wrong thing)
Persist signals:
- People use it regularly even if numbers are small
- Users tell others about it without prompting
- People complain about missing features (means they want more, not different)
Most projects *** from neglect, not from being bad ideas. If you're getting any traction at all, keep going longer than feels reasonable.
Open Sourcing Your Project
Making code public has benefits even if you don't want contributors:
- Credibility - "I built X" hits different when code is visible
- Learning - Others learn from your code, you learn from their feedback
- Portfolio - Future employers/clients can see your actual work
- Community - Open source projects attract contributors organically
When to open source:
- If you're not monetizing it, no reason not to
- If you want contributors, required
- If you're building in public, adds authenticity
- If you're abandoning it, lets others continue
Choose a License - Quick guide to picking appropriate open source license
Add a good README: Make a README - Template and guidelines README.so - Visual editor for creating READMEs
Projects That Work Long-Term
The projects that last solve problems their creators have. You use it, so you keep improving it. Others with the same problem find it useful.
Perfect example: side projects that start as tools for the creator's own workflow, then get discovered by others doing similar work.
Build for yourself first. If it's useful to you, it's probably useful to people like you. Find those people and share it with them.
Don't overthink it. Most successful projects started small, stayed small for a while, then gradually found their audience. The key is keeping them alive long enough to be discovered.
Share progress regularly. Consistent small updates beat rare big announcements. Shows momentum and keeps you accountable.
And if a project doesn't work? That's fine. You learned something, you made something, you shared it. That's the whole point. Start the next one.