Chinat · August 17, 2026

Demos That Never Die

In June I built a project at the NYC Multimodal Hackathon called Reels for Real. It pulled the week's photos off my iPhone, used AI to filter out the receipts and screenshots and accidental pocket shots, and turned the real moments into a short movie clip that got texted to my mom every Sunday. She flew in from Hong Kong to watch me build it. The demo worked. The judges remembered it.

Then the event ended, and the project did what every hackathon project does. It died. The Vercel link is a 404. The repo is the only proof it ever existed.

I see this from both sides, because I also organize hackathons: SEA Hacks in Hong Kong, a healthcare AI hackathon in Kuching earlier this month. Every event produces two artifacts: a winners announcement and a graveyard. Judges clicking through submissions hit dead links within weeks. Teams that poured a weekend into something real are left pointing recruiters at a repo nobody will ever clone and run.

Recently I got to check out Blaxel, which gives you dedicated microVMs that spin up environments in under half a second, suspend to zero when nobody is using them, and keep their memory and filesystem intact. Every sandbox can expose a public preview URL. Reading that feature list, I had one question: could I bring back a dead hackathon project with just a quick script?

The experiment

Here is the code. About 40 lines against the Blaxel SDK: point it at a repo, get back a live URL.

import { SandboxInstance } from "@blaxel/core";

const sandbox = await SandboxInstance.createIfNotExists({
  name: "reels-revival",
  image: "blaxel/node:latest",
  memory: 4096,
  ports: [{ target: 3030, protocol: "HTTP" }],
  ttl: "168h",
});

// git clone + npm install run as sandbox processes, then:
await sandbox.process.exec({
  name: "web",
  command: "npx next dev -H 0.0.0.0 -p 3030",
  workingDir: "/app/reels/frontend",
  waitForPorts: [3030],
});

const preview = await sandbox.previews.createIfNotExists({
  metadata: { name: "reels-live" },
  spec: { port: 3030, public: true },
});
console.log(preview.spec?.url);

The cool part: I did not write this by hand. I described what I wanted to Claude Code and it one-shotted the script against the Blaxel SDK, working on the first run. That is a big part of why Blaxel has been so pleasant to build with: the platform is legible enough to agents that the tooling writes itself.

Measured numbers, not marketing numbers:

• Sandbox boot to DEPLOYED: 356ms
• Clone plus npm install: about 90 seconds, the bulk of the wall clock
• Next.js dev server up and listening: 1.1 seconds
• Total, from 404 to a working public URL: about two minutes

The resurrected project now runs on a microVM that suspends when nobody is looking and wakes the moment someone clicks. When the sandbox's TTL eventually expires, rerunning the script brings it back in two minutes, which is rather the point.

What actually came back

First pass: just the frontend. The photo pipeline ran on my Mac with API keys and a launchd job, so the shiny "Generate this week's reel" button rendered perfectly and did nothing. The body was walking; the brain was missing.

So I ran the second half of the experiment: resurrection plus repair. I pointed Claude Code at the gap and had it play repair agent. It read the pipeline source, worked out the data contract the frontend expects (a set of JSONL work files the classifier and curator write), and rebuilt the backend inside the sandbox, with one substitution: my camera roll lives on my Mac, so a demo photo feed stands in for the Photos-library pull. A few minutes later the dead landing page had become this:

That is the real dashboard doing real work again: 14 photos pulled, near-duplicates clustered, junk rejected with reasons, the top 8 curated into the reel, and the iMessage to Mom drafted. What stayed stubbed, because honesty: the Photos-library pull, the video render, and the actual send, which need my Mac and paid API keys.

The product version writes itself: an agent that lives inside the sandbox, reads the README and .env.example, stubs what it can fake, wires the keys it is given, and reports on what it cannot revive. What I just did is that loop, run once by hand. Blaxel is built for exactly this shape, since the agent doing the fixing gets its own isolated machine with the project already on the filesystem.

Your hackathon projects deserve a second run

This changes what a hackathon portfolio can be. Every builder I know has a graveyard of weekend projects that were genuinely impressive for 48 hours of work, and none of them are demoable today. Resurrecting one is a two-minute script, which means the whole graveyard can come back: pin a live link next to each repo and your GitHub stops being a list of READMEs and becomes a portfolio someone can actually click through. And because each sandbox suspends the moment nobody is looking and wakes when the next visitor clicks, a revived project just sits there, ready, indefinitely.

Every hackathon I run collects submissions as GitHub links. A pipeline that clones each one into a sandbox, builds it, and pins a preview URL next to the Devpost entry means judges never see a dead link, and a team's weekend project is still demoable when a recruiter asks about it in November.

Demos are the best proof of work a builder has. They should not expire when the Vercel free tier rotates. Now they don't have to.

Built and measured on Aug 17, 2026. The revival script is 40 lines; the project it revived is edumame/reels-for-real.

← Back to all posts