Tweet
You made something. Maybe it's finished, maybe it's halfway there, maybe it's just an interesting experiment. Whatever it is, this is the place to share it.
This isn't about formal launches or perfect presentations. It's about showing your work, getting feedback, connecting with people building similar things, and celebrating progress. Some of the best collaborations start with "hey, I built this thing..."
What to Share
Side projects at any stage. Doesn't have to be done—sharing early gets better feedback.
Experiments and prototypes. Even if you're not taking it further, others might learn from what you tried.
Open source projects. Looking for contributors, showing what you built, or just documenting it publicly.
Tools you built for yourself. Solved your own problem? Probably solves someone else's too.
Learning projects. Built something while learning a new technology? Share it. Others are on the same journey.
How to Share Projects Effectively
Start with what it does and why it exists. "I built a tool that tracks coffee intake because I kept forgetting how much caffeine I'd had" gives immediate context.
Show, don't just tell. Screenshots, demo videos, live links. Loom for quick demos, CloudApp for annotated screenshots.
Be clear about what stage you're at. "Just starting and looking for direction" needs different feedback than "mostly done, finding bugs."
Explain what you want. Feedback on the concept? Technical review? People to test it? Co-founder to take it further? Be specific.
Demo and Documentation
Live demo is best. Vercel, Netlify, or GitHub Pages for free hosting.
If it can't be live, video demo. 60-90 seconds covering the main use case. Don't narrate every feature—show the core value.
README matters even for small projects. What it does, why it exists, how to run it locally, how to contribute. Make a README has templates.
GitHub or GitLab for code, even if you're not looking for contributors yet. Public code builds credibility.
Getting Useful Feedback
Ask specific questions. "What do you think?" gets vague responses. "Would you use this for X?" or "Is the pricing clear?" gets actionable feedback.
Don't defend your choices. If multiple people are confused by something, that's data. Fix the confusion, don't explain why it shouldn't be confusing.
Distinguish between "I wouldn't use this" and "This is built wrong." Former is preference/fit, latter is actionable feedback.
Thank people for critical feedback especially. It's harder to give and more valuable than compliments.
Sharing Unfinished Work
Half-done projects are often the most interesting to share. People see the process, not just the result.
WIP.co - Community specifically for sharing work in progress
Twitter/X building in public - Regular updates on what you're making generates audience and accountability
Be honest about what's not done yet. "Login isn't implemented, just testing the core feature" prevents confusion.
Unfinished ≠unprofessional. An MVP with clear scope is better than vaporware with promises.
Technical Projects
Include your tech stack. Helps others learn and helps potential collaborators assess fit.
Link to the repo if it's open source. Even if code is messy, public code > private code for credibility.
Explain interesting technical decisions. "Used X instead of Y because..." helps others in similar situations.
Dev.to - Developer community good for sharing technical projects
Hashnode - Developer blogging platform with engaged audience
Creative Projects
Show process, not just final output. Sketches, iterations, what changed and why.
Behance for visual work - design, illustration, motion graphics
Dribbble for UI/UX and design work
ArtStation for 3D, game art, concept art
Include tools used and techniques. Helps others reproduce or learn from your approach.
Open Source Projects
Write a clear README first. People decide in 30 seconds if they'll explore further.
Add a CONTRIBUTING.md if you want help. Explain how to set up the project locally, code style, how to submit PRs.
Choose a License - Pick appropriate license, MIT for permissive, GPL for copyleft
Use Good First Issue labels to welcome new contributors
Document your decisions in issues/discussions. Future contributors (including you) will thank you.
Non-Code Projects
Not everything is software. Essays, research, designs, videos, datasets, frameworks—all worth sharing.
Notion pages can be published publicly for writeups, documentation, frameworks
Figma Community for design files, templates, plugins
Substack for written content, research, essays
YouTube for video projects, tutorials, demonstrations
Why Sharing Matters
You never know who's working on something similar. Sharing connects you with potential collaborators.
Public work is a portfolio. Even unfinished projects show your thinking and skills.
Feedback makes everything better. Other perspectives catch blindspots you'll never see.
Accountability is real. Saying "I'm building X" publicly makes you more likely to finish it.
Teaching solidifies learning. Explaining your project helps you understand it better.
What Happens After Sharing
Some projects get lots of attention, most don't. That's normal. Value comes from feedback and connections, not upvotes.
Follow up on good feedback. "Thanks for suggesting X, I implemented it and it's much better" closes the loop.
Connect with people who engaged. They're your early user base or potential collaborators.
Share updates as you make progress. People who saw v1 want to see v2.
If a project doesn't resonate, ask why. Sometimes timing is wrong, sometimes positioning is wrong, sometimes the idea needs work.
The goal isn't virality. It's starting conversations that make your work better and connecting with people who care about similar problems.
This isn't about formal launches or perfect presentations. It's about showing your work, getting feedback, connecting with people building similar things, and celebrating progress. Some of the best collaborations start with "hey, I built this thing..."
What to Share
Side projects at any stage. Doesn't have to be done—sharing early gets better feedback.
Experiments and prototypes. Even if you're not taking it further, others might learn from what you tried.
Open source projects. Looking for contributors, showing what you built, or just documenting it publicly.
Tools you built for yourself. Solved your own problem? Probably solves someone else's too.
Learning projects. Built something while learning a new technology? Share it. Others are on the same journey.
How to Share Projects Effectively
Start with what it does and why it exists. "I built a tool that tracks coffee intake because I kept forgetting how much caffeine I'd had" gives immediate context.
Show, don't just tell. Screenshots, demo videos, live links. Loom for quick demos, CloudApp for annotated screenshots.
Be clear about what stage you're at. "Just starting and looking for direction" needs different feedback than "mostly done, finding bugs."
Explain what you want. Feedback on the concept? Technical review? People to test it? Co-founder to take it further? Be specific.
Demo and Documentation
Live demo is best. Vercel, Netlify, or GitHub Pages for free hosting.
If it can't be live, video demo. 60-90 seconds covering the main use case. Don't narrate every feature—show the core value.
README matters even for small projects. What it does, why it exists, how to run it locally, how to contribute. Make a README has templates.
GitHub or GitLab for code, even if you're not looking for contributors yet. Public code builds credibility.
Getting Useful Feedback
Ask specific questions. "What do you think?" gets vague responses. "Would you use this for X?" or "Is the pricing clear?" gets actionable feedback.
Don't defend your choices. If multiple people are confused by something, that's data. Fix the confusion, don't explain why it shouldn't be confusing.
Distinguish between "I wouldn't use this" and "This is built wrong." Former is preference/fit, latter is actionable feedback.
Thank people for critical feedback especially. It's harder to give and more valuable than compliments.
Sharing Unfinished Work
Half-done projects are often the most interesting to share. People see the process, not just the result.
WIP.co - Community specifically for sharing work in progress
Twitter/X building in public - Regular updates on what you're making generates audience and accountability
Be honest about what's not done yet. "Login isn't implemented, just testing the core feature" prevents confusion.
Unfinished ≠unprofessional. An MVP with clear scope is better than vaporware with promises.
Technical Projects
Include your tech stack. Helps others learn and helps potential collaborators assess fit.
Link to the repo if it's open source. Even if code is messy, public code > private code for credibility.
Explain interesting technical decisions. "Used X instead of Y because..." helps others in similar situations.
Dev.to - Developer community good for sharing technical projects
Hashnode - Developer blogging platform with engaged audience
Creative Projects
Show process, not just final output. Sketches, iterations, what changed and why.
Behance for visual work - design, illustration, motion graphics
Dribbble for UI/UX and design work
ArtStation for 3D, game art, concept art
Include tools used and techniques. Helps others reproduce or learn from your approach.
Open Source Projects
Write a clear README first. People decide in 30 seconds if they'll explore further.
Add a CONTRIBUTING.md if you want help. Explain how to set up the project locally, code style, how to submit PRs.
Choose a License - Pick appropriate license, MIT for permissive, GPL for copyleft
Use Good First Issue labels to welcome new contributors
Document your decisions in issues/discussions. Future contributors (including you) will thank you.
Non-Code Projects
Not everything is software. Essays, research, designs, videos, datasets, frameworks—all worth sharing.
Notion pages can be published publicly for writeups, documentation, frameworks
Figma Community for design files, templates, plugins
Substack for written content, research, essays
YouTube for video projects, tutorials, demonstrations
Why Sharing Matters
You never know who's working on something similar. Sharing connects you with potential collaborators.
Public work is a portfolio. Even unfinished projects show your thinking and skills.
Feedback makes everything better. Other perspectives catch blindspots you'll never see.
Accountability is real. Saying "I'm building X" publicly makes you more likely to finish it.
Teaching solidifies learning. Explaining your project helps you understand it better.
What Happens After Sharing
Some projects get lots of attention, most don't. That's normal. Value comes from feedback and connections, not upvotes.
Follow up on good feedback. "Thanks for suggesting X, I implemented it and it's much better" closes the loop.
Connect with people who engaged. They're your early user base or potential collaborators.
Share updates as you make progress. People who saw v1 want to see v2.
If a project doesn't resonate, ask why. Sometimes timing is wrong, sometimes positioning is wrong, sometimes the idea needs work.
The goal isn't virality. It's starting conversations that make your work better and connecting with people who care about similar problems.