How to Vet Someone Before Inviting Them to Your Side Project

How do I vet someone before inviting them to work on my side project

Vet them with a short trial, a small scoped task, a real conversation, and a check of their work history, communication, and reliability before you share access.

Start by deciding what you are actually trying to protect. For most side projects, the risk is not just bad code. The risk is time loss, broken trust, missed deadlines, vague communication, and someone disappearing after you have opened your repo, docs, or accounts.

Begin with a public profile review. Look for evidence of finished work, not just opinions about work. A GitHub profile with merged pull requests, deployed apps, issue comments, or maintained libraries tells you more than a polished bio. A portfolio that links to live products is stronger than a list of skills.

Check whether their claims line up. If someone says they ship React apps, look for React commits, release notes, or demos. If they say they handle backend work, look for code that handles auth, data modeling, tests, or deployment. When the evidence is thin, treat the claim as unproven rather than filling in the gap with hope.

Read how they communicate before you invite them into your project. Good collaborators answer directly, ask clarifying questions, and can restate a task in their own words. That matters because side projects fail as often from poor handoff as from poor code. One good signal is a person who notices ambiguity before you have to point it out.

Do one real conversation before any access. Keep it short and concrete. Ask what kind of project they enjoy, how they handle unfinished specs, what they do when they are blocked, and how they prefer to give progress updates. You are listening for how they think, not for a rehearsed pitch.

The part people get wrong is overrating friendliness and underrating process. A person can be pleasant, responsive, and still be a bad fit if they miss details, need constant prompting, or disappear when the task stops being fun. The goal is not to find someone you would chat with. The goal is to find someone who can help you finish.

Use a small paid-free trial before you invite anyone deeper. Give them one task that is useful but contained, something like fixing a bug, adding one endpoint, improving one screen, or writing one integration test. Make the task real enough to reveal their habits and small enough that a mistake does not hurt the project.

Define the trial in writing. Include the outcome you want, the stack, where the code lives, how long it should take, and what “done” means. A clear trial shows you whether they read instructions, whether they ask the right questions, and whether they can work inside constraints without turning every decision into a meeting.

Watch how they handle scope. A strong collaborator does not need everything explained twice, but they will flag missing requirements and will not silently guess on core logic. A weak collaborator may start coding quickly, but they often build the wrong thing with confidence. Confidence is not progress if the result does not fit the project.

Ask for one example of a problem they solved that went wrong at first. Then ask what they changed. You are checking for reflection, not perfection. People who can describe a mistake, a correction, and the result usually work better than people who only talk about successes.

Check references only if they are real and relevant. A reference from a teammate, client, or maintainer who actually worked with them is useful. A generic endorsement is not. Ask specific questions: Did they finish on time Did they communicate delays early Did they take feedback without defensiveness Would you work with them again

Review their code, not just the final output. Look for readability, naming, structure, tests, and whether they made reasonable tradeoffs. A collaborator who leaves a clean trail is easier to trust than someone whose work only looks good from a distance. If they use AI tools, that is fine, but they still need to understand and explain the code they hand over.

If the trial involves sensitive access, keep the access minimal. Give a branch, a fork, a local stub, or a test environment first. Do not give production keys, admin access, payment tools, or customer data until they have earned it. On a side project, a small mistake with the wrong permission can cost far more time than the trial itself.

Use a simple checklist and apply it the same way every time. Ask: Can they explain the problem clearly, do they finish what they start, do they communicate early when something changes, do they handle feedback without friction, and did they leave the codebase better than they found it. If three of those are weak, do not escalate.

The inconvenient part is that vetting takes effort before the fun part begins. That is still cheaper than onboarding someone who cannot work independently. A one-hour call and a one-task trial can save a week of cleanup. The mistake is thinking trust is something you feel. For side projects, trust is something you observe.

If you want a lightweight place to organize that process, DevConnect is built around people who test and build for real, and it stays free to use. You can use it to structure reciprocal testing instead of starting with access and optimism.

A good final filter is whether the person respects boundaries. Someone who pushes for faster access, wider permissions, or vague promises before any proof is asking you to skip the part that protects the project. That pressure is useful information. The safest people to invite are the ones who are comfortable earning the next step.

If you only do three things, do these: look for real work, run a small trial, and watch communication under a real task. That combination reveals more than a resume, and it catches the common failure modes before they reach your codebase.

FAQ

What should I ask in the first call? Ask about recent projects, how they handle unclear requirements, how they report progress, and what they do when they get blocked. Keep the questions tied to the work you actually need.

How small should the trial task be? Small enough to finish in one focused session, but real enough to show judgment. If the task cannot be described clearly in a short paragraph, it is too large for a first test.

What if they have no public portfolio? Use a direct conversation plus a paid-free sample task. No portfolio does not mean no skill, but it does mean you need more evidence before you share sensitive access.

Should I give access to my main repo during the trial? Give the minimum access needed to complete the task. A branch, fork, or sandbox is better than handing over full control on day one.

What is the biggest mistake founders make here? They confuse enthusiasm with reliability. Someone can be excited about the idea and still be inconsistent, hard to brief, or slow to finish.