KDBM Lite · 10 / 10

Finish & Share

Test the main action, record proof, publish through GitHub and Vercel when possible, and explain what you built.

Finish & Share

What this is

Proof is evidence that your build works and that you understand it. A live URL is strongest, but a screenshot or short recording plus a clear explanation is a valid fallback.

Proof level	Evidence
Ready	Screenshot or recording, main action shown, short explanation
Strong	GitHub repository plus the Ready evidence
Strongest	Live Vercel URL, GitHub repository, tested main action, short explanation

Why it matters

Shipping forces a final check outside the coding chat. It turns a private preview into something another person can open, test, and discuss.

What to do

Test the main user action on desktop and a narrow mobile width.
For a browser-local tool, add, update, delete, save, refresh, and confirm the data returns.
Fix only the smallest issue that blocks the promised result.
Update build-status.md with what passed, what remains, and where the proof lives.
Commit and push the project to GitHub without including secrets.
Import the repository into Vercel and test the live URL.
If publishing is blocked, capture a screenshot or recording and explain:
- who it is for;
- what problem it solves;
- what you decided as the architect;
- what you tested;
- what you would improve next.

Common mistakes

Sharing a URL before testing the live main action.
Treating deployment as proof when the page is broken on mobile.
Committing .env files, keys, or private data.
Adding a large new feature instead of fixing the smallest blocker.

Next step

Share your strongest proof with the tutor, then keep the project folder: build-status.md tells your next session exactly where to continue.