The File You Add After the Tutorial Closes

src/app/post-tutorial-notes.md is empty.

You just wrapped a full-stack tutorial, poured a glass of water, and returned to your code editor with a faint buzzing in your brain: you followed every step, ran every command, debugged the CORS error that the instructor glossed over, and now have a working to-do app that authenticates users and stores data in a hosted database. But you know if you step away for 48 hours, you’ll forget 70% of the small, unscripted workarounds that made the project actually run, instead of only working on the instructor’s pre-configured machine. This file is where you lock that knowledge in, no fancy formatting required.

File purpose and permanent fields

This is not a generic notes file, it’s tied directly to the specific project you built in the tutorial. Unlike the tutorial’s official documentation, this file only contains information relevant to your specific implementation, your common pain points, and the gaps the tutorial left unaddressed. It lives in the root of your project repo, so it’s the first thing you see when you open the repo folder, and it’s committed to git so you can reference it even if you check out an old version of the code.

Every post-tutorial notes file has four permanent fields that you fill out immediately, no exceptions, before you make any other changes to the project or start adding custom features: the tutorial source link, total time spent completing the tutorial, number of unplanned bugs you fixed that the instructor didn’t mention, and one core concept you understood for the first time while working through the content. Illustrative example: your tutorial is the Build Next Stack full-stack React + Supabase course, so you paste the direct link to the course module, note you spent 3 hours and 47 minutes working through it, fixed 2 unplanned bugs (one CORS configuration error, one Supabase row-level security policy typo), and your core new concept is how server components eliminate the need for client-side data fetching for non-interactive page content.

You don’t add extra fluff to these fields, just the raw facts. The goal is to give yourself a 10-second context refresh when you come back to the project after time away, so you don’t have to search through your browser history or email receipts to remember where you found the tutorial, or how much work you already put in to get it to a working state. These fields also help you track your learning progress over time, so you can see how much faster you get at troubleshooting common errors and picking up new frameworks as you complete more projects.

Single edit to lock in tutorial takeaways

This is the only edit you make to the file right now, before you tweak the UI, add custom features, or push the code to a production host. It’s a numbered list of the 5 specific, actionable facts you learned that are not in the tutorial’s written notes or scripted walkthrough. These are the exact gaps that made you pause, pull up a separate search tab, and troubleshoot for 10+ minutes while you worked through the content, and they are the first things you will forget if you don’t write them down immediately:

1. Supabase row-level security policies require you to explicitly grant SELECT access to authenticated users even if you set the table to be “public” during initial creation. The instructor dragged through this step in 10 seconds and did not mention that misconfiguring this will throw a generic 403 error that does not reference RLS in the error message, so you spent 22 minutes troubleshooting a typo in the policy name.
2. Next.js App Router client components require the ‘use client’ directive at the very top of the file, even if you only import a single hook that uses client-side state. If you add the directive below import statements, the app throws a hydration error that references a React internal function instead of the misplaced directive.
3. The Vercel deployment environment variable for Supabase service role keys must be marked as “sensitive” to prevent it from being exposed to client-side code, even if you only reference it in server-side API routes. The instructor did not mention this setting, so your first test deployment failed with a permission error when you tried to delete a to-do item.
4. When you run npm run build locally to test for production errors, you need to set all required environment variables in a .env.production file, not just the .env.local file you use for development. The tutorial only referenced .env.local, so your first local build failed 3 times before you realized you were missing variables in the production env file.
5. The default Tailwind CSS prose class adds unwanted top margin to the first

   tag in any rendered markdown content, so you need to add prose-headings:mt-0 prose-p:mt-0 to the class list to remove that extra space for your to-do item descriptions.

You don’t add screenshots, long explanations, or tangential thoughts to this list. You just get the exact, actionable facts down while they are still fresh in your short-term memory. This list is not meant to teach the concept to anyone else, it’s meant to remind you of the specific mistake you made and the exact fix you found, so you don’t waste time troubleshooting the same problem again later. Once you finish writing the list, you save the file, commit it to git, and step away from your desk for the day, no extra work required.

Next time you open this file

The next time you open this file is three days from now, when you sit down to add a custom feature to the tutorial project: the ability to assign due dates to to-do items. You don’t have to rewatch the entire tutorial to remember how the data layer works, you just pull up this file first. First, you scan the permanent fields to remind yourself of the core concept you learned, so you know to build the due date display as a server component to avoid unnecessary client-side data fetching. Then you scan the list of takeaways to avoid the common mistakes you made the first time around: you double check your RLS policies when you add the due date column to the Supabase table, you add the ‘use client’ directive to the top of the date picker component before you write any other code, you mark any new environment variables as sensitive when you push the feature to Vercel, you add the required variables to .env.production before you run a local build, and you remember to adjust the Tailwind prose classes if you add any new markdown-rendered fields to the to-do items.

When you finish building the new feature, you add one more line to the takeaways list: the exact quirk you found when working with the date picker library that required you to format the date string as ISO 8601 before sending it to Supabase, because the library returns a Date object that the Supabase client does not parse automatically. You don’t add anything else, just that single line, so the file stays a concise, actionable reference instead of a bloated collection of random notes.

This file stays in the repo for the entire lifespan of the project, so every time you come back to add a new feature, fix a bug, or refactor old code, you reference it first to avoid repeating the same mistakes you made during the initial tutorial build. You also copy the structure of this file for every future tutorial project you complete, so you build a library of personalized reference docs that are tailored exactly to your learning style and common pain points, instead of relying on generic tutorial documentation that doesn’t account for the specific mistakes you tend to make. Over time, these files become far more valuable to you than any official documentation or third-party tutorial, because they are written by you, for you, and only contain the information you actually need to build and maintain your projects. (Word count: 1372)