A Small Laptop Is a Full Build Kit: Bootstrapping with a Chromebook, Claude, and GitHub

A small laptop is a full build kit. Here's how far mine went.

TL;DR: A reader suggested I publish the full bootstrapping path behind an app I built on a 4 GB Chromebook: editor, auth, build, deploy, and recovery. So I did, and then I pushed the same little laptop through three more builds and a few stress tests to see where it would break. The Chromebook never broke a sweat. Through five rounds, a broken deploy, and a 44-second fix, its CPU stayed between 5% and 15%.

The comment landed while I was still answering replies on my last post.

Alex Shev, creator of Terminal Skills, a free, open-source library of skills that extend AI coding agents like Claude Code, wrote that building on constrained hardware shows which parts of a workflow are essential, and that publishing the bootstrapping path would make a useful guide for other builders working with limited machines.

That comment changed how I saw the whole thing. I built that app because my wife was sick and this little laptop was what I had with me. I usually build on a bigger one. I never thought of what I did as a guide. Alex's idea helped me see it could be one: if a small laptop is what someone has to build with, the exact steps I took might be what they need. So this post is that guide, step by step. I wrote it on the same laptop: an HP Chromebook 11a with 4 GB of memory.

The kit

That's the whole list. Nothing installed on the laptop.

Here's everything this post covers, in 46 seconds. Claude recorded it, and Round 4 explains how.

Round 1: You can ship a live app with no editor

Round 1 already happened. A few days ago, on vacation in Mexico City, my wife got sick and I built her a digital bell from the Chromebook: a page of big buttons where tapping "Té, por favor" opens a text to me, already written. The full story is in A Builder in CDMX: Flu Edition. Here's the bootstrapping path Alex suggested I write up.

Editor: there wasn't one

I never opened an editor or a terminal. I described what I wanted in the Claude chat, answered a few multiple-choice questions about buttons and colors, and Claude wrote the code in its cloud workspace. The chat was the editor.

Auth: one account, one approval

I created an empty repository on GitHub, the same way anyone does at github.com/new. Then I approved Claude's access to that one repository. That was the only sign-in step.

Build: on someone else's computer

Claude cloned the repository, wrote the files, took screenshots to check its own work, committed, and pushed. All of it ran in Claude's cloud workspace, not on my laptop. When I checked the Chromebook right after, here's what it showed:

Deploy: three clicks

Claude couldn't turn on GitHub Pages from its side, so I did: Settings, Pages, deploy from the main branch, Save. A minute later the app had a public address. The repo is here if you want to see every file.

Recovery: when something goes wrong

