My Journey

cycling buddies brd

13 min read

✅ chatgpt BRD

1. Background

The London Cycling Campaign (LCC) operates Cycle Buddies, a behaviour-change initiative connecting:

  • Starters (people wanting to cycle)
  • Helpers / Instructors (volunteers or professionals)

The previous platform (Django + React, hosted on Heroku) was suspended in March 2026 due to provider insolvency.

LCC requires:

  • rapid relaunch
  • migration of historical data
  • improved safety, reporting, and scalability

2. Work Context Diagram

graph TD
    subgraph Users
        S[Starter]
        H[Helper]
        I[Instructor]
        A[LCC Admin]
        P[Partner Admin]
    end

    subgraph External Systems
        MAP[Postcode / Distance API]
        EMS[Email Service]
        DB[LCC Membership future DB]
    end

    subgraph System
        SYS[Cycle Buddies Platform]
    end

    S -->|Search, Message, Feedback| SYS
    H -->|Profile, Respond, Availability| SYS
    I -->|Register, Provide Instruction| SYS
    A -->|Moderate, Report, Verify| SYS
    P -->|View Reports | SYS

    SYS --> MAP
    SYS --> EMS
    SYS --> DB

3. Business Requirements

BR-1: Data Continuity

  • Migrate ≥95% of:
    • user accounts
    • profiles
    • message history

BR-2: Privacy-Preserving Matching

  • Match by postcode distance
  • Never expose:
    • full postcode
    • exact location
    • coordinates

BR-3: Safeguarded Messaging

  • Restrict sharing of personal contact details in first message
  • Encourage public meeting locations

BR-4: Verified Instruction

  • Instructors must not appear in search or messaging until:
    • credentials verified by LCC admin

BR-5: Measurable Outcomes

  • Track:
    • meet-ups
    • cycling confidence
    • engagement

BR-6: Administrative Oversight

  • Admins must:
    • access all profiles and messages
    • send targeted communications
    • generate reports

BR-7: Regulatory Compliance

  • GDPR (UK/EU hosting required)
  • Online Safety Act 2023

4. Use Cases

UC-1: Register Account

Primary Actor: Unregistered User
Actors: Starter, Helper, Instructor

Preconditions

  • User has valid email and mobile number

Main Flow

  1. User selects account type (Starter / Helper / Instructor)

    • Rule: System displays role-specific guidance

  2. User enters:

    • name
    • address
    • email
    • mobile
    • password
    • display name

  3. System validates input

    • Rule: Email must be unique
    • Rule: Password must meet security requirements

  4. System sends verification email

  5. User activates account

  6. System creates base account and prompts profile creation

Alternate Flow

A1: Outside London postcode

  • System flags non-Greater London postcode
  • User must confirm:
    • lives OR works in London
  • If not → registration halted with signposting

UC-2: Create Profile

Primary Actor: Registered User

Main Flow (Starter)

  1. User enters cycling ability and bike ownership

  2. User selects goals and motivations

  3. User enters up to two postcodes

    • Rule: Labels allowed (e.g. home, work)

  4. User selects partner organisation (optional)

  5. User enters diversity data

    • Rule: Year of birth required
    • Rule: All others optional

  6. User confirms:

    • over 18
    • safety responsibility

  7. User submits profile

  8. System saves and activates account

Main Flow (Helper / Instructor)

  1. User enters experience and motivation

  2. User selects badges (e.g. disability, LGBTQ+)

  3. User uploads optional profile photo

  4. User enters free-text description

    • Rule: block URLs, emails, phone numbers

  5. User confirms:

    • guidelines read
    • duty of care

  6. If Instructor:

    • enter credential ID
    • Rule: profile status = “Pending Verification”

  7. System publishes profile

    • Rule: instructors hidden until approved

UC-3: Search Helpers

Primary Actor: Starter

Preconditions

  • Starter profile complete
  • At least one postcode present

Main Flow

  1. Starter opens search

  2. System retrieves helpers

  3. System calculates distance

    • Rule: server-side only
    • Rule: exact postcode not exposed

  4. System sorts results

    • default: distance
    • options:
      • recent activity
      • recently joined

  5. Starter applies filters:

    • gender match
      • Rule: match based on registered gender
    • LGBTQ+ inclusion
    • badge filters

  6. System displays helper cards:

    • photo
    • badges
    • distance (approximate only)

UC-4: Send Message

Primary Actor: Starter
Secondary Actor: Helper

