In this chapter
Anna finishes her project like a professional — a proper README, a public GitHub repository checked for secrets, a development workflow that deploys from main, and a tagged v1.0.0 production release — then demos it at Hack Day. Reviewing Acts 15, 16, 18, 19 and 24 one last time in her own work.
The Problem in Real Life
2:00 PM. Demos start at 4. Anna could add another feature. Instead she remembers Act 25 — Mark's repo, and the hour she lost to an outdated .env.sample. "Two hours left," she says. "I'm spending them on making this usable by someone who isn't me."
John, passing with his clipboard, makes another mark. He doesn't say what it means.
A project nobody else can run isn't finished.
Anna
"It Works for Me" vs. Something Others Can Use, Run and Trust
Nobody knows what it is
Without a README, visitors leave a repository within seconds.
Public means public
Making a repo public exposes its whole history — including any secret ever committed.
How do changes get to production?
Without a defined workflow, the next change goes out by hand — and Act 19 happens again.
Documentation, a README, GitHub, a Development Workflow and a Production Release
The shop-opening analogy: before opening day, a good shop owner writes the sign on the door (what we sell, opening hours), a staff handbook (how to open up, how to close, what to do if the till breaks), checks the locks one more time, and then holds a proper opening. Shipping a project is the same.
- The README — the sign on the door (Acts 16, 24, 25): what it is (one sentence and a screenshot); the live link; features; the tech stack; how to run it locally (exact commands —
docker compose up, migrations, seed data); the environment variables (names only, with.env.example); how to run tests; the API endpoints; the folder map; and known limitations and next ideas. She writes it, then follows it herself on a fresh clone to prove it works. - Other documentation (Act 24):
.env.examplewith every real variable (checked against the code, Act 25), short comments where the "why" isn't obvious (the unique constraint, the position query), and adocs/decisions.mdwith two short decision records: why sessions instead of JWTs, why positions are calculated rather than stored. - A public GitHub repository — check before you publish (Acts 15, 22): before making the repository public, she checks the whole history, not just the current files: secret scanning, a search of
git log -pfor anything like a key or password, and confirms.envwas ignored from the first commit. (If a secret had ever been committed: rotate it first, then clean history — Act 22.) She adds a licence and a short description. - A development workflow — how changes reach production (Acts 15, 18, 19):
mainis protected: changes arrive through pull requests (yes, even from herself) that must pass CI. Merging tomainbuilds the image and deploys it automatically, with migrations and a health check. Rollback means redeploying the previous image. She writes this in the README too. - A production release (Act 18): she tags the first release
v1.0.0(Act 16's semantic versioning) with short release notes: what it does, how to use it, what's next. From now on, a new feature means a new MINOR version, a fix a PATCH.
| Section | Content |
|---|---|
| What it is | Event waitlists: organisers create events, fans join and see their position |
| Live demo | https://waitlist.anna-builds.example |
| Stack | Node.js 20, Express, PostgreSQL, Docker, GitHub Actions |
| Run locally | docker compose up · npm run migrate · npm run seed |
| Environment variables | DATABASE_URL, SESSION_SECRET, LOG_LEVEL (see .env.example) |
| Tests | npm test (unit + integration, needs Docker) |
| API | Six endpoints with examples |
| Deployment | Merge to main → CI → image → deploy; rollback = previous image |
| Limitations / next | No email notifications yet; no admin UI |
| Step | Acts |
|---|---|
| Warm-ups: CLI calculator, file organiser | 06, 07, 08 |
| REST API + database + CRUD | 12, 13, 23 |
| Authentication and authorization | 22 |
| Git workflow and tests | 15, 17 |
| Container, deploy, domain, HTTPS | 12, 19, 20, 21 |
| Logging and monitoring | 17, 19, 21 |
| README, GitHub, workflow, release | 16, 18, 24, 25 |
git log -p | grep -iE "secret|password|api[_-]?key|sk_live" # search ALL history, not just todaygit ls-files | grep -E "^\.env$" # must print nothinggit switch main && git pullgit tag v1.0.0 -m "Event Waitlist v1.0.0 — first production release"git push origin v1.0.0
4:30 PM — the demo: Anna shares her screen. She shows the live app on her phone — "You are #42 in line" — then the README, then the CI checks on her last pull request, then the error tracker, then the v1.0.0 release. She breaks one thing on purpose (stops the database), shows the uptime alert arriving on her phone, and fixes it. Then she says the sentence she's been practising: "Everything in this project is something I learned this year."
The close: the judges confer. John doesn't announce a winner straight away. He walks over and shows her the clipboard: every step she took has a tick next to it, plus one note at the bottom — "Act 04: couldn't run node. Act 27: built and shipped this, alone." Samantha reads it over his shoulder and asks whether the waitlist could become a real BlueTicket feature. Anna grins. "Give me a sprint."
Key Takeaway
Finish a project so others can use, run and trust it: a README with what it is, the live link, the stack, exact local setup, environment variables, tests, endpoints and limitations — verified on a fresh clone; a complete .env.example and short decision records; a public repository checked for secrets across its whole history; a protected main branch where PRs must pass CI and merging deploys automatically; and a tagged v1.0.0 release with notes.
Why This Matters
A finished, documented, deployed project with a real Git history, tests, CI and a release is the single strongest thing a beginner can show an employer — proof that you can take something from an empty folder to production on your own. And the habits of finishing well are the ones teams value most.
Hack Day is over, and Anna has something she never had a year ago: proof — to herself and to anyone — that she can build software from nothing. One question remains, and John asks it over the last slice of pizza: "So. What do you want to do next?"
