What did I think PostAP was at the beginning? Having seen my older brother Alex go through it two years ahead of me, I already had an idea for it. That era of PostAP I saw through Alex: glimpses of Barrow, Miles, Grant, Ben, Ava, Patrick, Jack. I saw the possibilities of coding projects: mean variance optimization, Burger King burger Call of Duty arbitrage, generative Pokemon gameplay. I saw the tutoring of Principles and CSA that Ben would do. I saw the fun of completing Turing Complete and understanding logic gates at a fundamental level.

I saw PostAP as a place to apply my prior curiosity — 3D modeling, instantNGP, website creation — toward building things for my life and the people around me.

What did it actually become? I saw three main routes. I could code software, apps, or websites. I could learn to get better at guiding others through tutoring and teaching. Or I could tutor and teach what I had learned from CSA while also teaching concepts I found interesting to my PostAP peers. In the end I feel like I touched all three, while still keeping my personal interest as route one: building.

After a successful CSA exam, Dr. Lena presented me the opportunity to work with Ms. Newsom and the Independent Schools Admissions Association of Dallas over the summer on translating their old WordPress site to a responsive React app. This was my first intro to PostAP. The opportunity presented itself and all I had to do was say yes.

I learned the process of iteration there: seeing the final goal but only needing to take the next step. Over weeks, improving the website step by step, eventually I could deliver the final product.

At the same time I started Turing Complete and found genuine enjoyment in the game-ification of building my own computer, maybe more of a calculator/basic logic machine, from simple logic gates. Over time I learned to love building. Looking at a friction point in my life, something that would be cool to have, or even just cool to show off, and then just building it.

As the year passed I had only tutored once or twice. It was never my strong suit. As senior year came, I came up with more projects, more opportunities presented themselves, and this year I learned to improve at tutoring. By the end I had grown in all three paths.

The project that best represents my PostAP experience is Palo. Palo AI began from friction in AP US History. Not so that I could use it for the class exactly, but APUSH was the spark of the idea for all applications. Having to go find a transcript, paste it into AI, ask questions about a specific video. Also a lot of the time having only one specific part of the video I immediately wanted to get to.

Starting with a pain point, then imagining the solution, that is the whole project. I built ClipChat, improved it and turned it into a real project, and submitted Palo AI to the Chrome Web Store. Seeing the daily impressions, user signups, and weekly users was the most motivating and rewarding part of it all.

Seeing a result come from the project and continuing to use it was the value. Palo was the personal project that stuck the most. For over a year I used it every day as I used YouTube. It changed the way I used YouTube, and that is the point of an extension. The user count growing reflected that too.

The other projects that ended up being worth doing were the projects that generated returns. The summer job rebuilding the ISAAD website, the coding I did for the school, getting paid. Those were the projects where I was motivated to learn the most.

If you have no idea what to build, start with a problem. Not a problem invented to fit the solution you have in mind. It has to be a real problem. Not a big problem, but it has to actually exist.

For a first project, look at a problem in your life: a website that is slow, a repeatable workflow you can automate, something magical that just sounds cool. An idea can be far out there. You do not have to worry about implementation or planning or code stack when thinking. All you need to do first is define your final goal as clearly as possible.

Only once you know where you are headed can you easily plan out the steps and substeps to get there.

Make the first version an MVP. That does not mean it cannot have substance. It has to be notable, have scale, do something. But it does not have to be beautiful, perfectly clean, or work perfectly every single time.

Your project does not have to be perfect to present, or even to publish to the store. Your project has to be usable as a minimal viable product. Once you have that, instead of having to find all bugs and fix them yourself, you get feedback for free.

As you work down one path, it is never linear. You try things. You get errors. Sooo many errors and roadblocks along the way. But that is how you know it is working. Even once you get past one error only to find the next, that is a win. You are one step closer to the clean run.

I heavily leveraged AI. When I was younger I would get other people's GitHub projects running just to see what cool thing someone built. Following those READMEs, hitting bugs, learning to use a terminal. Now with AI it has felt like I could present the idea, and it could write the README and codebase for me.

AI has been instrumental in making my projects, yet I instruct it. I know what it is doing. I know what technologies I am using and how to use them. You have to learn and continue to code, but if AI is helping you as you learn and you are taking things with you, that is not terrible either.

For documentation, not every action taken. Enough screenshots to make a presentation. Enough notes to pick back up if you left it for a little while. Enough knowledge to actually have learned something and make it worthwhile.

When a project stalls, attempt to solve it. Or just pick up a new one. What matters most is enjoying the building. Projects are going to stall; you do not want to give up after the first error. There will be errors.

Do not give up immediately. If there really is an unpassable error, try building something new, try starting anew, or build the same project but with a different process.

How do you know when to abandon, archive, or ship something? When you have completed something, done enough, and there is a more interesting project you want to do. Ship, iterate, improve, archive, build something else, come back, archive. If you run out of project ideas, you can always go back and build a better version.

Use class time for talking through ideas, presenting, working on your project, getting help, seeing what other people are building, and sometimes just enjoying that PostAP is not a normal class.

What makes PostAP different from a normal class is the freedom. In another class, you usually wait for the next test or assignment for the opportunity to move your grade up. In PostAP, you can come up with the next idea, make it yourself, and turn it in for points.

Because I had the preview through my brother, I never really misunderstood that part of the class. From the start I had an idea about the points system, the point sinks, the thresholds, and the 'assignments.' I already knew how different from my other classes PostAP could be.

The freedom is useful, but it can also be overwhelming. If you already have a project, the freedom is the best part. If you have no idea what to build, the freedom is the hard part. That is why I think the most important advice is still just to start with a real problem.

I think the program rewards effort, curiosity, shipping, reflection, and technical skill, but the thing underneath all of those is initiative. You have to make the next move. The class gives you room, but it does not always give you the next step.

The program also rewards building things that actually matter to you. Palo mattered because I used it. ISAAD mattered because someone needed it. The school coding mattered because other people relied on it. Those projects pushed me more because there was some result outside of just finishing an assignment.

What the program does not make obvious enough is how important it is to keep track of the trail. Documentation does not have to be every tiny thing you did. But you need screenshots, notes, demos, and enough context that the work does not disappear after the code is done.

By the end, I think my projects said that I like noticing friction and trying to remove it. YouTube transcripts, school websites, school systems, apps, extensions, little tools, personal workflows. Some projects shipped. Some stalled. Some were archived. But the pattern was pretty similar: find something annoying, useful, or cool, and build toward it.

If I could make PostAP better for the next group, I would make more past projects visible. Not just the polished final versions, but the starts, the half-working versions, the weird ideas, and the parts where people got stuck. Seeing the first version of a project makes starting your own feel less impossible.

Why was documenting the projects as important as building them? Because the project is not only the final product. It is also the decisions, errors, screenshots, restarts, and context that got it there. Without that, you might have built something, but it is harder to explain what you learned or let someone else continue from it.

That is why my Leave a Legacy artifact is the whole website. The project pages show what I built. This page is the advice and brain knowledge that came from building them.