Preconditions

  • Helper profile active
  • Helper not “on a break”

Main Flow

  1. Starter opens message interface

  2. System displays guidance prompts

  3. Starter writes message

  4. System validates message

    • Rule: first message must NOT contain:
      • phone numbers
      • emails
      • URLs

  5. If violation:

    • block send
    • display safety warning

  6. Starter sends message

  7. System logs message

  8. System waits 30 minutes

  9. If unread:

    • send email notification to helper
    • include message content

  10. Helper replies

  • Rule: subsequent messages may include contact details

UC-5: Exchange Messages

Actors: Starter, Helper

Main Flow

  1. Users exchange messages

  2. System logs:

    • timestamps
    • response times

  3. System enables notification emails on delay

UC-6: Provide Feedback

Actors: Starter, Helper

Preconditions

  • At least one message each way
  • 4 weeks elapsed

Main Flow

  1. System sends email with options:

    • Yes (met)
    • No (not planning)
    • Not yet

  2. User selects option

  3. System records response

  4. If “Not yet”:

    • schedule follow-up email after 2 weeks

  5. If no response:

    • show dashboard popup on next login

  6. If “Yes”:

    • prompt confidence improvement question

Rules

  • No public ratings or reviews allowed

UC-7: Manage Availability

Primary Actor: Helper

Main Flow

  1. Helper sets “On a break”

  2. System updates profile

  3. Rule:

    • profile hidden from search
    • messaging disabled

Alternate Flow

A1: Inactivity

  1. System detects 6 months inactivity
  2. System sends warning email
  3. If no login after 14 days:
    • auto set “On a break”

UC-8: Administer Platform

Primary Actor: LCC Admin

Main Flow

  1. Admin views user profiles

  2. Admin views message logs

  3. Admin edits profile

    • Rule: system logs change
    • Rule: notify affected user via email

  4. Admin verifies instructor credentials

    • Rule: set status = active

  5. Admin sends targeted emails

  6. Admin defines automation rules:

    • inactivity
    • nudges

  7. System logs:

    • emails sent
    • failures

UC-9: Generate Reports

Primary Actor: LCC Admin

Main Flow

  1. Admin selects report

  2. System generates metrics:

  • users by type
  • demographics
  • location
  • partner affiliation
  • active users
  • logins
  • search activity
  • messaging stats
  • response rates
  • meet-ups (feedback-based)
  • confidence improvements

  1. Admin exports or schedules report

  2. System emails reports to partners

    • Rule: log all report deliveries

5. Non-Functional Requirements

Security & Safety

  • No exposure of precise location data
  • Messaging restrictions enforced
  • Full audit logs

Performance

  • Scalable to London-wide usage
  • Responsive search (<2s typical)

Compliance

  • GDPR (UK/EU hosting)
  • Online Safety Act 2023

6. Future Enhancements

  • Profile browsing (carousel navigation)
  • Helper ride notes
  • Multi-affiliation system
  • Affiliation-based filtering (private)
  • Partner dashboards
  • Community group profiles
  • Custom signup links
  • LCC membership integration

If you want, I can next:

  • convert this into user stories + backlog (Jira-ready)
  • or design a solution architecture (AWS/Azure + costed options)
  • or produce a vendor scoring sheet for procurement

gemini BRD

Background

The London Cycling Campaign (LCC) is a prominent UK charity with over 20,000 supporters. Cycle Buddies is its premier behaviour-change initiative, designed to pair cycling novices (“starters”) with experienced volunteers (“helpers” and professional “instructors”) to build sustainable cycling habits. First launched as a manual matching system in 2020 and transitioned to a custom Django/React web platform in 2023, the digital service was abruptly suspended in March 2026 due to the previous platform provider’s insolvency. LCC is now issuing a tender to either revive the legacy application or build a clean-slate replacement. The priority is to quickly relaunch a secure, GDPR-compliant, and highly localized matching platform while migrating historical user data, profiles, and communication logs.

Context Diagram

The diagram below maps the system boundary of the Cycle Buddies Platform, showing the interaction between human actors and external system actors.

