Projects to build

Ten student projects, each one taken from its table design to a working app. They are ordered: the first teaches the conventions the rest assume, and each adds one thing the last did not have.

These are not screenshots of something that once worked. Every command was run from an empty app, on both stacks, in the order it appears — and three bugs in Flare were found and fixed in the writing of the first two pages. Where something does not work, the page says so instead of showing a command that fails.

The pages

Lost and found portalStart here. Photos, two relations to one table, and a field that only exists when a claim is rejected.

Library management systemThe many-to-many, the title-versus-copy split, and money stored so it cannot drift.

Campus marketplaceA table that points at itself, several photos per listing, ratings, and a moderation queue.

Student complaint systemAnonymity that actually removes the name, an append-only audit trail, and SLA routing.

Event ticketingWhy an order is not a ticket, money, and a unique code you can scan exactly once.

Student fees and paymentsMoney as an integer, webhooks you can safely receive twice, and the first project needing its own Student table.

Campus clinicConfidential records, stock with expiry dates, and the one place the field grammar says no.

Hostel bookingHostel to room to bed, and why allocating beds rather than rooms makes the whole system work.

Online examination platformQuestions reused across exams, and one answer table holding two shapes of answer.

Course registrationThe deepest schema here: a four-level academic tree, and prerequisites relating courses to courses.

What each one teaches

They are ordered so that each adds one thing:

	Project	New in it
1	Lost and found	Uploads, two relations to one table, a conditional field
2	Library	Many-to-many as a resource, title versus copy, money
3	Marketplace	A table pointing at itself, several files per record, ratings
4	Complaints	Anonymity that removes the name, an append-only trail
5	Event ticketing	Why an order is not a ticket; a code scanned once
6	Fees	Money as an integer, idempotent webhooks, a Student table
7	Clinic	Confidentiality per role, stock batches, enum limits
8	Hostel	A four-level hierarchy, and allocating the smallest unit
9	Exams	Reused questions, one table for two answer shapes
10	Course registration	A deep tree, and a junction from a table to itself

What these pages assume

That you have read the quickstart and have an app running. Beyond that they are self-contained, and each says which of the others it builds on.

How to use one

Read the design section first and argue with it. The table design is the project — it is the part your supervisor will question and the part Flare turns directly into code. If you disagree with a modelling decision, change it; the commands are three lines of text, not a scaffold you are stuck with.

Then run the commands. Then read the last section of the page, which is the part Flare does not write: the matching algorithm, the fine calculation, the timetable solver. That is your actual contribution, and every page names it explicitly so you can tell the difference between what you generated and what you built.

A note on scope

Flare generates the parts of an application that are the same in every application: tables, migrations, validation, a REST API, an admin with list, create, edit and detail screens, uploads, roles. That is most of the code and almost none of the interesting decisions.

It does not generate your domain logic, and these pages do not pretend it does. A library without a fine rule is a catalogue; the rule is yours.