Share and Collaborate

You’ll learn to share your work so others can find it, understand it, and build on it.

Why this matters

Your projects are your portfolio. How you present them matters as much as what you built. A live URL with a clear README turns “I messed around with some code” into “I built this — here is the link, here is the code, here is what it does.” Whether you are applying for a job, submitting a class assignment, or sharing a research tool with your lab, the ability to present your work clearly is a career-long skill.

Mental model: the back of the book

Think of a README as the back cover of a book. Before someone opens the book, they flip it over and read a short summary: what is this about, who is it for, and why should I care? A good README does the same thing for your project. It tells visitors what is inside before they open the code.

Writing a great README

Every project on GitHub should have a README.md file in the root directory. GitHub renders it automatically on the repository page — it is the first thing people see.

The template

Here is what a solid README includes:

# Project Name

One-line description of what the project does.

![Screenshot](screenshot.png)

## What it does

A short paragraph explaining the main features and what problems it solves.

## Tech stack

- Framework (e.g., Astro, React, Next.js)
- Styling (e.g., Tailwind CSS)
- Hosting (e.g., Cloudflare Pages)

## How to run it locally

1. Clone the repo: `git clone https://github.com/you/project-name.git`
2. Install dependencies: `npm install`
3. Start the dev server: `npm run dev`
4. Open the localhost URL shown in your terminal (often port 3000, 4173, 4321, or 5173)

## How to build for production

```
npm run build
```

Let AI write the first draft

You do not need to write it from scratch. Open your AI CLI tool (such as Claude Code, Gemini CLI, or your preferred tool) in your project directory and ask it to generate a README based on the actual files:

Read my project files and write a README.md. Include: project name,
one-line description, screenshot placeholder, how to install and run
locally, what it does, and the tech stack. Keep it concise -- no more
than 30 lines.

Because a CLI tool can read your local files directly, it will generate a more accurate README than copy-pasting a description into a chat window.

Review what the AI generates, adjust anything that is inaccurate, and commit the file:

git add README.md
git commit -m "Add README"
git push

A mediocre README that exists is infinitely better than a perfect README you never write.

Sharing your URL

You now have two shareable links:

1. Deployment URL — the live site from Module 11 Lesson 1 (e.g., https://my-project.pages.dev)
2. GitHub repository URL — the source code from Module 7 Lesson 4 (e.g., https://github.com/you/my-project)

Both are valuable. The deployment URL shows what you built. The GitHub URL shows how you built it and that you know how to use version control.

Where to share

Every deployed project with a README is a portfolio piece. If you are job-seeking, treat each project as evidence of your skills — not just what you built, but how you presented it.

• LinkedIn — Post about your project with the live URL. Recruiters and hiring managers click links.
• Portfolio site — If you have a personal website, add a “Projects” section with links and descriptions.
• Class assignments — Submit both the live URL and the GitHub repo link. Instructors appreciate being able to click and see it working.
• Job applications — Include your best project URLs in your resume or cover letter. A working demo is more compelling than a bullet point.
• Email and messaging — When someone asks “what have you been working on?”, a link is worth a thousand words.

Pre-share checklist

Before sending anyone the link, do a quick quality check. If you built a web application:

• Open the deployed URL in a private/incognito window (catches caching issues)
• Click every navigation link — make sure no pages are broken
• Check on your phone or resize to mobile width
• Verify no placeholder text (“Lorem ipsum”) or error messages are visible
• Confirm the browser tab title is not “Vite App” or “React App” — set a real title in your HTML or framework config

If you built a CLI tool or backend project, verify the command runs without errors on a fresh install (git clone, npm install, then run it).

Showing your work internally

Not everyone needs a GitHub portfolio. If your goal is to prove your value at work — to your manager, your team, or in your next performance review — you need a different playbook.

The “look what I built” email

When you build something useful with AI tools, send a brief email (or Slack/Teams message) to the right people. Here is the template:

Subject: Built a [tool/automation] that saves [X hours/week]

Hey [name],

I built a [brief description] using AI-assisted development.

[Screenshot or link]

What it does: [one sentence]
Time saved: [before vs. after metric]
Time to build: [how long it took you]

Happy to demo if you're interested.

Three sentences. A screenshot. A time-saved metric. That is it. Do not explain AI orchestration, prompt engineering, or your tech stack. Show results, not process.

The five-minute demo

When someone asks to see it, keep it short:

1. 30 seconds — state the problem it solves (“We used to spend 3 hours formatting the weekly report”)
2. 2 minutes — show it working (click through the tool, upload a sample file, point at the output)
3. 1 minute — show the before/after (“Here’s the old process, here’s the new process”)
4. 1 minute — answer questions
5. 30 seconds — offer next steps (“I can add [feature] if this is useful”)

The demo is about the outcome, not the technology.

The impact log

Keep a simple running document — a markdown file, a note, even a spreadsheet — tracking what you build and the impact:

## Impact Log

### 2026-03-01 — Weekly Report Automation
- **What**: Script that converts raw data export into formatted report
- **Before**: 3 hours manual formatting every Friday
- **After**: 15 minutes (run script, spot-check, send)
- **Tools used**: Claude Code
- **Build time**: 45 minutes

### 2026-02-15 — Meeting Notes Summarizer
- **What**: Prompt template that turns raw meeting notes into action items
- **Before**: 30 min writing up notes after each meeting
- **After**: 5 min review and send
- **Tools used**: Browser chat (ChatGPT)
- **Build time**: 10 minutes

This log becomes ammunition for performance reviews, promotion cases, and job interviews. The pattern is simple: what you built, how much time it saves, and how long it took to build. Over a few months, the cumulative time savings tell a compelling story.

Open-source basics

git add LICENSE
git commit -m "Add MIT license"
git push

git clone https://github.com/your-username/forked-repo.git
cd forked-repo
git checkout -b fix-typo
# Make your edits
git add .
git commit -m "Fix typo in README"
git push origin fix-typo

Getting feedback

Shipping is not the finish line — it is the starting line. The best projects improve through feedback.

Ask specific questions

Bad feedback request: “What do you think of my project?”

Good feedback requests:

• “Does the form work correctly on mobile?”
• “Is the navigation confusing on any page?”
• “Can you find the search feature without me telling you where it is?”
• “Does the data load fast enough, or does it feel sluggish?”

Specific questions get specific, actionable answers. Vague questions get “looks good!” which helps nobody.

Use AI for a code review

Open your AI CLI tool (such as Claude Code, Gemini CLI, or your preferred tool) in your project directory and ask for a review of your local code:

Review these files for bugs, readability, UX improvements,
and best practices. Give me 3 concrete improvements with
code examples.

Because a CLI tool has access to your project files directly, it can give more accurate and context-aware feedback than pasting code into a chat window.

The feedback loop

The professional workflow looks like this:

Ship --> Get feedback --> Make changes --> Push --> Auto-deploys --> Get more feedback

Every round makes the project better. The key insight: you have to ship before you can improve. A project sitting on your laptop gets zero feedback.

Key takeaways

• Your projects are your portfolio. Every deployed project with a README is a proof-of-work that speaks for itself.
• Write a README for every project. Use the template, let AI draft it, then review and commit. A mediocre README beats no README.
• Share two links: the live URL and the GitHub repo. The deployment shows what you built. The repository shows how.
• Ask for specific feedback. “Does the form work on mobile?” gets useful answers. “What do you think?” does not.
• Ship, get feedback, iterate. The professional workflow is a loop, not a straight line. You have to deploy before you can improve.