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
| Part | What I used | Cost |
|---|---|---|
| Laptop | HP Chromebook 11a: MediaTek Kompanio 500 processor, 4 GB of memory | Already owned |
| Browser | Chrome, which comes with ChromeOS | Free |
| Code host and website | GitHub and GitHub Pages | Free |
| AI that builds | Claude, working in a cloud workspace from the chat | Paid plan. More in "What it costs." |
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:
| Reading | Number |
|---|---|
| CPU in use | 5% |
| Memory free | 1.44 GB of 4 GB |
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
- Create a free GitHub account.
- Make an empty repository at github.com/new. Check "Add a README file."
- In a Claude chat, describe the small thing you want to build. Ask Claude to interview you one question at a time.
- When Claude asks for access to your repository, approve that one repository.
- When the files are pushed, turn on Pages: Settings, Pages, main branch, Save.
- 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:
| Change | Why |
|---|---|
| A live frame-rate meter in the corner | It shows, in real time, how smoothly this laptop is drawing the scene. The page becomes its own evidence. |
| Keyboard controls: arrow keys spin, + and − zoom | The first version only worked with a mouse or a finger |
| Warm string lights and a few stars | The flags looked flat. Small glowing bulbs added depth and that plaza-at-night feeling. |
| Pause when the tab is hidden, and cap sharpness on high-res screens | Keeps it light on a 4 GB machine |
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.
| Reading | Round 1 (after the build) | Round 2 (flags moving) |
|---|---|---|
| Frame rate | not measured | 60 frames per second |
| CPU in use | 5% | 15% |
| Memory free | 1.44 GB of 4 GB | 1.68 GB of 4 GB |
| Temperature | 37°C | 41°C |
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.
| Step | Where it runs | Who does it |
|---|---|---|
| Describe it | On the laptop | Me |
| Decide it | In the cloud | Claude asks, I pick |
| Build it | In the cloud | Claude |
| Push it | On GitHub | Claude, after I approve one repo |
| Ship it | On GitHub | Me, three clicks |
| See it | On the laptop | Me |
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:
| Version | What I noticed on the Chromebook | What changed |
|---|---|---|
| 1 | It animated, but nothing showed the path or which step came next. | A glowing thread now unspools to the current step, with a spark at its tip. Steps behind it fill in, and steps ahead stay dim. |
| 1 | It used the same papel picado colors as Necesito. | It switched to my Clew Labs colors. The thread fits the brand: a clew is the ball of thread Ariadne used to find her way out of the labyrinth. |
| 2 | On the small screen, the current step fell below the fold. | The page now scrolls to each step, and the buttons and caption stay pinned at the top. |
| 3 | Autoplay kept going while I was trying to read. | Any click, tap, or scroll stops it. Replay starts the walkthrough over when you're ready. |
| 3 | A button called "Drop the Wi-Fi" didn't explain itself. | It's now a question: What if the Wi-Fi drops? |
| 5 | It scrolled to the next step before I finished reading. | Each step now holds for 6 seconds, and the scroll glides instead of jumping. |
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.
| Reading | Baseline (4 tabs, nothing animating) | Round 2 (3D) | Round 3 (diagram playing) |
|---|---|---|---|
| CPU in use | 5% | 15% | 6% |
| Memory free | 1.64 GB of 4 GB | 1.68 GB of 4 GB | 1.68 GB of 4 GB |
| Temperature | 37°C | 41°C | 38°C |
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:
| Choice | Why |
|---|---|
| Recorded from the repo files | Claude's workspace can't reach github.io. They're the same files GitHub Pages serves. |
| Necesito uses a demo number | My real number doesn't go in a video. |
| The tap stops at the button | A browser can't film Messages opening on an iPhone. |
| The 3D frame-rate meter is hidden | It would show the recording machine's speed, not the Chromebook's. |
What the Chromebook showed
Same method: the video playing on the right, Diagnostics on the left.
| Reading | Baseline | Round 2 (3D) | Round 3 (diagram) | Round 4 (video playing) |
|---|---|---|---|---|
| CPU in use | 5% | 15% | 6% | 7% |
| Memory free | 1.64 GB of 4 GB | 1.68 GB of 4 GB | 1.68 GB of 4 GB | 1.40 GB of 4 GB |
| Temperature | 37°C | 41°C | 38°C | 35°C |
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.
| Capability | What I did | Result |
|---|---|---|
| Baseline browser tabs | Memory free with 4 tabs open (a Claude chat, the project page, Gmail, and my dev.to dashboard) plus Diagnostics, nothing animating | 1.64 GB of 4 GB free, CPU at 5% |
| Memory during a build | Diagnostics while Claude pushed the fix and GitHub rebuilt the site | 1.51 GB of 4 GB free, CPU at 6% |
| Where it starts to slow | Worked a normal afternoon on this post, then checked Chrome's Task Manager | I didn't hit it. 4 tabs plus extensions, and nothing felt slow. |
| Recovery after a failed deploy | Claude pushed a file that breaks GitHub's site build on purpose. When I said "fix it," we timed until the deploy turned green. | 44 seconds. The live site never went down. |
Here's what each tab was using, from Chrome's Task Manager (Search + Esc on a Chromebook):
| Tab | Memory |
|---|---|
| The Claude chat where I'm building all of this | about 283 MB |
| Gmail | about 185 MB |
| The GitHub repo | about 98 MB |
| The Round 3 diagram | about 32 MB |
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
| Part | Cost |
|---|---|
| The Chromebook | Already owned |
| GitHub and GitHub Pages | Free |
| Claude Pro, the cheapest plan with Claude Code | $20 a month, or $17 a month billed yearly |
| Claude Max, what I use | $100 a month |
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:
| Can't do (or didn't try) | Why |
|---|---|
| Work offline | Every step runs in the cloud or on GitHub. No internet, no build. |
| Run AI models on the laptop | 4 GB of memory isn't close to enough for a local model. |
| Heavy local tools | Things like Docker, phone emulators, or big compiles want more memory than this. I didn't try them. |
| Skip the GitHub clicks | Claude couldn't turn on GitHub Pages from its side. I clicked Settings, Pages, Save myself. |
| Test on the real live site from Claude's side | Claude's workspace couldn't reach github.io, so it tested the repo files. I checked the live site on the Chromebook. |
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:
- Get the accounts. A free GitHub account and a Claude plan that includes Claude Code (Pro or Max).
- Make an empty repo. Go to github.com/new, name it, check "Add a README file," and create it.
- Describe what you want in the Claude chat. Ask Claude to interview you one question at a time. Answer in plain words.
- Approve one repo. When Claude asks for access, approve only the repo you just made.
- Look at what it built. Open it on your laptop. Say what feels off in one sentence. Repeat until it's right.
- Turn on Pages. Settings, Pages, deploy from the main branch, Save. Wait about a minute.
- Open your link and check it on the real device. Not just the preview.
- If a deploy breaks, say so. Tell Claude what you see. Mine was fixed in 44 seconds.
- 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.
Top comments (3)
The side-by-side Diagnostics readings are what make this convincing for me — 60fps at 15% CPU on a 4GB Chromebook is a real number, not a vibe. I also liked the honest limits section, especially that the failed deploy took 44 seconds to fix and the live site never went down. The "write down what goes wrong when it happens" rule is the one I'll steal; undocumented outages always turn into stories you can't verify later.
Thank you! The side-by-side came from a mistake. My first Round 2 reading caught the scene resting, because Diagnostics was covering the tab and the 3D had paused itself. Once both were on screen at the same time, I could actually show my work.
Helping people is the main reason I wrote this post, and that really made my day. Next time, a Wi-Fi-adjacent moment will be part of the story!
The side-by-side Diagnostics readings are what sold me on this — 60fps at 15% CPU on a 4 GB Chromebook makes the "full build kit" claim concrete instead of aspirational. I also liked the honesty about the limits: the 44-second failed-deploy recovery shows the safety net works, while the unrecorded Wi-Fi drop is a useful reminder that a cloud build's weakest link is the connection, not the laptop. The detail about keeping the phone number out of the repo and in the URL hash was a smart, practical touch. Did the 1.5x pixel-ratio cap noticeably change how the 3D scene looked, or was it invisible in practice?