graph TD
     External Systems
    subgraph External Systems
        DB[(LCC Membership Database)]
        MAP[Postcode/Mapping API]
        EMS[Email/SMS Gateway]
    end

     Relationships
    S -->|Searches, Filters, Initiates Messages, Provides Feedback| SYS
    H -->|Registers, Updates Profile, Responds to Messages, Sets Availability| SYS
    I -->|Registers Credentials, Responds, Offers Paid/Voluntary Help| SYS
    A -->|Manages Accounts, Audits Message Logs, Pulls Reports, Checks Credentials| SYS
    P -->|Views Partner-Specific Reports/Dashboards| SYS

    SYS -- "Validates Postcode Coordinates" --- MAP
    SYS -->|Sends Verification/Notifications/Triggers| EMS
    SYS -- "Validates LCC Member Numbers (Future Integration)" --- DB

Business Requirements (Solution-Agnostic & SMART)

Assumptions:

  • LCC has legal ownership and access to the legacy relational database export (schema and records).

  • An API or local database for UK postcodes (such as Ordnance Survey or Postcode.io) is accessible for distance calculations.

  • All hosting will occur within the UK or EU to automatically comply with GDPR.

  • Instructors’ National Standards Instructor (NSI) or 1st4Sport registration numbers can be verified via existing external registries or manual administration.

BR-1: Core Data Migration

  • Statement: Migrate at least 95% of active historical user account credentials, matching profiles, and historical messaging logs from the previous Python/Django platform database.

  • SMART Criteria:

  • S: Specific target of database import.

  • M: Measured by database reconciliation scripts comparing source and target record counts.

  • A: Highly achievable given database access.

  • R: Ensures community continuity.

  • T: To be completed and verified before public beta launch.

BR-2: Privacy-Preserving Geographic Distance Matching

  • Statement: Order helper search results by distance calculated from the Starter’s postcode (home or work) to the Helper’s postcode(s). The system must never expose the precise coordinates, home addresses, or postcodes of any user to another.

  • SMART Criteria:

  • S: Keeps precise physical locations private while sorting by proximity.

  • M: Distance output is display-capped to qualitative bands (e.g., “0.5 miles away”, “Less than half a mile away”).

  • A: Achievable through server-side Haversine/coordinate calculations.

  • R: Critical for personal safety and privacy.

  • T: Ready for the initial release.

BR-3: Identity and Credential Verification Gate

  • Statement: Prevent newly registered Instructors from appearing in search results or using messaging until an LCC Administrator manually verifies their NSI or 1st4Sport credential.

  • SMART Criteria:

  • S: Administrative approval gate for professional instructor accounts.

  • M: “Verified” state boolean in database must be true before profile visibility query is satisfied.

  • A: Standard workflow configuration.

  • R: Guarantees public safety and legitimacy.

  • T: Must be functional on day one of relaunch.

BR-4: Demographic and Organizational Reporting

  • Statement: Generate on-demand and scheduled reports broken down by local authority, partner organization affiliations, age bands, and diversity metrics (ethnicity, gender, sexual orientation, spiritual beliefs).

  • SMART Criteria:

  • S: Detailed reporting capabilities for LCC and funding partners.

  • M: Correct calculation of statistics across all user registration fields.

  • A: Standard data aggregation queries.

  • R: Crucial for proving impact to charity stakeholders and NHS trusts.

  • T: To be implemented within 1 month of platform launch.

BR-5: Automated Engagement Tracking and Feedback Loop

  • Statement: Automatically survey paired buddies via email and dashboard pop-ups 4 weeks after their first mutual message exchange to track if a meet-up occurred and assess confidence gains.

  • SMART Criteria:

  • S: Two-step transactional tracking (4-week survey and 2-week follow-up if unanswered).

  • M: Survey click-through responses are logged as structured records on user profiles.

  • A: Achievable using cron jobs / scheduled tasks and tracking tokens.

  • R: Essential for measuring project success.

  • T: Implemented for launch.

Use Cases

UC-1: Register and Create Profile (Onboarding)

  • Primary Actor: Unregistered User (Starter, Helper, or Instructor)

  • Preconditions: User has access to the web platform and holds a valid email address.

  • Happy Flow:

  1. User selects their profile type (Starter, Helper, or Instructor) and acknowledges the category criteria.

  2. User inputs first name, surname, full postal address, email, and mobile number.

  3. User enters a display name and password following the on-screen safety guidance.

  4. System validates the address and sends an activation link to the user’s email.

  5. User clicks the verification link, logs in, and fills out the profile details (ability, postcodes, diversity metadata, and partner affiliations).

  6. System saves the profile and displays a customized welcome dashboard with tips on getting started.

