At most one email a week. Unfollow anytime with one click.
Transcript
The full narration of this video. The current sentence is highlighted while the video plays; click any sentence to jump there.
Show transcript
Introduction
Hi, and welcome back. The Sunset Coffee mini cashier has passed testing and Dimas is using it. There's just one more stage to make this project truly complete. Today we write documentation for three readers, prepare a data-driven presentation, and check the project before sharing it as a portfolio.
Step 1: Three documents, three readers
Good documentation is written for its reader. The first document, the README, is for whoever maintains the code. That could be Raka himself six months from now, or someone else who carries the project on. The second document is a one-page user guide for Dimas: how to handle sales and make the recap. No technical terms at all. The third document is handover notes for Laras as the owner: who to contact if there's a problem, where the data backups are, and what the next plans are. A common mistake is writing one document for everyone. The result is too technical for Dimas and too shallow for whoever maintains the code. Let's peek at the handover notes for Laras. First, the help contact: Raka, via WhatsApp, during working hours. Second, where the backups are: the daily recap folder on the laptop, which is also copied to the shop's Google Drive. Third, running costs. This cashier doesn't use the internet and doesn't call the Claude API, so it costs zero rupiah; the shop laptop is enough. That's different from the bot in the previous session, which is paid per token. Fourth, a monthly review schedule: running the tests, checking the backups, and deciding which later feature to build next. These notes fit on one page, but they mean Laras doesn't depend entirely on Raka's memory. A business owner who knows how to look after a tool feels more confident using it.
Step 2: A README written by Claude Code
Raka asks Claude Code to write a README in plain, simple language: the goal, how to run it, the file structure, how to change prices, and how to run the tests. Claude Code reads CLAUDE.md, the menu file, the cashier logic, and the project settings file. It also reads the Git history: eighteen commits up to version one point zero. This history helps explain important decisions, such as why canceled transactions aren't deleted. Then it writes a README with six sections. Claude Code suggests one thing that's often skipped: follow the README from the start to make sure no step is missing. Claude Code wrote the README, but Raka still reads it all the way through. He finds one term that's too technical and asks for a short explanation to be added. Documents written by AI are still our responsibility. Raka copies the project to a new folder and follows the README from the first step, as if he were a stranger. The app opens without him asking anyone for help. He tries changing one price using the README's steps, then runs the tests. They pass. But one thing is missing: the step for installing Node.js, the program needed to run the tests, isn't written down. It's already installed on Raka's laptop, so he never noticed. Raka asks Claude Code to add it, with a note telling readers to follow Node.js's official guide. This is why we test documents. Small gaps like this only show up when someone else tries on a different laptop, and usually at the worst possible moment.
Step 3: A one-page user guide
Now for Dimas's guide. Raka asks Claude to make a one-page guide in everyday language, ready to print on A4 paper. The guide appears in the Artifact panel: five main steps, from opening the cashier to the nightly recap, plus an emergency box. Notice its last sentence: don't clear the browser history, because the transaction data is stored there. Raka asks Dimas to read the guide. Dimas is confused by the term export CSV. That's understandable; it's the builder's language, not the user's. Claude replaces it with a sentence Dimas understands: tap save recap, and the file goes into the daily recap folder. The guide is printed and stuck up near the cashier laptop. A good guide gets tested too, just like the app. The way to test it is simple: ask the user to read it and mark every word that makes them hesitate. For your business, keep this guide in a Claude Project along with the project sheet. When the app is updated, you just ask Claude to update the guide to match the latest changes.
Step 4: A five-part presentation
A convincing project presentation only needs five parts. First, the problem: a thirty-minute nightly recap and miscounts when it's busy. Start with the user's pain, not the technology. Second, the solution: a mini cashier on the shop's laptop, explained in the one-sentence project formula we wrote at the start of the session. Third, a short demo: one sale from picking menu items to the change, just one minute. Fourth, results as before-and-after numbers. This is the part your audience remembers most. Fifth, the plans: the later features from the project sheet, such as delivery and ingredient stock. Practice this presentation in about five minutes, and prepare a backup demo as a recorded video in case the laptop acts up during the presentation. A live demo failing in front of an audience is a very common experience. For the results part, Raka asks Claude to make a short page with three key numbers and a chart of recap time over five nights. The result is instantly convincing. Three number cards at the top: the recap went from thirty to four minutes, zero miscounts in forty-seven sales, and fourteen tests passed. The chart below shows two nights with paper receipts, then three nights with the cashier, getting faster as Dimas got used to it. Notice the small note under the chart: the numbers were recorded by Dimas every night. Naming the source of your numbers makes a presentation honest and trustworthy. Don't round off or polish numbers to look more impressive.
Step 5: Share it safely
Raka wants to share the project on GitHub as a portfolio. Before that, he asks Claude Code to check for secrets, real transaction data, and personal info, without changing anything yet. Claude Code looks at the list of files tracked by Git, which are the files that would be uploaded. The findings matter. There's no key, but there's one file with the shop's real sales. Sunset Coffee's sales data is Laras's business secret, so it must not be published. Claude Code proposes removing that file from Git, without deleting it from the laptop, and replacing it with sample data. Raka approves. Before you show off the project, check five things. First, no keys, tokens, or real data in the repository. Second, ask the business owner's permission to mention the name and results. Laras is happy for Sunset Coffee to be mentioned, but she still has to be asked. Third, choose a private or public repository deliberately. A private one can still be shared with specific people. Fourth, record a two-minute demo video with sample data. Fifth, tell the story of the process: the problem, decisions, mistakes, and fixes. Recruiters and potential clients care more about how you think than about a list of features. The screens in this video are simulations, so menus on your screen may differ slightly. Your final project doesn't have to be a cashier. Whatever it is, tidy documentation and an honest story make it worth showing off, whether you're applying for a job or offering your services to other businesses.
Done!
The final project is now complete: a tested README, a one-page guide Dimas understands, a five-part presentation with honest numbers, and a portfolio without secrets or real data. In the final episode we look back on the journey through twenty sessions, talk about how to keep learning, and explore the next path after this class. See you there!
Practice exercises
Try these on your own after watching to lock in what you learned.
Ask Claude Code to write your project's README, then follow its steps yourself from the start
Make a one-page user guide with an Artifact and ask your user to read it
Build a five-part presentation with at least two result numbers
Ask the class material
Type a question or keyword; we find the part of this episode that explains it and jump the video there.
My notes
Notes are saved with the current video time and are only visible to you.
Questions & answers
Stuck on a step? Ask here; the instructor and other learners can answer.
No questions yet.
Your instructor
Cerdas Inovasi Digital Team
Software developers, BIM & 3D engineers, and AI practitioners
53 video classes1,286 episodes
We build software, BIM models, games and AI automations for clients every day, and turn that hands-on work into step-by-step classes: every step is shown on screen and comes with a PDF guide you can keep.
