Contact person: Business Client

Phone:Show

Email:Show

Location: City of London, United Kingdom

Budget: Recommended by industry experts

Time to start: As soon as possible

Project description:
"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)" (client-provided description)