UC-2: Search and Match Helpers

  • Primary Actor: Logged-in Starter

  • Preconditions: Starter’s profile is fully complete, and at least one postcode is configured.

  • Happy Flow:

  1. Starter clicks “Search for Helpers” on their dashboard.

  2. System detects the Starter’s primary postcode and queries the database for active Helpers.

  3. System sorts results by closest proximity, most recently active, or newest members based on Starter’s selected sorting option.

  4. Starter toggles the “Match Gender” filter.

  5. System filters out any helper profiles whose registered gender does not match the Starter’s registered gender.

  6. Starter views a safe, photographic summary card of matching helpers showing distance approximations (e.g., “0.8 miles away”) and expertise badges.

UC-3: Initiate and Exchange Messages

  • Primary Actor: Logged-in Starter

  • Preconditions: Starter has found a Helper profile of interest.

  • Happy Flow:

  1. Starter clicks the “Message” button on the Helper’s profile card.

  2. System opens a text workspace pre-populated with friendly prompt suggestions on safety and initial conversation starters.

  3. Starter writes and sends the message. System checks for safety violations (e.g., blocks initial links/emails/phone numbers).

  4. System records the message in the secure communications log.

  5. System waits 30 minutes; if the Helper hasn’t read the message, an automated notification email containing the message body is sent to the Helper.

  6. Helper logs in and replies. System permits URLs and phone numbers in subsequent responses to facilitate meeting logistics.

UC-4: Provide Ride Feedback

  • Primary Actor: Starter or Helper

  • Preconditions: Both buddies have exchanged at least one message each way, and 4 weeks have elapsed.

  • Happy Flow:

  1. System triggers an automated feedback email containing three simple option buttons: “Yes, we met”, “No, and don’t plan to”, and “No, but we hope to”.

  2. User clicks “Yes, we met” inside the email.

  3. System registers the click, authenticates the token, and updates the user profile with the confirmation.

  4. System redirects the user to a quick dashboard pop-up asking for a subjective assessment of confidence improvement.

  5. User submits the single confidence question, and the feedback loop is successfully closed.

UC-5: Toggle Availability (“On a Break”)

  • Primary Actor: Helper

  • Preconditions: Helper profile is currently live and visible.

  • Happy Flow:

  1. Helper logs into their dashboard and navigates to “Update Profile”.

  2. Helper checks the “I am on a break” checkbox and saves.

  3. System updates the status flag and immediately hides the Helper’s profile from all Starter searches.

  4. (Later) Helper returns, unchecks the box, and the system restores the profile to active search results.

Alternate / Exception Flows

UC-1-Alt A: Outside London Restriction

  • Trigger: Non-London postcode entered during address verification stage.

  • Flow:

  1. System flags that the postcode is outside the Greater London service boundary.

  2. System shows a helpful warning banner stating the platform is geographically restricted but allows the user to declare if they work inside London.

  3. If user cannot confirm working/living in London, registration is safely paused, and they are redirected to public cycling resources.

UC-1-Alt B: Instructor Awaiting Verification

  • Trigger: Instructor completes registration.

  • Flow:

  1. System completes profile creation but sets visibility status to “Pending Verification”.

  2. System sends a notification to the LCC administrative portal.

  3. Profile is excluded from all search queries until approved by an administrator.

UC-3-Alt A: URL/Contact Details in First Message

  • Trigger: Starter inputs an email address, phone number, or URL in the very first message.

  • Flow:

  1. System blocks the send operation.

  2. System displays an on-screen warning: “For your safety, please do not share personal contact details, emails, or websites in your first message. Meet in a public space first.”

  3. Starter modifies the message to comply and resends successfully.

UC-4-Alt A: No Email Response / Dashboard Prompt

  • Trigger: User does not click a button in the feedback email.

  • Flow:

  1. Two weeks later, the system sends a follow-up email.

  2. If still unanswered, upon the user’s next login, the system renders a blocking modal window (dashboard pop-up) containing the feedback questions.

  3. User completes the feedback inside the modal, unlocking normal dashboard navigation.

UC-5-Alt A: Inactive Helper Auto-Sabbatical

  • Trigger: Helper has not logged in for 6 months.

  • Flow:

  1. System scheduled task detects 6 months of inactivity.

  2. System sends an automated warning email to the Helper requesting they log in to keep their profile active.

  3. If the Helper fails to log in within 14 days of the email, the system automatically sets their profile flag to “On a Break” and updates their dashboard with an activation prompt.

Graph View