Legal
Mentor code of conduct
Accepting a project on MentorBuild means accepting this code. It is deliberately specific, because the difference between good mentoring and something that damages a student's standing at their institution is a line that has to be drawn precisely.
It sits alongside our community guidelines, which apply to everyone, and our terms of service.
1. Represent yourself accurately
- Your profile must describe experience you actually have. We verify it, and we re-check when something does not add up.
- Name your employer only if you are entitled to, and never imply your employer endorses MentorBuild or your work here.
- Do not claim expertise in a domain to win a project you are not equipped to guide. Decline instead — declining costs you nothing.
- Keep your availability honest. A student choosing you is planning around it.
2. The line you must not cross
You are here to make the student capable of the work, not to do the work. This is the clause we terminate accounts over.
Do:
- Explain concepts, review what the student has written, and show them where it breaks.
- Demonstrate a technique on a separate example, so the student applies it themselves.
- Point out that an approach will not scale, is insecure, or will not survive a viva question — and say why.
- Insist the student can explain every part of what they submit.
Do not:
- Write the student's project, code, report or dissertation for them.
- Hand over a finished artefact for the student to submit as their own.
- Attend an examination, viva or interview in the student's place, or coach them to misrepresent authorship.
- Agree to any of this even when the student asks, and even when they offer to pay more.
If a student asks you to cross this line, decline and report it. You will not be penalised for the project ending that way.
3. Run the engagement professionally
- Agree milestones and a realistic timeline at kickoff, and record them in the workspace.
- Reply to a student promptly on working days. If you will be unavailable longer, say so in advance.
- Turn up to scheduled sessions on time, prepared, and from somewhere you can actually hold a working conversation.
- Keep sessions to what was booked. If the scope has grown, agree a change with the student rather than absorbing it silently or abandoning it.
- Give as much notice as possible if you must withdraw from an active project, and help hand over cleanly.
4. Give feedback that is useful
- Be direct about problems. A student who finds out at submission that their architecture was wrong has been failed, however pleasant the sessions were.
- Criticise the work, not the person, and say what to do instead.
- Acknowledge what is working. Students calibrate against your reaction.
- Never mock a student's question, in the session or afterwards.
5. Confidentiality
- Treat a student's project, brief and code as confidential. Do not reuse, redistribute or publish it.
- Do not name a student, or show their work, in your own portfolio without their written consent.
- Never bring your employer's confidential material, proprietary code or licensed assets into a student's project.
- Do not share a student's personal details with anyone outside the platform.
6. Boundaries
- This is a professional relationship. No romantic or sexual advances, comments or content, at any point.
- Keep communication in the platform workspace. Moving to private channels removes the record that protects both of you.
- Do not solicit a student for other paid work, recruitment or any other service.
- Do not ask for, or accept, payment outside the platform.
7. Payment and disputes
- Price the project on scope, honestly, before work starts. Do not inflate scope mid-project to raise the fee.
- Mark deliverables ready only when they genuinely are.
- Do not pressure a student to approve work, and never make approval a condition of a good review.
- Engage with a dispute properly. Your account of what was agreed and delivered is evidence, and refusing to give it does not help you.
8. If you breach this code
Depending on severity and history: a warning, removal from matching, suspension, or permanent removal with forfeiture of standing on the platform. Producing work for a student to submit as their own, and any form of harassment, lead to immediate permanent removal.
Payment for work already accepted by a student is still paid out. We do not use this code as a reason to keep money owed to you.
9. Questions and appeals
If you are unsure whether something crosses the line in section 2, ask before you do it: contactmentorbuild@gmail.com. To appeal a decision, email contactnavatrix@gmail.com within 30 days.