Guides

How to get feedback on side projects

Getting useful feedback on a side project is not about dropping a link and hoping strangers magically understand what you need. Good feedback starts with clear context, a specific question, and a project that is easy to review.

A side project can improve faster when other people point out confusing flows, missing details, weak positioning, bugs, design problems, or unclear value. But vague feedback requests usually get vague replies.

Why feedback matters

When you build alone, it is easy to become blind to your own project. You already know what every button means. You already know why each page exists. A new visitor does not.

Feedback helps reveal what is unclear from the outside.

Good feedback can help you find:

Do not ask for “any feedback”

The weakest feedback request is:

I built this. Any feedback?

That puts all the work on the other person. They have to understand the project, guess what matters, test random things, and decide what kind of response you want.

Better:

I built a platform for developers to document live projects. I am trying to understand if the homepage clearly explains the difference between live projects and finished projects. Could you check the landing page and tell me what feels confusing?

That is easier to answer because the request is specific.

Step 1: Explain what the project is

Before asking for feedback, explain the project in one or two clear sentences.

A good explanation includes:

Devmaniac is a build-in-public platform for developers. It helps builders track live projects, document coding progress, and turn real work into proof of skill.

If people cannot understand the project quickly, their feedback will usually be about confusion instead of improvement.

Step 2: Share the current stage

Tell people whether the project is an idea, prototype, MVP, live product, redesign, or finished project.

This sets expectations.

Do not present an early MVP like a mature platform. People judge more fairly when they know the stage.

Step 3: Ask one specific question

Specific questions get better answers.

Instead of asking:

What do you think?

Ask:

One sharp question beats ten vague ones.

Step 4: Make the project easy to test

If you want feedback, reduce friction.

Make sure people have:

If your project requires too much effort to understand, most people will bounce. That is not because they hate you. It is because the internet has the attention span of a caffeinated squirrel.

Step 5: Tell people what kind of feedback you want

Different people can give different types of feedback.

Ask for the type you need:

This helps people respond in the right direction.

Step 6: Share a live project page

On Devmaniac, a live project page can make feedback easier because it gives people context before they respond.

A good live project page can show:

This is better than sending a naked link with no explanation. Context makes feedback sharper.

Step 7: Do not argue with every reply

Some feedback will be wrong. Some will be lazy. Some will be painfully correct.

Do not treat every response like a court battle.

Your job is to look for patterns. If one person misunderstands something, maybe it is random. If five people misunderstand the same thing, the project probably has a clarity problem.

Feedback is not a command. It is signal.

You still decide what to change.

Step 8: Document what you changed

After receiving feedback, write a journal update explaining what changed.

This turns feedback into proof of work.

Example:

Several users said the difference between live projects and finished projects was unclear. I updated the onboarding guide, changed the create menu labels, and rewrote the docs page to explain live projects earlier.

That shows you listen, decide, and improve.

Where to ask for feedback

Good places to ask include communities where people understand the type of project you are building.

Do not spam the same message everywhere. Match the request to the community.

Feedback request template

Use this when asking for feedback:

I built [project name], a [short explanation] for [target users]. It is currently at [stage]. I am looking for feedback on [specific area]. Could you check [link] and tell me [specific question]?

Example:

I built Devmaniac, a build-in-public platform for developers who want to track live projects and document coding progress. It is currently an early MVP. I am looking for feedback on onboarding clarity. Could you check the signup/profile flow and tell me what feels confusing before posting the first live project?

What to avoid

Avoid feedback requests like:

Feedback is useful only if you are willing to hear uncomfortable things. Praise feels good, but clear criticism builds the product.

How Devmaniac helps with feedback

Devmaniac helps you collect and act on feedback by giving your project a clear public page.

Instead of asking people to understand your project from one random post, you can send them a live project page that shows the goal, status, stack, links, images, and progress journals.

After you receive feedback, you can post a journal update showing what you changed. That makes improvement visible.

The core idea

A good feedback request should answer:

What is this project, what stage is it in, and what specific feedback do I need right now?

If your request answers that, you are much more likely to get feedback that actually helps.

Next Learn about profiles →