Build a Lending Tracker as a Python Group Project for Clubs

Our club owns eleven Raspberry Pi kits, two spare keyboards and a shelf of donated Python books. Last spring we lost track of four of them in a single term. Nobody stole anything; people just borrowed things and forgot. So we turned the problem into a Python group project, and it became the best thing our members built all year.

A lending tracker is a small program that records who borrowed which item and when it is due back. It sounds plain, and that is the point. Every member understands the problem on day one, the code splits naturally into parts, and the finished tool gets used every single week. Here is how we ran it, what each team built, and where it went wrong.

Why a Lending Tracker Works as a Python Group Project

Most club projects fail for one of two reasons: the idea is too big, or only the strongest coder can touch the hard part. A lending tracker avoids both.

The scope is fixed. Items, members, loans, due dates. You can finish the core in a few sessions.
Every part is real but small. Reading a file, checking a date, printing a report. Each piece is a beginner sized task with a clear test.
It has an obvious user. The club itself. Feedback arrives the first time someone borrows a kit.
It grows if you want it to. Strong members can add search, reminders or a simple web page without blocking anyone else.

We ran it with fourteen members, from people who had written fewer than fifty lines of Python to two who had shipped small apps.

The Data Model Everyone Agrees On First

Before anyone opens an editor, spend the first twenty minutes on paper. Agree on exactly what gets stored. We wrote this on the whiteboard and photographed it:

Record	Fields	Stored in
Item	item id, name, type, condition	items.csv
Member	member id, name, year group	members.csv
Loan	item id, member id, date out, date due, date returned	loans.csv

Plain CSV files were a deliberate choice. Beginners can open them in a spreadsheet and see exactly what their code wrote. Once loaded, each row becomes a Python dictionary, which made this project a natural follow on from our dictionary practice exercises.

The one rule that saved us later: item ids never change and are never reused. Write that on the board too.

How We Split the Work Into Four Teams

We used teams of three or four, each mixing one confident coder with newer members. Every team owned one file and one job.

Team one: loading and saving

Functions that read each CSV into a list of dictionaries and write it back. Simple, but everyone else depends on it, so this team finishes first and the confident member reviews it closely.

Team two: borrowing and returning

A borrow function that refuses an item already on loan, and a return function that fills in the return date. This is where most of the logic lives.

Team three: due dates and overdue checks

Using Python's datetime module to set a due date fourteen days out and list everything overdue today. Newer members found dates surprisingly fun once they saw them working.

A text menu that calls everyone else's functions, plus a weekly report: what is out, who has it, and what is late.

Agree on function names and arguments before splitting. We wrote each signature on a card, for example "borrow item, taking an item id and a member id, returning true or false". Teams could then work in parallel using fake data until the real functions arrived.

Session by Session, What Actually Happened

We meet for ninety minutes once a week. The core tracker took four sessions.

Session one: data model on paper, teams formed, CSV files created by hand with five sample items and members.
Session two: each team wrote its functions against sample data. Team one finished and shared their code.
Session three: joining everything together. This was messy, as it always is. Two teams had used different spellings for the same dictionary key.
Session four: testing with real items, fixing bugs, and the first real loan. Our treasurer borrowed a Pi kit and got a printed receipt.

If your club prefers a longer arc with clear milestones, the same project fits neatly into the structure in planning a six week club project, with two extra weeks for features.

The Advice I Would Ignore Next Time

Many guides to club projects say to set up Git, branches and pull requests from day one, because "that is how real teams work". For this group, I would not do it again.

Half our members had never used a terminal. In session one we spent forty minutes on login problems and merge conflicts, and three people left feeling the project was not for them. That is a bad trade for a ninety minute meeting.

What worked better was a shared folder, one file per team, and a single "integrator" who copied finished files into the main version. Clumsy by industry standards, but nobody lost an evening to tooling. We introduced Git in week five, once people cared about the code and could see why versions matter. The lesson is not that Git is bad; it is that tools should arrive when the problem they solve becomes visible.

Extensions for Members Who Finish Early

Fast teams always need something next. Ours chose from this list, and each one stays separate from the core so it cannot break it:

Search items by name or type, ignoring capital letters.
A "most borrowed" ranking built from the loans file.
Condition notes added on return, such as "missing SD card".
A reminder message printed for each member with something overdue.
A small web page using a lightweight framework, for members who wanted to try one.

The ranking feature produced the most discussion. Seeing the books nobody had ever borrowed led to a reorganised shelf.

Frequently Asked Questions

How much Python do members need before starting?

Variables, lists, loops, if statements and basic functions. Dictionaries and reading files can be learned during the project with a short demo at the start of session two.

Can this project work with only four or five members?

Yes. Merge teams one and four, and two and three. It takes a session longer, but each person sees more of the program.

What if our club has nothing to lend?

Track something else the club shares: library books from the school, rotating presentation turns at meetings, or a snack rota. The data model stays almost identical.

Start With the Whiteboard, Not the Code

If you try this next term, spend the first session entirely on the data model and the function signatures. That one hour decides whether four teams build parts that fit. Keep files plain, keep tools simple until people need more, and get one real loan recorded as early as possible. Browse our other club project ideas when you are ready for the next build.