Assignments

Any small working web app that you built with AI and put on the internet, plus a memo about building it. It does not have to be related to your team's venture, and it does not have to be a groundbreaking idea.

That said, this is a good moment to start thinking creatively. Look for something you have not already seen a hundred times, or a familiar tool built for a customer who is currently being ignored. Whatever you land on, the memo has to make the case for it: who it is for, why the problem is worth solving, and what would make someone choose your version over what they use today.

So that you, personally, know you can do this before your team forms.

Most teams have one person who is more comfortable with technology, and on many teams that person quietly ends up doing all the building. This assignment exists so that does not happen to you. By week four you will have shipped something with your own hands, and you will spend the rest of the semester knowing you can.

It is also graded generously on purpose. This is an on-ramp rather than a filter.

Graduate. Due 9/16, before Session 4.

Undergraduate. Due 9/15, before Session 4.

Submit three things:

1. A live web address where your app can be opened
2. A link to your GitHub repository
3. A memo explaining what you built and why: what market problem it solves, and how customers would use it

Graduate. Your memo is two pages single-spaced, and must also cover the challenges you faced along the way. What broke, how you recovered, and which AI-prompting techniques worked well for you.

Undergraduate. Your memo is one page single-spaced.

• The app does one thing and that one thing works when I click it
• The memo makes a real case for the app: a customer you can name, a problem you can point to, and a reason someone would use your version
• The memo names specific failures. "I got an error saying the module was not found, and the fix was X"
• The memo shows you understood what you were doing, rather than that you got lucky
• Weak version: "I built a website. It was hard at first but then it worked." That tells me very little and scores near the bottom of the memo points.

A team-written proposal outlining your group's candidate ideas for a new product.

Graduate. Three pages single-spaced, covering three ideas.

Undergraduate. Two pages single-spaced, covering two ideas.

It forces the conversation your team would otherwise put off. Committing an idea to paper, with a reason attached, makes it much easier to tell a real opportunity from one that only sounded good out loud.

It also gives me a chance to push back before you spend six weeks building the wrong thing.

Graduate. Due 9/30, before the Determining Pricing and Business Model session.

Undergraduate. Due 9/29, before the Pricing and Business Models session.

One document per team, briefly covering, for each idea:

1. Why your group is interested in it
2. What problem it solves, and for whom
3. The novelty, value, and uniqueness of the proposed solution
4. Why AI can help you build it

More details will be available on Canvas.

• The problem is described from the customer's side, not from the solution's side
• The ideas are genuinely different from each other rather than variations on one idea
• You say something honest about which one you currently favor and why
• Weak version: three descriptions of software features with no named customer and no reason to think anyone wants them.

A fifteen to twenty minute meeting with me during class time in Session 7, where your team walks through where you have got to on the Discovery Report.

The Discovery Report is the largest team deliverable in the first half of the course, and the most common failure mode is a team that discovers a hole in its evidence a few days before it is due. This meeting is there to find the hole while there is still time to fix it.

Nothing is submitted through Canvas. Come to class on 10/6 with a rough plan of action for the Discovery Report: which sections you have drafted, what evidence you have collected so far, and which parts you know are still thin.

Your progress is graded as "Poor Progress," "Marginal Progress," "Good Progress," or "Excellent Progress," and each corresponds to a particular score.

• You can name specific evidence you have already gathered, including interviews you have already run
• You are candid about what is missing rather than presenting a polished front
• The whole team shows up and more than one person can speak to the work
• Weak version: a team that has divided the report into sections and not started any of them.

A team-written summary of the research your group conducted across the discovery sessions: finding market problems, understanding customers, assessing competition and moats, and working out a business model.

Graduate. Up to twelve double-spaced pages, plus figures, appendices, and references.

Undergraduate. Up to eight double-spaced pages, plus appendices and references.

Appendices do not count toward the page limit.

This is the document that stops you from building something nobody wants. It is also the thing your pitch gets checked against in December, so the evidence in it needs to be real.

Writing it forces you to notice what you do not actually know yet. Many teams discover a hole in their argument while writing this, which is exactly when you want to discover it.

Graduate. Due 10/28, with the Polishing Design and Testing session.

Undergraduate. Due 10/27, with the Polishing Design session.

One report covering:

• The market problem you are solving, defined explicitly, and why now is the right time to target it
• The size of the target market, with the assumptions behind your estimate stated
• What you learned from customer research
• An analysis of your competitors
• Your defensibility argument: what makes your product's proposed moat hold up
• A business model with planned unit economics

You will use AI throughout to conduct this research, and you must verify and validate what it gives you. AI is not permitted for the writing of the report. AI-generated interviews are not evidence and will not be counted.

• Quotes are specific and sometimes inconvenient. A report where every quote supports your idea reads as cherry-picked, because it usually is
• What your landing-page probes actually showed is reported plainly, including the ones that did not work
• The strategy visibly follows from the evidence rather than sitting next to it
• Every market number has a source you could hand to someone else
• Weak version: interviews that all say "yeah that sounds useful," no probe data, and a strategy section that could have been written before you talked to anyone.

