A small app for community project supplies

Our Rotary Mihan volunteers usually start a project with good intentions, donated items and a clipboard. This is the story of how we developed a simple mobile app for tracking project supplies after repeated shortages, duplicate purchases and uncertainty about where stock had been stored. We wanted one shared answer to three practical questions: what we had, what a project needed and who had moved it.

We deliberately avoided building a large procurement platform. The first version focused on counting, locations, low-stock alerts and basic project history, and it opened from the Rotary Mihan Members portal. That narrow scope let us test the app with volunteers while keeping account registration, password recovery and profile management in the familiar member area.

The problem behind the clipboard

A health camp exposed the problem clearly. Volunteers recorded gloves, masks and drinks on separate sheets, while boxes of supplies remained in a cupboard at another venue. Nobody could confirm whether an item was available, reserved or already in use.

Our own update on school garden work showed how quickly one project can generate several supply groups: tools for adult volunteers, gloves and aprons for students, seeds for garden beds and containers for seedlings. Each group has a different storage place and consumption rate.

We translated those experiences into a short requirements list. The app had to show available quantities by project and location, record withdrawals, flag items running low and preserve a simple history. It also needed to work for volunteers who would never describe themselves as technical users.

Designing around volunteer routines

We considered how volunteers move through an Australian day. Members might travel across Melbourne or Sydney by car, bus or tram, then carry supplies from a shopping centre to a school, community centre or temporary clinic. A cumbersome interface would quickly be abandoned.

Everyday purchasing habits also shaped the design. Many members buy stationery at Officeworks, tools from Bunnings or Mitre 10, and event materials through supermarkets such as Coles or Woolworths. Click-and-collect is common, receipts arrive by email, and a quick photograph in the car is often easier than entering dozens of details later. The app therefore accepts photographs and short notes alongside formal quantities.

Outdoor conditions added another constraint. Volunteers may be dealing with summer heat, sudden rain or uneven mobile coverage in regional areas. Large controls, clear labels, high contrast and cached access to recently viewed items proved more valuable than dense tables, tiny icons or elaborate animations.

The first useful version

The first usable release contained a searchable catalogue of common supplies. Each item could be linked to a project, venue and storage area, with the quantity on hand, minimum stock level and unit of measure visible on one screen. Coordinators could add new items without waiting for a developer.

Volunteers could check supplies out or return them by entering a quantity and selecting a destination. Every movement generated a dated record showing who handled it and why. Low-stock alerts appeared on the project dashboard, while photographs of damaged or donated items could be attached to the relevant entry.

We also connected the app to member sign-in so volunteers did not need another account. Profile details remained in the main portal, while the supply app displayed only the information needed for approvals and stock records. Community updates, newsletters and project news stayed in their established sections rather than being mixed into inventory screens.

Choosing tools that stay out of the way

We used a lightweight web-app framework that could be installed on Android and iPhone devices. The underlying database was familiar enough for a small technical team to maintain, while the interface remained uncomplicated for members. Barcode and QR scanning worked through the phone camera for labels attached to storage boxes.

A web search for examples of volunteer reporting offered another useful reminder. Reading about community reporting in Tunis reinforced that a number without context is rarely enough: the date, venue and purpose of a count matter when someone reviews it weeks later. We added a short notes field to stock entries without making lengthy commentary compulsory.

Our rule was that every feature should answer a known volunteer need. If a function did not speed up counting, approval or handover, we left it out. This kept the first version small enough to change after each pilot and prevented project management features from taking over the app.

Protecting member and project data

The application stores more than objects on a shelf. It may include member names, purchase details, delivery addresses and information about health-related projects. We treated the Australian Privacy Principles under the Privacy Act 1988 as the minimum standard for handling that information, even where the club’s legal coverage required careful assessment.

Access was limited by role. Ordinary volunteers could view relevant stock and record movements, while coordinators approved purchases and administrative users managed catalogues, locations and retention settings. Passwords, recovery details and session management remained aligned with the portal’s existing authentication process, and database access was restricted to authorised maintainers.

We also reviewed how the app described and grouped people. For projects involving dietary needs, scheduling or community outreach, we consulted Islamic research while reviewing culturally sensitive wording. The resulting design principle was simple: the supply app should hold operational details, not assumptions about members’ beliefs, backgrounds or identities.

What field testing changed

We piloted the app during a blood donation drive, an educational materials session and a youth activity. Volunteers consistently requested fewer steps. Instead of opening a project, choosing a location and then searching for an item, they wanted the most likely project and storage area selected first.

Large buttons, plain-language labels and confirmation messages for check-outs became more important than visual polish. We added an offline cache for saved projects, improved error messages for poor reception and made quantity adjustments easier when volunteers were wearing gloves. The app now records whether an item was purchased, donated, reserved or consumed.

Resource testing also showed why curated links matter. One broad search produced casino free spins alongside pages genuinely relevant to community work. The promotional result had no place in a volunteer resource area, so we removed it and limited future listings to reviewed club material.

A practical workflow for future projects

Several practices helped the new system remain dependable across health camps, fundraisers and local outreach activities. The following approach also gives future projects a clear starting point:

• Begin with one project and one shared supply catalogue.
• Agree on standard names, units and item identifiers before counting.
• Assign every quantity to a named project, venue or storage area.
• Set minimum stock levels for regularly used materials.
• Record each check-out, return, donation or consumption event.
• Test the workflow outdoors, on different phones and with weak coverage.
• Review unused records and archive completed projects at the end of each cycle.

The practical takeaway is straightforward: agree on one item list, one count and one storage location before the next project begins. A useful app cannot repair unclear ownership, but it can keep that agreement visible whenever volunteers need it.