The app works on your machine. This step makes it work for someone who is not you, on a device you have never touched. The way you do it is the same as for any small project, covered in publishing your project: two gates, then the push, then a short list of obligations.
Step 7: ready it for strangers
Update the README for publishing: what the app does, the live link (https://YOUR-USERNAME.github.io/habit-tracker/), how to run it locally, a status line saying this is a finished learning project, and add an MIT LICENSE file.
The address of a GitHub Pages site is predictable before it exists, so the link can go in now. Put your own username and repository name in it.
The README is the page a stranger lands on. It has to answer three questions without anyone asking you: what is this, how do I start it, and is anyone still looking after it. The licence answers a fourth, whether they are allowed to copy it. Without one, the default is that they are not.
Checkpoint: step 7 in the reference repository. It also says plainly where the data lives and what that means: it never leaves your device, and clearing your browser data deletes it.
Two gates before the push
No secrets. This project has no keys and no server, so there should be nothing to find. Check anyway, because the habit of checking is the point: look through every file, and through the history, for anything you would not want on a public page. A secret committed and deleted later is still in the history.
It runs from a clean clone. Copy the repository into a new folder, or clone it, and open index.html from there. This is where you find the file that only exists on your machine.
The path that only works on your machine
There is one more check specific to this kind of hosting. A GitHub Pages project site is served from an address like https://<owner>.github.io/<repository>/. The repository’s name is a folder in the address.
So a page that loads its script as /app.js, with a leading slash, asks for the file at the root of <owner>.github.io instead of inside the repository’s folder. The page loads, the script does not, and the app does nothing.
Your turn. The project in the terminal below is about to be pushed. Search index.html for the files it loads and find the one that will break once it is published. On your own machine, the fix is one turn: ask the agent to make every path in index.html relative, then run it again.
Quick check
Which of these keeps working after the page is published as a project site?
Getting it online
You need a free GitHub account and a public repository: on GitHub Free, a repository has to be public to be published with Pages. The site itself is public either way.
- Create an empty repository on GitHub and push your project to it. GitHub shows the commands for pushing an existing folder on the empty repository’s page. If any of them are new to you, ask your agent to explain each one before you run it.
- In the repository, open Settings, then Pages in the sidebar.
- Under Build and deployment, set Source to Deploy from a branch.
- Choose the main branch and the / (root) folder, then click Save.
Wait a few minutes. GitHub says it can take up to ten for changes to publish. Then open https://<owner>.github.io/<repository>/, with your username and repository name in it.
The reference project is live at funfactorydev.github.io/habit-tracker-with-an-ai-agent, published exactly this way.
Check it like a stranger
Open the link on your phone, not just on the computer you built it on. Add a habit, tick a day, close the browser, open it again. Then send the link to one person and ask them to try it without any explanation from you. Whatever they get stuck on is your next turn.
Remember that the published page has its own storage. The habits you added while building, from the file on your computer, are not there. That is not a bug: each site gets its own localStorage, and every project site of one GitHub account shares the same <owner>.github.io address, which is a good reason for an app to save under a key with its own name. The reference app saves under habits-v1. That is fine while it is the only tracker on the account; publish a second one from the same account and it needs a key of its own, or the two will read and overwrite each other’s habits.
Every push is a publish
From now on, pushing to main updates the live page within minutes. Keep the habit from the build: run it, read the diff, commit, and only then push. A broken commit on main is a broken page for everyone who has the link.
What you now owe it
The list is short, and it is the same for every project you publish:
- Keep the link working, or say clearly that you have stopped.
- Keep the status honest. The reference README says it is a finished learning project that is kept working but not growing. That one line saves a stranger from opening an issue nobody will read.
- Own it. You scoped it, you checked every turn, you decided when it was done. The agent typed most of it. Both are true, and saying both is how you describe it in a portfolio.
What is next
Build the second one. Pick something just as small, write the one sentence and the not-doing list, and go through the same seven steps without a reference to compare against. It will take less time than this one, because the loop is now yours: scope small, one turn at a time, run it, read the diff, commit, ship.
Does GitHub Pages cost anything?
Not for this. Publishing from a public repository works on a free GitHub account. Check GitHub's own documentation for the current limits if your project grows beyond a small static page.
Can I use my own domain?
Yes, GitHub Pages supports custom domains. It is a separate setup in the same Pages settings, and not needed to share a first project.
Why not a hosting service with a server?
Because this app does not need one. A static host serves files and nothing else, which means nothing to configure, patch or pay for. Reach for a server when the app needs one, for example to sync between devices.