Two kinds of trouble came up. My Wi-Fi dropped once during this build, and nothing seemed lost (Round 5 has the honest version of that story). And later I broke a deploy on purpose to time the fix (it's in the capability table). Short version: the work lives in the cloud and on GitHub, not on the laptop, so a hiccup on the laptop doesn't undo it.

Try it yourself

1. Create a free GitHub account.
2. Make an empty repository at github.com/new. Check "Add a README file."
3. In a Claude chat, describe the small thing you want to build. Ask Claude to interview you one question at a time.
4. When Claude asks for access to your repository, approve that one repository.
5. When the files are pushed, turn on Pages: Settings, Pages, main branch, Save.
6. Open your link. This uses Claude Code, which comes with Claude's Pro and Max plans, not the free plan. More in "What it costs." I did all of this in the Claude app, so the approval screen may look a little different wherever you use it.

Round 2: You can make interactive 3D, and your laptop can draw it

Round 2 was a callback to Round 1: strings of papel picado flags in 3D, swaying in the wind across a dusk sky. You can drag to spin it, pinch or scroll to zoom, and when you let go it slowly turns on its own.

Try it: Papel picado, in 3D. The code is here.

This round tested the laptop differently. Building it happened in the cloud, like Round 1. But drawing 3D happens on the device you're looking at, many times a second. So for the first time, the Chromebook had real work to do.

One library, no 3D tools

The whole scene is one HTML file and one library, three.js, which draws 3D in the browser. The flags are flat squares with a cut-paper pattern painted on, and their ripple is plain math run every frame. No 3D modeling software, nothing installed.

Hardening the design

The first version worked. Then I asked Claude, as a design partner, what it would change. It suggested four things, and I said yes to all four:

Testing it caught one more: the instructions at the bottom disappeared the first time I clicked, so a reader who looked away lost them. Now they stay on screen.

It also told me what to skip: shadows and a 3D ground. They look great, and they're the most expensive things to draw. On a small laptop, I think the best design choices are the ones that leave things out.

What the Chromebook showed

I opened the scene from the live page and put it side by side with ChromeOS Diagnostics, so both stayed on screen. That mattered: the scene pauses when its tab is hidden, so my first reading, with Diagnostics covering it, caught the scene resting instead of working.

Sixty frames per second is as smooth as most laptop screens can show. Drawing 3D tripled the CPU, from 5% to 15%, and the laptop still had most of its power to spare. One reading each, not a benchmark.

Round 3: You can make animated diagrams to explain your work

Round 3 is the bootstrapping path itself, drawn as a diagram you can play. Six steps run from the laptop to a live link, and each is colored by where it happens: on the laptop, in Claude's cloud workspace, or on GitHub.

Try it: The bootstrapping path.

The diagram makes the article's main point visible. Of the six steps, only two happen on the laptop: describing what you want, and opening the link at the end. Everything in between happens somewhere else.

It has one button I'm especially fond of: What if the Wi-Fi drops? Press it, and the link between the laptop and the cloud breaks into an orange dashed line while the thread keeps going. My Wi-Fi dropped once while I was building Round 1, and Round 5 says what I know about it.

The back and forth

The first version was not the one you see. I tested each version on the Chromebook, told Claude what felt off in plain words, and Claude changed it and pushed again. Here's the whole loop, in order:

Six versions in about twenty minutes, all from the same chat. To me, that's the feedback loop Alex was asking about. Each fix took one sentence from me and one push from Claude, and the laptop never did more than show me the result.

No libraries this time: plain HTML, CSS, and a little JavaScript. It also starts paused if your device asks for reduced motion, and a screen reader reads each caption as the steps change.

What the Chromebook showed

Same method as Round 2: the diagram playing on the right, Diagnostics on the left.

The diagram barely registered: 6%, one point above resting. The processor was running at 0.91 GHz, about half its top speed, which usually means it has little to do. In my test, a plain page with a little motion cost the laptop almost nothing. One reading each, not a benchmark.

Round 4: You can make a demo video without video software

Watch the tour · Recording script

I asked for a tour of the whole kit, Necesito included. No screen recorder, no editor, nothing installed on the Chromebook.

Claude wrote a script that opens a browser in its cloud workspace, clicks through every round, and records what it sees. Then ffmpeg, a command-line video tool, turned the recording into an MP4. The laptop's only job was to play the result.

The tour GIF at the top of this post is this round.

What the video does and doesn't show:

What the Chromebook showed

Same method: the video playing on the right, Diagnostics on the left.

Playing the video cost about the same as the diagram. The interesting part to me: the video shows the 3D flags, but here the laptop is only playing back pictures, not drawing them. That's half the CPU of Round 2. Memory was lower because I had more tabs open this time. One reading each, not a benchmark.

Round 5: A dropped connection, and what I can't tell you

My Wi-Fi dropped at some point during the Necesito build. I know it happened. I don't remember when. We were either brainstorming or Claude was reworking something I'd asked for.

I didn't write it down, because nothing seemed wrong. When the connection came back, the chat picked up where it left off, and I kept going.

While writing this post, I asked Claude to look back through the chat for the drop. It couldn't find one. No repeated messages, no cut-off replies, no "are you still there?" The chat doesn't record times, so a pause leaves no gap to spot.

Here's my honest read. The build runs in Claude's cloud workspace, not on the laptop, so the laptop losing Wi-Fi doesn't stop the work. It just stops me from seeing it for a minute. That's my understanding of how it works, not something I tested.

If you want proof instead of a memory, it's an easy test to run yourself: start a build, turn off your Wi-Fi for a minute, turn it back on, and see what's waiting.

The capability table

Alex came back with a sharper ask: make the 4 GB limits concrete. In his words, the point isn't proving everyone should work this way. It's showing the smallest setup that still preserves a reliable feedback loop. So I measured it.

Here's what each tab was using, from Chrome's Task Manager (Search + Esc on a Chromebook):

About that failed deploy: GitHub caught the broken file 31 seconds after the push, and the live page stayed on the last good version the whole time. Then I typed two words, "fix it," and 44 seconds later the deploy was green. I didn't open GitHub, read an error log, or touch a file. On this setup, recovery is a sentence. One caveat: Claude knew exactly what it broke, so this is a best case. A real mystery bug would take longer.

The heaviest thing on my laptop wasn't anything I built. It was the chat I built it in, and that chat is a long one: every round in this post happened in it. Everything I made used less than the tools I made it with.

What it costs

Prices are from Claude's pricing page as of November 2026.

I want to be clear about one thing: I built all of this on Max. I haven't tested whether this much work fits inside Pro's usage limits. Something the size of Round 1, one small app, feels like it should. Five rounds back to back might not. If you try it on Pro, I'd love to hear how far you got.

What a 4 GB laptop can't do

This setup works because the heavy lifting happens somewhere else. That's also its limit. Here's what I'd still want a bigger machine for:

None of these stopped me. They're the edges I found, and they're worth knowing before you start.

A deeper dive

For anyone curious about what's under the hood, here's the technical layer under the rounds.

The stack. Static HTML, CSS, and plain JavaScript on GitHub Pages. One library in the whole kit: three.js r128 from a CDN, for Round 2. No build server, no framework, no bundler. Necesito has a tiny Node script (build.js) that writes index.html, run in Claude's workspace, not on the laptop.

A secret that never touches the repo. Necesito needs my phone number, but the number isn't in any file. It rides in the link after the #, which browsers never send to the server. The page reads it, accepts digits only, and builds the text links:

var raw = (location.hash || "").replace("#", "");
var ok = /^[0-9]{10,15}$/.test(raw);
var phone = raw.length === 10 ? "+1" + raw : "+" + raw;
// iOS format: sms:NUMBER&body=TEXT
button.setAttribute("href", "sms:" + phone + "&body=" + body);

Anything that isn't 10 to 15 digits turns the buttons off. Before this, the number was in the first commit, so I rewrote the history to one clean commit. Worth doing early, while the repo is minutes old.

Keeping 3D light on a small device. Two settings did most of the work in Round 2:

// Cap sharpness: high-res screens can't multiply the pixel count past 1.5x
renderer.setPixelRatio(Math.min(window.devicePixelRatio || 1, 1.5));

// Stop drawing when the tab is hidden, so a background tab costs nothing
document.addEventListener("visibilitychange", function () {
  if (document.hidden) { running = false; cancelAnimationFrame(rafId); }
  else if (!running) { running = true; rafId = requestAnimationFrame(tick); }
});

The second one also explains my first bad reading: with Diagnostics covering the tab, the scene had paused itself.

How the failed deploy failed. GitHub Pages runs Jekyll unless the repo has a .nojekyll file. Claude pushed a Markdown file with an unclosed Liquid tag ({% raw %}{% if broken %}{% endraw %}), and the Pages build failed in 31 seconds. GitHub kept serving the last good build, so the live site never went down. Deleting the file and pushing fixed it in 44 seconds.

The demo video. Playwright drives headless Chromium through each page and records it, then ffmpeg encodes the MP4. Fonts and three.js are routed to local copies so the recording doesn't depend on the network. The script is in the repo.

The limits to know up front:

• Static only. GitHub Pages can't run a server, hold a database, or keep API keys secret. Anything that needs one of those needs a different host.
• Public repo. Free Pages needs a public repo, so everything in it is visible, history included.
• Small samples. Every number in this post is one Diagnostics reading, not a benchmark. Treat them as a sense of scale. ## Your setup, step by step

Everything from every round, in order:

1. Get the accounts. A free GitHub account and a Claude plan that includes Claude Code (Pro or Max).
2. Make an empty repo. Go to github.com/new, name it, check "Add a README file," and create it.
3. Describe what you want in the Claude chat. Ask Claude to interview you one question at a time. Answer in plain words.
4. Approve one repo. When Claude asks for access, approve only the repo you just made.
5. Look at what it built. Open it on your laptop. Say what feels off in one sentence. Repeat until it's right.
6. Turn on Pages. Settings, Pages, deploy from the main branch, Save. Wait about a minute.
7. Open your link and check it on the real device. Not just the preview.
8. If a deploy breaks, say so. Tell Claude what you see. Mine was fixed in 44 seconds.
9. Keep Diagnostics handy. On a Chromebook it's in the launcher. Side by side with your page, it shows what your laptop is really doing.

10. Write down what goes wrong when it happens. I didn't, and my Wi-Fi drop became a story I can't fully tell.

Thanks to Alex Shev for the idea for this post, and for helping me see that what I built on vacation could be useful to someone else. If you build with AI coding agents, his Terminal Skills is worth a look.

Quick context if you are new here. I work in the California courts, running court operations for the county. I started building with AI in July 2025 and I have been learning in public ever since. I do not write the code. I direct, the agents generate, I validate and decide. I build the Clew Suite, a set of civic tech tools for making complex systems easier to inspect. That is the lens I am writing from.

Built and written with AI assistance in November 2026, on a Chromebook. Claude (Opus 5.5) wrote the code and drafted this post from our build sessions. I directed, decided, and edited. Check the source before you quote me.

AI Assisted. Human Approved. Powered by NLP.