DEMO DAY · Final project voting · Course wrap-up (last class)

All 14 final projects were deployed, demoed live, and put to a vote that we revealed on the spot, then the wrap-up. Just 10 weeks ago, most of you had never written real code, never used GitHub, and never deployed anything. Today every one of you walked the class through a live URL you built and explained how it works. The habit to keep: keep a running list of ideas and pick one up whenever you have free time. That is the whole method now. Final submission is due Friday, 7/24, so you still have two days.

• 14 final project demos, three minutes each, with questions after every one.
• The awards vote, three categories, revealed live at the end.
• The wrap-up: what the semester actually taught, how your role kept changing, and where to go from here.

This is the part worth reading even though you were in the room, because the pattern is hard to see when you are waiting for your own turn.

Most projects were aimed at somebody in particular. A few had an actual client: a brother running a manufacturing company, a high school tennis coach trying to grow his business, a friend group that plays the same game every week. More were built for the person who built them, which turns out to work just as well: your own portfolio, your own movie habit, your own health data, your own travel history. The handful aimed at a wider audience, like adopting a pet or planning a trip, still started from something the builder had actually done. Knowing who the user is shows up in the finished thing.

The hard part was almost never the code. When I asked what was hardest, the answers were: getting a real client to sign off on how it looked, understanding why deployment broke, figuring out which API actually had the data. The code came out of the agent. Everything around the code was yours.

Pivots were common and they worked out. At least two of you abandoned the product in your original proposal because the data you needed did not exist in any public API, and rebuilt around a problem you actually had. That is a real product decision, and it produced better projects than grinding on the original idea would have.

Several of you used three or four APIs in one page. A year ago that was a backend engineer's job. The interesting part is not that it is possible now. It is that stitching several sources into one coherent view is where the value showed up.

1. API keys on a static site, properly explained

This came up during a demo and it deserves the full answer, because half of you will hit it.

The situation: a static GitHub Pages site could not reach its API. The key was in .gitignore, which is the correct habit we learned for a server-side app. The site could not read it, so nothing loaded. The fix was to commit the key.

That fix is right, and here is the part that has to travel with it. A key committed to a public repo is a public key. Anyone can read it. There is no backend on a static site, so there is no place to hide anything. The reason it is acceptable in that case is that the key was read-only, rate-limited, and cannot spend money.

So the rule is about which key, rather than where you put it:

• Safe to ship in a static site: read-only keys for public data, ideally restricted to your domain, with a rate limit. Weather, movies, maps, pet listings, public sports data.
• Never ship in a static site: anything that can spend money or write data. OpenAI, Anthropic, Gemini, Stripe, anything with your billing attached. If your project calls one of those, the call has to go through a small server function, which is exactly what the Vercel setup does.

Check the provider's docs for the phrase "client-side" or "publishable". If the docs say a key is safe to expose in a browser, it is. If they do not say it, assume it is not.

2. When the answer is a number, check the math by hand

One project computes whether a hotel built at a specific map location will make money: total investment, payback period, revenue per available room, break-even occupancy, a 15-year figure. It looks great and the reasoning is readable.

The note I gave applies to anything with a calculation in it. Check the formulas by hand, on at least one case where you know the answer. An agent will produce a plausible financial model very quickly, and plausible is a long way from correct. If the number is what people come to your site for, then a wrong number is a broken site no matter how good it looks. Pick two or three inputs, work the math out yourself, and compare.

3. Do not let the same model be the writer and the judge

One project analyzes a reference video, then writes a script, then reviews the script. If the same model does all three steps, the review is worth very little, because it is grading its own homework.

I do the same thing in a project of mine that ranks university AI programs. I never let one model make the judgment. I run two or three, have them vote, and look at the cases where they disagree. Those disagreements are the interesting part.

The cheap version for your projects: when you ask an agent to check its own work, open a second tool and paste the output in cold, with no context about who wrote it. You will be surprised how often the second opinion catches something.

4. Put the human at the last step, on purpose

One project sends order updates to clients over WhatsApp. It could have sent them automatically. It does not. It opens WhatsApp with the message already filled in, and a person presses send.

That was a deliberate choice and the reasoning was good: a wrong message to a client is expensive, and the last check costs two seconds. When you are wiring an agent into something that touches other people, decide where the human step goes before you build it, rather than removing it later after something embarrassing goes out.

5. Ask what leaves your app

Several projects hold something a user would want to take elsewhere: an itinerary, a movie log, a set of travel stats, a portfolio. If the only way out is a screenshot, the data is trapped in one browser on one device.

An export is usually an afternoon of work. A copy-to-clipboard button, a downloadable file, a shareable link. It is the difference between a thing you use once and a thing you keep using.

Worth keeping as a list, because these are all free or have a usable free tier:

• TMDB for movies, worldwide, including non-Hollywood catalogs
• Open-Meteo for weather. No key required at all
• Unsplash for photography by keyword
• RescueGroups for adoptable pets and shelters
• NHTSA vPIC for decoding a vehicle VIN, and fueleconomy.gov for mileage and running costs
• Finnhub for live stock prices
• The Odds API for betting lines. ESPN also has public endpoints for team data and injury reports, but they are undocumented, so expect them to change without warning
• Plaid for linking bank, credit card and brokerage accounts
• Oura for sleep and heart rate, if you wear the ring
• Google Maps Platform and other mapping APIs, which also return points of interest and photos
• youtube-transcript-api for pulling a video transcript

Most of this is on today's slides, so I will not rewrite it here. Two things that are worth having in text:

You do not have to learn everything at once. Learn the amount that gets you to the next thing you want to build. If you want your sites to look better, go deeper on design. If you want data and logic behind them, basic Python and SQL at roughly the level we did HTML, CSS and JavaScript is already enough to build an API and a database, which makes you full stack. Depth arrives when a project needs it.

Keep a list. Write down every idea, including the ones that sound silly. When you have a free evening, pick one and see how far you get. You do not need another course for this. That is the whole method now.

Final submission is Friday, 7/24. Everything below is due then.

1. Resubmit your deployed project URL on Canvas, even if you already submitted it. I want the final version to be the one I grade.
2. Write a real README in your final project repo. Someone who has never seen your project should be able to read it and understand what it is, what it does, and how to use it. This one matters more than usual, because I am reading the code this time, and the README is how I know what I am looking at.
3. Write logs/wk10.md. This is your final reflection for the semester, so make it a real one: what you built, what you would do differently, what you want to build next.
4. Finish learning-journey.html in your oim3690 repo, then add Week 10 into the page so the last week is in there.
5. Checkpoint 5 is due Friday too. It checks all 10 weekly logs, your learning-journey.html, and that your oim3690 repo is clean.
6. Complete the course evaluation (SEQ). It takes a few minutes. It genuinely shapes what the next group of students gets, and writing it is a decent way to close out your own semester.
7. Office hours stay open through Friday. If we have not met one on one yet, book a slot.

• Today's session slides, including the workflow diagram and the roles ladder.
• Cloudflare Registrar if a project is worth a domain. It sells at cost, roughly $10 a year for a .com, and it is a better deal than the registrars that advertise at you. While you are there, email routing gives you an address at your own domain for free, and R2 gives you 10 GB of storage for free, which is enough for a lot of images.
• gpt-image-2 made the workflow diagram in today's deck. I described my actual daily process in plain text and asked for a diagram.

The course website stays up for about another month before it is rebuilt for the next semester. Save anything you want to keep.

Congratulations to everyone graduating this summer, and to everyone else, I will see you on campus.