A small app with a real job
Our project tracker helps one person keep a short list of tasks. You can add a task, mark it complete, filter the list, delete an item, and download your data as JSON. It is a web app that runs in a browser, not a native App Store app.
The first version deliberately uses browser storage. That keeps the project understandable and avoids a database or account setup. It also means tasks do not automatically sync to another device, and clearing browser data can remove them.
You need a desktop browser, a folder for your project, and an AI coding assistant that can produce or edit files. If you use our finished example, an AI account is optional. Do not put secrets or sensitive personal information in this learning app.
1. Decide what the first version does
Begin with a person and a problem: “I want to see the next few tasks for my project.” A calendar, team chat, and automatic reminders can wait. The narrower version is easier to check and more likely to get finished.
Help me plan a tiny project tracker for one person. It should add a task, mark it complete, filter by status, delete a task, and export the list. Data stays in this browser. No accounts, payments, AI APIs, or cloud sync in this version. Before writing code, describe the screen, data fields, limitations, and acceptance checks.
Read the assistant’s plan before it writes code. You should be able to describe the screen and the data in ordinary language: each record needs an ID, a title, and a completed state.
2. Ask for a complete first version
Create a new folder for this experiment. Ask the assistant to produce a single index.html file. Keeping this first app in one file makes the relationship between the interface, styles, and behavior easier to follow.
Build the agreed project tracker as one self-contained index.html file using HTML, CSS, and JavaScript. Use readable system fonts, a light background, and green controls. Store task records with an ID, title, and completion boolean in localStorage. Handle unavailable storage with a clear message. Render user text with textContent, not innerHTML. Use labelled form controls, real buttons, visible keyboard focus, and a responsive layout. Provide the complete file and explain how to preview it. Do not deploy yet.
Ask for a local browser preview from your assistant’s supported environment. Serving the file over a local web address is more reliable than depending on storage behavior when double-clicking a file. Keep this preview separate from your public site until the behavior is checked.
3. Try the working example
The example below is the same app provided in the download. Add a task, mark it done, switch filters, and download a backup. The embedded example saves to this browser; it does not create a shared account.
Unzip the starter into its own folder. It contains index.html and a short README. You can use it as your first version or compare its behavior with the app your assistant generated. It is a learning example, not a promise that every generated version will behave identically.
4. Check the behavior before adding more
A good-looking screen is only part of a working app. Test the main journey and the awkward cases. Use the checklist below as acceptance criteria, not as a claim that your own generated app has passed.
| Try this | Expected result |
|---|---|
| Add “Write the homepage” | One new task appears. |
| Submit spaces only | No blank task is created. |
| Add a long title | Text wraps without breaking the layout. |
| Mark a task complete | Its appearance and completed count update. |
| Choose To do or Done | Only the matching tasks appear. |
| Refresh the page | Saved tasks return when browser storage is available. |
| Download my tasks | The JSON file contains the current task records. |
| Use Tab and the keyboard | You can reach and operate every control. |
| Try a phone-sized viewport | The input, list, and actions remain usable. |
Review this project tracker against the agreed requirements. Check blank task input, long titles, marking complete, each filter, deletion, refresh persistence, JSON export, keyboard navigation, and a narrow viewport. Treat task text as untrusted text. Check how storage failures are reported. Run checks you can actually execute, and state which browser or device checks remain unverified. Fix concrete failures without adding new features.
Ask the assistant to distinguish executed checks from suggestions. If it cannot open a browser, it should say so. Test the page yourself on the devices that matter before sharing it widely.
5. Make one change you can see
Start with a color or headline. Give a clear target and explain what should stay the same. After the edit, repeat a task-creation check so a visual improvement does not conceal a functional regression.
Change the project tracker background to #F5F2EB. Keep the cards white, the green primary button, and all task behavior unchanged. Check readability and the mobile layout. Explain which style changed and how to undo it.
For a more guided edit, open Change the background color or Rewrite the hero headline. Our direct CSS tool needs a separate stylesheet; this single-file example is best changed in AI mode unless you first extract its styles.
6. Publish the finished app
Use a host that supports static websites. This project does not need a database, a server-side language, or a build command. The folder you publish must have index.html at its root.
Review the finished static project tracker for publication. Confirm the entry file is index.html, required assets are included, paths work at the site root, and there are no secrets or unfinished placeholder actions. Keep task data local to each browser. Remove any preview-only noindex restriction only if I intend the published app to appear in search. Explain how to deploy the folder to my chosen static host and what I should verify after publishing. Do not publish or change DNS until I request it.
- Keep a copy of the working folder before publishing.
- Create a static-site project with your chosen host, then upload the folder or connect its repository.
- Open the real HTTPS address returned by the host. Do not assume a successful upload means every feature works.
- Add a task, refresh, use a filter, and export the data on the deployed address.
- Check the deployed page on a phone. Connect a custom domain only after the app works at its initial address.
Storage belongs to an origin. Tasks saved in a local preview will not automatically appear on a newly published domain. Download any data you need to retain before moving between environments. The included example has a noindex tag to keep demo copies out of search; remove it in your own published app only if you want that app indexed.
What comes next?
Now choose one improvement that addresses a real need: editing a task title, a due date, or an accessible empty state. Cloud sync and team sharing are bigger changes because they introduce identity, authorization, and durable storage. Treat them as a new phase with their own plan and tests.
The useful habit is the same each time: scope one change, inspect the implementation, test the result, and keep a recoverable checkpoint.