What, and For Whom

How this course is different. The nine courses before this taught you tools. This one is about judgment, and judgment cannot be graded by running code.

Whether your schema is well designed, whether a stranger can use your interface, whether your architecture survives its second feature: none of that is checkable by a test. So this course grades the few things that genuinely are, and reviews everything else against criteria stated in advance. That is also how the work is judged at a job.

Start with a person and a problem, not a stack. 'A React and Django app with Postgres' is not a product idea. It is a list of things you already know how to use.

Write one sentence: someone has this problem, and my application helps by doing this. If you cannot fill in all three blanks, you are not ready to design anything, and no amount of architecture will rescue it.

✦ Build for a person you can actually ask

Yourself, a friend, a family member, a group you belong to. The single strongest predictor of a finished project is being able to show it to somebody who wanted it and watch them use it. Building for an imagined generic user means every decision is a guess with nothing to check it against.

Then cut it. Write everything the application could do. Then mark the smallest set that still solves the problem for one person, once. That set is version one, and everything else is a list you keep for later.

The most common reason a portfolio project is unfinished is not difficulty. It is scope decided by enthusiasm rather than by the problem.