Keeping Track of What You Built
A project you can finish is also a project you can understand three days from now. As your project grows, the decisions pile up: why did you choose that layout? what prompt added the delete button? which version broke the score counter and which one fixed it? Without a record, you will spend real time reconstructing what you already knew. A build log costs five minutes per session and saves hours.
What a Build Log Is
A build log is a running written record of what you changed, why you changed it, and what prompt or action you used. It does not need to be formal. It does not need software. A text file, a notebook page, or a notes app entry works perfectly. Each entry in a build log captures four things: 1. Date and session number. 2. What you added or changed. 3. The prompt or approach you used. 4. Whether it worked, and if not, what you did next. That is it. Four lines per session keeps you oriented no matter how much time passes between sessions.
A build log is a chronological record of changes made to a project — what changed, why, and how. It is the difference between a project you own completely and one that becomes mysterious to you as it grows. Professional developers call this version history; your build log is its low-tech equivalent.
Here is three sessions from Marcus's actual build log for his reading tracker. Session 1, May 10: Added: MVP — input box and log button, saves entries to a list. Prompt: [full first prompt from Lesson 2]. Result: Worked. Core function confirmed. Session 2, May 11: Added: Delete button for each entry. Prompt: 'Add a delete button next to each entry. Clicking it removes that entry from the list.' Result: Worked first try. Test checklist: all pass. Session 3, May 12: Added: Weekly total display. Prompt: 'Below the entry list, calculate and display the sum of all page counts as Total this week: [number].' Result: Total showed correctly for adding. Broke on delete — total did not update when entry deleted. Fixed with: 'The weekly total does not recalculate when I delete an entry. It should. Fix that.' Result after fix: All pass. This log takes Marcus two minutes per session. When he returns after a week away, he reads three entries and is fully caught up.
Tracking Your Prompts
Your prompts are valuable artifacts. The exact wording that got a feature working is worth keeping because you might need a variation of it later, and because reviewing your prompts over time is one of the best ways to learn what makes a prompt effective. In your build log, paste the exact prompt you used for each feature. Not a summary — the actual text. When a prompt did not work well, note what you changed to make it work. Over ten sessions you will notice patterns: certain structures and certain levels of detail consistently produce better results than others.
It is tempting to only record successes. Log the failures too — what you tried, what went wrong, and what fixed it. The failures teach you more than the successes, and a future version of you will be very grateful to find the solution to a problem already documented in your own words.
Match each build log element to what it captures.
Terms
Definitions
Drag terms onto their definitions, or click a term then click a definition to match.
Organizing Your Files
As your project grows, you may accumulate multiple versions of your code, notes, screenshots, and exported files. Without organization, these become a pile you hesitate to dig through. A simple folder structure keeps everything findable: - One main project folder with your project name. - Inside it: a code subfolder, a notes subfolder, and an archive subfolder. - Save each major working version with a date in the filename: tracker-may10.html, tracker-may12.html. - When something breaks, you can always return to the last known-working file. This is an informal version of what professionals call version control. It is less powerful than git — the tool professional developers use — but it is completely sufficient for a first project and it costs nothing.
Before making a significant change, save a copy of the current working file with a date in the name. If the change breaks everything, you can return to the dated copy. Overwriting the only copy of working code and then breaking it is one of the most painful experiences in building — and entirely preventable.
Why should you paste the exact prompt text into your build log rather than just describing it?
Marcus's project broke during session 4. He saved dated copies after sessions 2 and 3. What is his best immediate option?
Start or Catch Up Your Build Log
- Step 1: Create a text file or notebook page titled '[Your Project Name] Build Log.'
- Step 2: Write an entry for every session you have worked so far — date, what you added, the prompt you used, and the result. Reconstruct from memory as best you can.
- Step 3: Create a dated copy of your current working project file.
- Step 4: Set up a simple folder structure: project folder, code subfolder, notes subfolder, archive subfolder.
- Step 5: Move your dated copies into the archive subfolder.
- Step 6: Write the entry for today's session — which is this log-setup work itself.
- From now on, open your build log at the start of every session and close it only after writing the day's entry.