A resume lists claims. A deployed demo is evidence. When I want to show that I can do something, I build a tiny project around that one skill, ship it to a public URL, and write a README that explains the decisions.

This post is the pattern I use to do that.

The benefits of this approach over a traditional resume:

  • Verifiable proof: a live URL lets a reviewer confirm the skill works, not just read a claim.
  • Scope discipline: one skill per demo prevents feature bloat and keeps the project finishable in hours, not weeks.
  • Decision transparency: a README that explains trade-offs shows judgment, which is harder to fake than a bullet point.
  • Searchability: public repos and deployed demos are indexed and shareable, increasing the chance a recruiter finds your work.

The idea: one skill, one demo

The biggest mistake I see in portfolio projects is scope creep. A "simple search demo" turns into a full app with auth, dashboards, and a database before anything ships. The skill gets buried under features.

I avoid that by picking one skill and one constraint. For this example, the skill is client-side filtering and the constraint is no external libraries.

That means no React, no Lodash, no build tools. Just an HTML file, some data, and a search box.

Here is how I pick the skill and constraint for a demo:

  1. Identify one specific skill you want to prove (e.g., client-side filtering, debounce handling, accessibility).
  2. Choose a constraint that forces the skill to be visible (e.g., no libraries, no framework, single file).
  3. Define a clear success criterion — a measurable behavior like "filter 500 rows in under 16ms per keystroke."
  4. Time-box the build to a single sitting so scope creep is physically impossible.
  5. Write the README before you ship so the decisions are fresh.
Career progression checkpoint illustration for this section.

The demo