A live demonstration of your working product, in front of the class, on the projector, followed by questions from a peer panel and me.

Graduate. Eight minutes.

Undergraduate. Six minutes.

It is the product running live. It is not a slide deck about the product.

Because a thing that works in front of an audience is the clearest proof that it works. Almost everything else can be described convincingly whether or not it is true.

The question period is the other half. It tends to reveal in about ninety seconds whether you understand what you built.

Graduate. The demo happens in class on 11/4.

Undergraduate. The demo happens in class on 11/3.

Submit through Canvas the same day:

• Your live product web address
• Your GitHub repository link
• Your team's CLAUDE.md and prd.md files, which you can upload to Canvas directly

Grading covers whether the product runs, whether and how evidence presented in the Discovery Report visibly shaped the product and its features, the quality of your testing and validation, and your responses to questions during the presentation.

Start scheduling any user testing early. Other people's calendars are usually the slow part.

• The core workflow runs start to finish without you explaining around a broken bit
• You can say "we changed X because user Y did Z"
• You are honest about limits. "Our summarizer degrades past two pages so we cap it" scores better than claiming it always works
• You narrate what the user gets, rather than what technology you used
• If the live demo breaks, switch to your backup recording and keep going. Panicking usually costs more than the break itself.
• Weak version: three half-built features shown quickly, no evidence of testing, and answers to questions that do not match what is on screen.

Your own weekly record of what you personally did on the project, kept from Session 4 onward.

In both sections, each entry should be no longer than one page.

This is yours. It is not shared with your team, and your teammates do not write it.

This course cannot really grade your code, because AI wrote most of it. What it can grade is your judgment.

There is also a blunter reason. Most assignments after week four are graded as a team. Without this, a student could contribute nothing from October onward and still do fine. This is the assignment that shows what you personally did.

Do not leave it to December. It cannot be reconstructed.

Weekly from Session 4. Keep a file called build-log.md in your project. Each entry covers what you built that week, what unique things you tried, what broke along the way, how you fixed it including dead ends, and what you learned.

Graduate. Final submission due 12/9. Combine your four most interesting weekly logs into a single document.

Undergraduate. Final submission due 12/8. Combine your four most interesting weekly logs into a single document.

Your final submission must also describe a case where AI was confidently wrong, how you caught it, and what you learned from the incident. This is not optional and it carries the most weight in the assignment.

Undergraduate. Your combined build log is graded as "Poor," "Average," "Good," or "Excellent," and each corresponds to a particular score. More details are on Canvas.

The test is whether someone reading an entry could tell that you wrote it rather than any of your teammates.

• Weak: "Worked on the signup form. Had some issues but fixed them. Learned about databases."
• Strong: "Tried to add email signup. Claude built it and said it was working. The form submitted and showed a success message but no emails arrived in Supabase. Claude insisted the code was correct. I opened the Supabase dashboard directly and the table was empty. It had created the table under a different name than the code was writing to. Lesson: a success message in the browser proves nothing about the database."

The second one takes about four minutes to write and is worth several times the first.

Two things graded together. A live pitch presentation, and a final package of documents submitted the following week. Both sections get five minutes of Q&A after the pitch.

Graduate. A ten-minute pitch, judged live by external judges.

Undergraduate. An eight-minute pitch.

The demo proved the product works. This has to prove the business works, which is a different argument requiring different evidence.

Graduate. Pitch Day is 12/2, in class. The Venture Package is due 12/9.

Undergraduate. Pitch Day is 12/1, in class. The Venture Package is due 12/8.

The Venture Package contains:

• The final pitch deck, with an appendix of supporting evidence
• A live product web address and a GitHub repository link
• A two-page double-spaced AI-usage report documenting the most impactful uses of AI over the semester, such as pivotal prompts and agent workflows
• The Discovery Report, revised and reframed as a Go-to-Market Strategy document. This is an update rather than a rewrite, so every substantive change must be visibly annotated with highlighting or a short change log, making it clear what shifted and why
• Real customer evidence, meaning documented interviews with actual people and what you learned from each

Graduate. A minimum of six real interviews.

Undergraduate. A minimum of four real interviews.

More details will be provided in class and on Canvas.

• Your market size is built bottom up: number of customers times price, with a source for the customer count. Never "one percent of a fifty billion dollar market"
• You have prepared answers to the questions investors usually ask AI startups: what is your moat when the model improves, why does the incumbent not just do this, what do inference costs do to your margins, is this a feature or a company, and what lock-in accrues over time
• Your numbers match your Discovery Report and your demo. Anything appearing for the first time in the pitch will probably be asked about
• The change log in your Go-to-Market document shows real revision rather than reformatting
• When you do not know, you say "I don't know, and here is how we would find out." That is usually a good answer. Bluffing is graded down, and experienced judges tend to notice.