All BlueprintsEducation

School fee invoicing

Termly fees for one school: the office raises four hundred invoices at four hundred different amounts in a single action, a guardian sees what each of their children owes and why, payments that arrive by transfer land on named bills, and what is overdue is chased until the money arrives.

L3–L5Level range
8Sprints
43Tasks
Backend and frontendBuilt as

What you’ll build.

By the last sprint

A school fee system. Parents sign in and see what each child owes this term and why. The office raises a whole term of invoices in one go, records transfers against the right bills, and turns a dropped fee into a credit. Late payers are chased every morning on their own, and the chasing stops the moment the money lands.

What you’ll learn.

Each sprint is built around one skill. You show you have it in a pull request your team reviews, then explain it in a walkthrough.

Authentication

You can register and sign in a user, keep a request authenticated without asking for the password again, and explain where the credential lives in the browser and why there rather than somewhere else.

Charging the same card monthly

You can start a subscription, produce the next charge on time exactly once, and show what happens between a failed renewal and a cancelled subscription.

Roles and permissions

You can give users different roles and have the server refuse what a role may not do — not merely hide the button — and show the refusal working against a request the interface never offered.

A ledger you can trust

You can record credits and debits and produce a balance that is the sum of them — and explain why the balance is not a column you update, and what happens when two movements land at once.

Notifications people do not mute

You can notify a user when an event concerns them, show an unread count that survives a refresh, and honour a preference that says stop.

Background jobs

You can hand work to a worker, tell the user it is in progress, and show the result when it lands — and say what happens to that work if the process dies halfway.

Going live

Somebody who has never met you can open a URL and use the product — and you can say what is different about the copy running there, where its secrets come from, and what you do when a release turns out to be wrong.

The roadmap. 8 sprints, 43 tasks.

Every sprint has a goal and a set of tasks. Open a sprint to see the tasks you will pick up.

Sprint 01

Who pays for whom

A guardian can make an account, come back to it, and reach exactly the children the school says they pay for.

6 tasks
  1. A guardian can register and land signed in
  2. Coming back next week finds the same account
  3. Signing out on a shared machine ends it there
  4. Office accounts exist, and cannot be self-issued
  5. The school's roll says who pays for each child
  6. Nothing from the roll reaches an unproved address
Sprint 02

A term's bills, raised once

The school says what the term costs each child, and puts every invoice out in one action that is safe to run again.

7 tasks
  1. A term, and what it costs each year group
  2. What one child is charged, line by line
  3. A second child from the same family costs less
  4. A child who starts in week five owes part of the term
  5. The office raises a whole term's invoices in one action
  6. Raising the same term again bills nobody twice
  7. A child the school cannot price is reported, not skipped
Sprint 03

Only your own

A guardian sees what all of their children owe in one place, and cannot reach anything that belongs to another family.

5 tasks
  1. One screen showing what the family owes this term
  2. Another family's invoice is refused, not hidden
  3. The office can find a family and open its account
  4. A family with nothing to pay is told so
  5. A guardian can keep a copy of an invoice
Sprint 04

Money that lands on something

A payment that arrived by transfer is recorded against named invoices, and every figure on a family's account is the sum of what happened.

5 tasks
  1. The office records a payment that arrived outside the product
  2. A payment lands on named invoices, never on a pile
  3. A part payment leaves an exact remainder
  4. One transfer covering three children is split across them
  5. Every total is the sum of what happened, to the penny
Sprint 05

Putting it right

A dropped fee, a payment on the wrong family and a parent who paid twice are all corrected without anything being rewritten or deleted.

5 tasks
  1. A waived fee is a credit, not a rewritten invoice
  2. A payment on the wrong family is reversed, not deleted
  3. A family that paid twice keeps the money
  4. Credit settles the next thing the family is billed
  5. A family's account reads as a history anybody can follow
Sprint 06

Chasing what is overdue

A family behind on fees is chased with something they can act on, and the chase stops the moment the money lands.

5 tasks
  1. An invoice past its date is overdue, and the office can see who
  2. A reminder a parent can act on
  3. One chase per family, on a ladder the school chose
  4. A chase written at six does not go out on a bill paid at eight
  5. The office has a list of who to ring, worst first
Sprint 07

Work that runs itself

The overdue sweep happens every morning on its own, never chases the same family twice, and says so when it fails.

5 tasks
  1. The overdue sweep runs every morning with nobody present
  2. A sweep that runs twice sends nothing twice
  3. A failed sweep is visible to somebody who can fix it
  4. The office can see what the sweep did this morning
  5. Raising a term no longer depends on a browser staying open
Sprint 08

Off the office computer

The product is on the internet at its own address, chasing on its own at the school's hour, with the term's money still on it after a release.

5 tasks
  1. A stranger can reach the product at its own address
  2. Nothing the product needs to run is in the repository
  3. The morning sweep runs on the server, at the school's hour
  4. A term's money survives a release
  5. A release that is wrong can be put back

Read before you build. The best engineers do.

Senior engineers read the docs before they touch the code. Every Blueprint comes with short documents on the product and its world, the kind a team hands a new hire. Read them well and you ask sharper questions and walk into every review prepared.

What you are building

The product, the two people who use it, and what finished means.

How a school actually charges for a term

Domain you will not have: fee heads, sibling discounts, part terms, and why a family is the unit rather than a child.

Build school fee invoicing.

Start your free week. Adaeze runs your kickoff, and Lars reviews every pull request.