Here is the entire project. It fits in one file:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Skill Proof: Search</title>
  <style>
    body { font-family: system-ui, sans-serif; padding: 20px; max-width: 600px; margin: 0 auto; }
    input { padding: 10px; width: 100%; box-sizing: border-box; margin-bottom: 20px; font-size: 16px; }
    .item { padding: 10px; border-bottom: 1px solid #eee; }
  </style>
</head>
<body>
  <h1>Employee Directory</h1>
  <input type="text" id="search" placeholder="Type to filter names...">
  <div id="results"></div>


  <script>
    const data = Array.from({ length: 500 }, (_, i) => ({
      id: i,
      name: `Employee ${i + 1}`,
      role: i % 3 === 0 ? 'Engineer' : 'Designer'
    }));


    const list = document.getElementById('results');
    const input = document.getElementById('search');


    function render(items) {
      list.innerHTML = items.map(i =>
        `<div class="item"><strong>${i.name}</strong> - ${i.role}</div>`
      ).join('');
    }


    render(data);


    input.addEventListener('input', (e) => {
      const term = e.target.value.toLowerCase();
      const filtered = data.filter(item =>
        item.name.toLowerCase().includes(term)
      );
      render(filtered);
    });
  </script>
</body>
</html>

That is the whole thing. It demonstrates data generation, DOM updates, and event handling without any framework.

How I deploy it

I push the file to GitHub, then deploy it to a static host like Vercel or Netlify. The exact host does not matter much. What matters is that the code is running somewhere I do not control.

Code on my hard drive is invisible. A live URL proves it works outside my machine.

My deployment steps:

  1. Initialize a git repo and push the project to a public GitHub repository.
  2. Connect the repository to a static hosting provider (Vercel, Netlify, or GitHub Pages).
  3. Confirm the build settings — for a single HTML file, no build command is needed.
  4. Deploy and copy the live URL into the README.
  5. Open the URL in an incognito window to confirm it loads without local dependencies.

Static host comparison

HostFree TierBuild Command NeededCustom Domain on Free PlanBest For
VercelYesNo (auto-detected)YesFrontend demos, instant deploys
NetlifyYesOptionalYesStatic sites, form handling
GitHub PagesYesNoYes (via CNAME)Repos already on GitHub

How I document it

A good README is what turns a demo into evidence. Every README I write includes these sections:

  • Live demo link so a reviewer can click and see it run immediately.
  • Source code link so the implementation is auditable.
  • Goal stating the single skill being proven.
  • Constraint listing what was deliberately excluded.
  • What I learned capturing trade-offs and surprises discovered during the build.

My READMEs follow this shape:

# Skill Proof: Client-Side Search


**Live demo:** [URL]
**Source code:** [URL]


## Goal
Demonstrate performant array filtering on 500 records using vanilla JavaScript.


## Constraint
No external libraries.


## What I learned
- Native `filter` is fast enough for this size of dataset.
- Re-rendering the full list on every keystroke is acceptable at 500 items but would need virtualization at larger sizes.

What makes a small project better than a tutorial

A tutorial teaches you a concept. A small project proves you can apply it. The difference matters to anyone reviewing your work.

When a reviewer looks at a tutorial repo, they see the same structure they have seen a hundred times: the same component names, the same file layout, the same CSS. It tells them you followed instructions. It does not tell them you can make decisions.

A small project, by contrast, has your fingerprints on it. You picked the constraint. You wrote the README. You chose what to leave out. You hit a bug and fixed it. Those choices are what a reviewer actually evaluates, because those are the choices you will make on the job.

The specific things a small project shows that a tutorial does not:

  • Scope judgment. You decided what was in and what was out. Tutorials do not let you practice this.
  • Constraint reasoning. You picked a constraint and stuck to it. That shows discipline, not just capability.
  • Deployment literacy. You shipped it to a live URL. That means you understand build, deploy, and the difference between local and production.
  • Written communication. Your README explains decisions in plain language. That is a skill most tutorials never exercise.

Specific small projects I have used

Here are real examples of small projects I built to demonstrate specific skills, and what each one was for:

  • AnimalSounds — a vanilla JS soundboard deployed to GitHub Pages. The skill I was proving was "I can ship a Vite project to GitHub Pages and handle base path configuration." It led to a concrete debugging note about deployment that I still reference. (Live demo, Source)
  • TriangleDemo — a TypeScript WebGPU project that renders a single triangle. The skill was "I can configure a WebGPU render pipeline from scratch." It proved low-level graphics literacy, which is hard to fake. (Live demo, Source)
  • The client-side search demo above — vanilla JS, no libraries, 500 records. The skill was "I can do performant DOM filtering without a framework." It is small enough to read in one file and verify in one click.

None of these are full applications. None of them have auth or a database. That is the point. Each one proves exactly one thing, and a reviewer can verify it in under a minute.

How to present a small project to an employer

A small project only works as evidence if it is presented well. Here is how I structure the presentation so a reviewer can evaluate it fast:

  1. Put the live demo link first. Before the README prose, before the repo link. The reviewer should be able to click once and see it run. If the demo does not load, nothing else matters.
  2. Write a README that leads with the goal and constraint. Two lines at the top: what skill this proves, and what you deliberately left out. A reviewer who reads only those two lines still understands the project.
  3. Include a short "what I learned" section. This is where judgment shows. If you write "I learned React," you have said nothing. If you write "native filter is fast enough at 500 rows but would need virtualization at 5,000," you have shown you understand the trade-off.
  4. Link the source code next to the demo. Not buried at the bottom. A reviewer who wants to audit the implementation should not have to hunt for it.
  5. Add it to your portfolio or resume as a bullet with a link. Not "Built a search demo." Instead: "Built a vanilla JS client-side search filtering 500 records in under 16ms per keystroke — [live demo], [source]." The specificity is what makes it credible.

Projects that led to conversations

I will be honest: a small project does not guarantee an interview. But it changes the conversation when one happens.

When a recruiter or hiring manager has clicked through a live demo before a call, the call starts differently. They do not ask "so, do you know JavaScript?" They ask "I saw your search demo — why did you choose vanilla JS over React for that?" That is a better question, and it is the question a small project is designed to produce.

The AnimalSounds project specifically has been useful as a deployment reference. When a conversation turns to CI/CD or static hosting, I can point to a real repo with a working GitHub Actions workflow and say "here is how I handled it." That is more convincing than claiming I understand deployment on a resume.

The pattern is consistent: the project does not get you the job. It gets you a better conversation. And a better conversation is where the actual hiring decision happens.

Closing

If you want to prove a skill, build the smallest possible demo that exercises it, ship it, and write down what you learned. One skill. One URL. One note. That is more useful than a feature list no one reads.

References