The live tab is open, and you still do not know which three clicks tell the story. Most new solo developers waste the first 2 minutes of portfolio demos clicking through irrelevant code files, explaining their tech stack before showing value, or fumbling through nested navigation to find the core feature. This script cuts all that fluff, so you can showcase your project’s value and your development skills in 90 seconds flat, with a backup plan for when your live deployment fails.
Opening sentence that names the user job
Your opening line of the demo has one job: tell the viewer exactly who the tool is for and what problem it solves, no small talk, no backstory about why you built it first. For example, if you built a free inventory tracker for independent coffee shops, your opening line is “This tool lets independent coffee shop owners track perishable bean and milk inventory across 2 locations to cut monthly food waste by an average of 22%.” This line takes 10 seconds max, and immediately signals to hiring managers that you built the project to solve a real user problem, not just to practice a new framework. You do not lead with “I built this project to learn Next.js” — save that context for after you’ve shown the tool works.
Three clicks you practice until they are boring
The only on-screen actions you need to take during your core demo are three intentional clicks that show the full user journey from start to value. Any extra clicks, like navigating through settings or editing random form fields, distract from the story you’re telling. For the coffee shop inventory tracker example, the three clicks are: 1) Click “New stock log” to open a pre-built inventory template, 2) Click “Sync POS data” to pull in the last 7 days of sales data automatically, 3) Click “Generate waste report” to see which items are expiring unused and need reduced order sizes. Practice these clicks 10+ times until you can complete them without looking at your keyboard, no fumbling, no closing wrong tabs. The full 90-second demo beat sheet is mapped out below, so you can adapt it to your specific project:
| Time Stamp | Action | Voiceover Line | Visual Cue |
|---|---|---|---|
| 0:00-0:10 | No clicks, hold on landing page | State user job and core value (e.g. “This tool lets independent coffee shop owners track perishable inventory to cut food waste by 22%”) | Screen shows live tool landing page, no code or browser extensions visible |
| 0:10-0:25 | First click: Open new stock log | “Instead of manually entering every inventory item into a spreadsheet, you start with a pre-built template customized for coffee shop stock” | Click “New stock log” button, form loads pre-filled with common items like oat milk, light roast beans, and pastry supplies |
| 0:25-0:45 | Second click: Sync POS data | “The tool connects directly to most common small business POS systems to pull recent sales data, so you don’t have to cross-reference sales receipts manually” | Click “Sync POS data” button, form fields auto-populate with current stock counts from the last 24 hours |
| 0:45-0:65 | Third click: Generate waste report | “The tool flags items that are expiring before you sell through your stock, and suggests adjusted order sizes to cut waste” | Click “Generate waste report” button, dashboard loads with highlighted expiring items and recommended order cuts |
| 0:65-0:90 | Hover over report details | “I built the POS sync with a public Square API integration, and added a scheduled function that runs daily to flag expiring items before they go bad” | Hover over the “Next recommended order date” label on the report to show the dynamic calculation |
This beat sheet keeps you on track, so you never run over time or forget to mention a key technical feature you built.
Failure you show on purpose, then the fix
A perfect demo feels fake to most viewers, especially hiring managers who have seen dozens of polished portfolio projects that don’t account for real-world edge cases. Add a short intentional failure segment after your core demo if you have extra time, to show you built proper error handling and tested for non-happy-path user behavior. For the coffee shop inventory tool, for example, intentionally try to sync POS data without connecting a POS account first. Click the sync button, let the error message pop up that says “Please connect your Square or Shopify POS account first to import sales data”, then click the “Connect POS” button to show the simple OAuth flow that fixes the error. Example measurement: This failure and fix only takes 15 extra seconds, so it fits easily into most 2-minute demo slots without rushing. You don’t need to make up a big, dramatic failure — a small, realistic user mistake shows you thought through how real people will interact with your tool, not just how you want them to interact with it.
Fallback recording if the host is asleep
You never want to be the developer who says “uh, the site was working 10 minutes ago” when your live deployment goes down right before a demo. Free hosting tiers hit bandwidth limits, deployment platforms have outages, and public API keys can get rate limited without warning, so you need a fully tested fallback plan prepared 24 hours before any demo. This fallback is part of your core demo deliverable, so you never get caught off guard:
- Record a 1080p 30fps screen recording of the full 90-second happy path demo plus the intentional failure segment, with no background noise, saved to both your local desktop and a private cloud storage link you can access in one click
- Spin up the project locally on your development machine, confirm all features work without an internet connection, and leave the local server running in a background tab before your demo starts
- Capture 3 high-resolution screenshots of each core click outcome (new stock log, synced POS data, generated waste report) saved to your desktop, in case even the local server crashes
- Add a 1-sentence note at the top of your project README linking to the pre-recorded demo, so reviewers who visit your repo on their own time can watch the demo even if the live deployment is down
If your live site is unresponsive when you start your demo, just say “Looks like the live deployment is having a small outage right now, let’s pull up the pre-recorded demo and I can walk you through the local version after” — no panic, no excuses, you’re prepared.
Close that points at the README, not a slogan
Your demo close should not be a cheesy generic slogan like “this tool will revolutionize coffee shop inventory management” — viewers don’t care about overblown claims, they care about proof that you can build and document functional software. Instead, close by pointing directly to your project README, which acts as supporting evidence for everything you just showed. For the coffee shop tool example, your close is: “All the code for this project, plus a full breakdown of how I built the Square POS integration, how I tested the error handling for unconnected accounts, and a link to the pre-recorded fallback demo, are all in the GitHub repo README linked in my profile. You can also find a full project roadmap with planned features like multi-location stock transfers in the README as well.” This closes the loop by showing you’re transparent about your work, you document your development process, and you’re thinking about future iterations of the project, not just a one-off demo build.
Before your next portfolio review or hiring manager call, run through the 90-second beat sheet twice to work out any kinks, record your fallback demo, and add the demo availability note to your project README so you never waste time fumbling through a disorganized demo again.