1) Purpose A mobile app (iOS + Android) for school communities to share second-hand school clothes for free. Parents/guardians join one or more school communities, list items with photos, request items, chat to arrange pickup/drop-off, and optionally post “wanted” requests. The app tracks points to encourage reuse. 2) Users and roles 2.1 Organisation Admin (your organisation only) Can: • Create and manage schools • Moderate users and listings (remove, suspend, review reports) • View activity logs and reporting dashboards • Manage categories, sizes/age ranges, and basic app settings • View/export data for admin purposes (within GDPR constraints) 2.2 Member (Parent/Guardian) Can: • Register/login • Create a profile • Join multiple schools • List items (with quantity) • Request items from other members • Post “wanted” requests • Use in-app chat to arrange handover • Set alerts (push + email) for size/age + gender + category + school(s) • Earn points and view points history Adults only. No student accounts. 3) Schools and communities • A “School” is a community space containing listings and requests. • Members can join multiple schools. • Listings can be shared across multiple schools (member chooses which schools a listing appears in). • No identity checks required to join a school (simple join flow). 4) Core features (MVP) 4.1 Registration and login • Email + password (minimum) • Password reset • Basic account settings (language, notification preferences) 4.2 Member profile Profile fields (minimum): • Display name (or first name + last initial) • Optional avatar/photo • Optional postcode area (e.g., “CF10”) for general context (not required) • Joined schools list • Points balance + points history • Basic preferences (language Welsh/English) Privacy: • No direct phone/email shown to other members • All coordination happens via in-app messaging 4.3 School page (per school) Shows: • Feed of available listings • Filters: category, gender, size/age, condition, keyword search • Separate tab/section for “Wanted” requests • Button to post a listing • Button to post a wanted request 4.4 Listing an item (donation only) A member can create a listing with: • Photos (at least 1, allow multiple) • Title (short) • Description (brief) • Category (e.g., jumper, t-shirt, shorts, trousers, skirt, PE kit, blazer, etc.) • Gender (e.g., girls/boys/unisex) • Size/age (age-based sizes as agreed in your size list) • Condition (new / very good / good / fair) • Brand (optional) • Colour (optional) • School logo: yes/no (optional) • Quantity (number available of the same item) • Visible in: one or more schools (multi-select) Listing statuses: • Available (default) • Requested (one or more incoming requests exist) • Reserved (owner approved a request and reserved quantity) • Handover arranged (collection/drop-off agreed in chat) • Completed (handover done; listing quantity reduced/closed) Rules for quantity: • If quantity > 1, owner can approve multiple requests up to the available quantity. • If quantity reaches 0, listing becomes Completed/Closed automatically. 4.5 Requesting an item (from a listing) Flow: 1. Member taps “Request item” 2. Chooses quantity (1..available) 3. Optional message 4. Owner receives a request notification 5. Owner can Approve or Decline 6. If approved: item quantity is reserved and chat opens (or continues) to arrange handover 4.6 In-app chat (handover coordination) • Chat is available between two members only after an item request exists (reduces spam). • Chat supports: • Text messages • Optional image share (nice-to-have; can be MVP if you want) • System messages for status changes (e.g., “Request approved”, “Status changed to Handover arranged”) • No phone numbers/emails revealed. 4.7 “Wanted” requests (members asking for items) A member can post a request like: • Category • Gender • Size/age • Description (“Looking for PE kit age 8–9”) • Schools where the request should appear (one or more) Other members can reply via in-app chat. 4.8 Alerts (push + email) Members can create multiple alert criteria. Each alert includes: • School(s) • Category (optional) • Gender (optional) • Size/age (optional but supported) • Keywords (optional) When a new listing matches, send: • Push notification (if enabled) • Email notification (if enabled) 5) Points and rewards 5.1 Points rules • +2 points every time a member lists an item (on successful listing creation) • +2 points every time a member completes an exchange as the giver (handover completed for reserved quantity) • +1 point every time a member gets an item (handover completed for reserved quantity) Notes to make this fair with quantity: • If a listing has quantity > 1 and the member hands over 3 items in one “completion”, award points per item handed over (recommended), not per listing. Same for the receiver. • Keep the original “+2 for listing” as per listing creation (not per quantity) unless you want it per item. 5.2 Points record The app stores a points ledger: • Date/time • Event type (listed / gave item / received item / admin adjustment) • Item reference • Quantity involved • Points added/removed • Running total Admins can adjust points (with a mandatory reason) and this is logged. 6) Admin features 6.1 School management • Create/edit/archive schools • School details: • Name • Address (optional) • Local authority (optional) • School logo (optional) • Status (active/inactive) 6.2 Moderation Admins can: • View members and their joined schools • Suspend/ban member accounts • Remove listings or wanted requests • Review reports and take actions • View chat metadata (not contents unless you explicitly decide to allow it) 6.3 Reporting and logs • Reports dashboard: • Number of new listings, requests, completions • Popular categories/sizes • Active users per school • Activity log (auditable): • Who did what, when (member + admin actions) • Listing status changes • Request approvals/declines • Admin moderation actions 7) Reporting (member-facing) Members can report: • A listing (e.g., misleading, inappropriate) • A wanted request • A user profile (optional) Report captures: • Reason category + free-text notes • Evidence (optional screenshot/image upload) Admin sees the report queue and outcomes are logged. 8) Languages and localisation • Full bilingual support: English and Welsh • User selects language in onboarding and can change it in settings • All UI text, emails, push notifications, and category labels must be translated • Store content (user descriptions) remains as entered by the user (no auto-translation) 9) Data and privacy (UK, GDPR-aligned) Minimum commitments: • Clear consent for push/email notifications • Ability to delete account (and define what happens to historical listings: typically anonymise the user) • Privacy policy and terms in-app • Data retention rules (define retention for logs, messages, completed listings) • Secure storage for passwords (hashed) and media (protected) • Role-based access control for admin tools 10) Key screens (suggested) Member app: • Welcome / Login / Register • Choose language (Welsh/English) • Home (your schools + quick search) • School page (Listings tab / Wanted tab) • Listing details (photos, info, request button) • Create listing (multi-step form + photos) • Create wanted request • Requests inbox (incoming/outgoing) • Chat • Alerts setup (list + create/edit alert) • Profile (points + history, joined schools, settings) • Report content flow Admin (web portal recommended, but could be mobile/tablet): • Dashboard • Schools management • Members management • Reports queue • Listings management • Logs / audit trail • Categories/sizes configuration 11) Key workflows 11.1 Listing to completion Available → Requested → Reserved → Handover arranged → Completed Each step triggers: • Status update stored • System message in chat (where relevant) • Notifications to the other party 11.2 Multiple schools per listing When creating a listing, member selects 1+ schools. The listing appears in each selected school feed. 11.3 Multiple requests and quantity • Owner sees all requests • Owner approves requests until quantity is fully reserved • Remaining requests can be declined or left pending (your choice; I recommend forcing a decision within a set time later as a “phase 2” enhancement) 12) Non-functional requirements • iOS and Android parity (same features) • Photo upload should be fast, compress images, and handle poor connectivity • Accessibility basics (font scaling, screen reader labels) • Secure APIs, rate limiting, and abuse prevention • Monitoring and error logging (crash reporting)