A debugging checklist before you share a demo link

Treat demos as production-lite — especially when recruiters and collaborators may open them from mid-range Android networks across African cities. A Passport link that returns 500 is worse than no link because it converts curiosity into distrust in one click. The difference shows up when someone opens your work cold — from another city, on a mid-range phone, with ten minutes to decide whether to message you.

Before you publish

• Open the URL in a private window
• Test the happy path end to end
• Confirm env vars and API keys for the hosted environment
• Check mobile layout once
• Note any seed/login credentials in the project description
• Confirm HTTPS and no mixed-content blockers

Test on a phone hotspot, not only office fiber. Confirm empty states and auth gates do not trap reviewers. If the demo needs seed data, put credentials in the Passport project description where humans will actually look — not only in a buried README commit.

Throttle the network once and watch what still loads. If the happy path needs a seed script, document the command — reviewers should not reverse-engineer your database.

When something is unfinished

Label it clearly: prototype, read-only demo, or local-only. Honesty protects your reputation.

Takeaway: Ambiguous broken links look like negligence; labeled prototypes look like professional judgment.

Use clear labels: prototype, read-only demo, or local-only. Honesty protects Execution Reputation. If you cannot host yet, record a short walkthrough and say so — still better than a silent 404.

Prefer a labeled prototype with a solid README over a “production” badge on a half-working deploy. Calibrated honesty reads as seniority.

After you ship

Set a calendar reminder to re-check demos monthly. Rotate dead projects off your featured list. Prefer static exports or seedable sandboxes for long-lived Passport entries.

Prefer static exports or seedable sandboxes for long-lived Passport entries. Rotate dead projects off your featured list. Link surviving demos to challenges or collaborations so the proof graph stays connected.

When you change hosting, update every Passport reference in one pass — featured list, project page, and open applications.

Hosting choices that survive scrutiny

Document how to rebuild from the repo if the live URL dies. Avoid demos that depend on a personal laptop remaining online. Choose hosts with predictable free tiers and a redeploy path you have actually practiced once.

Pin dependency versions when free tiers break on surprise major upgrades. Leave a short deploy note with the three commands you actually use.

Incident response for featured work

If someone reports a broken demo, fix or demote within forty-eight hours and reply with the new link. That response is itself a professional signal — the same reliability you want attributed in endorsements.

Keep a short status note on the project (“redeploying Sunday”) rather than going silent. Silence reads as abandonment to collaborators and recruiters alike.

Closing

Reliability is part of Execution Reputation — protect your demos like product releases. Run this checklist on every featured Passport URL before your next application. If you stall, ask Aurora for one next action that matches your persona, hours, and target role — then ship the link.