KDBM Lite · 10 / 10

Finish & Share

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

Goal

Package the build into proof you can show and explain.

Do now

Capture the screenshot, link, repo, or showcase submission and prepare a 60-second explanation.

Output

A proof package ready for trainer review or KD Showcase.

Stop when

You can show what works, explain what you checked, and name the next improvement.

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	Counts?
Minimum	Screenshot or recording, main action shown, short explanation	Yes
Good	GitHub repository plus the minimum evidence	Yes
Strong	Live Vercel URL, GitHub repository, tested main action, short explanation	Yes

Every level counts. Reach for the strongest one your accounts and network allow today, and take the minimum if they do not.

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

Do this now

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.

Submitting to KD Showcase is a strong finish when the session runs one. It is never required to complete this station.

Check yourself

I tested the main action myself, on desktop and at a narrow mobile width.
My proof shows the main action working, not just the page.
build-status.md says what passed and where the proof lives.
No secrets, keys, or private data are in what I am sharing.
I can explain the build in about 60 seconds.

You are ready when

You can show what works, explain what you checked, and name the next improvement.

Certificate eligibility later depends on attendance, submitted proof, and review.

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.