My Journey

cycling buddies ground up build

4 min read

✅ Definition of MVP Success

The MVP is successful if:

  • A user can:

    • register
    • create a profile
    • find a nearby helper
    • send and receive messages

  • LCC admins can:

    • view users
    • intervene if needed

  • The platform supports:

    • ~100–500 active users reliably

2. Scope (Simplified Requirements)

✅ Included (Phase 1 MVP)

1. User Registration & Profiles

  • Starter and Helper roles
  • Basic profile fields:
    • name (display name)
    • email (verified)
    • postcode (1 required)
    • cycling ability
    • optional demographics (stored but not heavily used yet)

Simplification:

  • No complex onboarding flows
  • No multiple postcode logic (start with one)

2. Helper Discovery (Core Feature)

  • List helpers ordered by:
    • distance from postcode
  • Basic filters:
    • gender match (optional toggle)

Simplification:

  • No badge system initially
  • No advanced sorting (activity/recent join)

3. Messaging (Essential but Simplified)

  • 1-to-1 messaging between starter and helper
  • Threaded conversations
  • Email notification on new message

Safety Rules (kept):

  • Block phone/email/URL in first message
  • Allow in subsequent replies

Simplification:

  • No 30-min delay logic
  • No advanced moderation initially

4. Basic Admin Capability

  • View users
  • View message threads
  • Manually disable users

Simplification:

  • No advanced dashboards
  • No automated admin workflows

5. Feedback Capture (Lightweight)

  • Simple email after 4 weeks:
    • “Did you meet?” (Yes / No / Not yet)

Simplification:

  • No follow-up automation
  • No confidence tracking initially

❌ Deferred to Later Phases

  • Instructor verification workflows
  • Badge system (LGBTQ+, disability, etc.)
  • Multi-postcode support
  • Advanced reporting dashboards
  • Partner organisation features
  • Automated inactivity handling
  • Complex email automation rules
  • Community group features

3. Proposed Architecture (Reuse-First)

This is designed to minimise custom build while remaining scalable.

🧱 Core Stack (Recommended)

✅ Backend-as-a-Service

Supabase

Provides:

  • PostgreSQL database
  • Authentication
  • Row-level security
  • Realtime messaging
  • File storage (profile photos)

✅ Frontend

Next.js (React)

  • Simple UI
  • Fast to iterate
  • Large ecosystem

✅ Hosting

  • Vercel (frontend)
  • Supabase (backend)

✅ Both support UK/EU hosting → GDPR alignment

🔌 Supporting Services

📍 Location

  • postcodes.io (UK-specific, free)

Used for:

  • postcode → coordinates
  • distance calculation

📧 Email

  • Resend or SendGrid

Used for:

  • verification emails
  • message notifications
  • feedback emails

📊 Admin / Reporting (MVP level)

  • Supabase dashboard (initially)
  • Optional: Metabase later

4. High-Level Architecture Diagram

graph TD
    U[Users] --> FE[Next.js Frontend]

    FE --> SB[Supabase Backend]

    SB --> DB[(Postgres DB)]
    SB --> AUTH[Auth]
    SB --> RT[Realtime Messaging]

    SB --> EMAIL[Email Service]
    SB --> MAP[Postcodes API]

    A[Admins] --> SB

5. Data Model (Simplified)

Core tables:

  • users

    • id
    • role (starter/helper)
    • email
    • display_name
    • postcode
    • lat/lng
    • gender

  • profiles

    • cycling ability
    • bike ownership
    • optional demographics

  • messages

    • sender_id
    • receiver_id
    • content
    • timestamp

  • matches (implicit via messaging)

  • feedback

    • user_id
    • buddy_id
    • outcome (yes/no/not yet)

6. Key Design Decisions (Future-Proofing)

✅ 1. Postgres-first model

  • supports:
    • reporting
    • scaling
    • migration if needed

✅ 2. Separation of concerns

  • frontend ≠ backend ≠ services
  • allows replacement of components later

✅ 3. Role-based structure from day one

  • enables:
    • instructor role later
    • partner dashboards later

✅ 4. Messaging stored structurally

  • enables:
    • analytics
    • moderation
    • future enhancements

✅ 5. Location stored as coordinates (not just postcode)

  • enables:
    • better matching
    • future geo features

7. Delivery Plan (Realistic for Volunteer)

Phase 0 – Setup (1 week)

  • Supabase project
  • Auth setup
  • Basic schema

Phase 1 – Core Build (2–4 weeks)

  • registration
  • profiles
  • helper search
  • messaging

Phase 2 – Admin + Feedback (1–2 weeks)

  • admin access
  • email notifications
  • feedback capture

Phase 3 – Pilot Launch (1–2 weeks)

  • limited user testing
  • bug fixing
  • UX improvements

⏱️ Total: ~4–8 weeks part-time

8. Risks & Mitigations

⚠️ Risk: Scope creep

Mitigation: Lock MVP scope strictly

⚠️ Risk: Messaging complexity

Mitigation: Use Supabase realtime (no custom infra)

⚠️ Risk: Data migration complexity

Mitigation: Defer full migration until after MVP

⚠️ Risk: Volunteer capacity

Mitigation: Deliver usable slices early

9. Future Roadmap (Post-MVP)

Once stable:

  • ✅ Badge filtering system
  • ✅ Instructor verification workflow
  • ✅ Automated engagement tracking
  • ✅ Advanced reporting dashboards
  • ✅ Partner organisation portals
  • ✅ Multi-affiliation system
  • ✅ Community group features
  • ✅ LCC membership integration

Graph View

Backlinks