Roadmap - Adrianhammer/Availably GitHub Wiki

Availably Roadmap πŸ—ΊοΈ

This roadmap outlines the major milestones, features, and priorities for Availably. Timelines are flexibleβ€”adjust based on your team’s pace.

Phase 0: Project Setup (1–2 weeks) βš™οΈ

Goals
β€’ Establish repo structure, CI, docs, and local dev environment
β€’ Validate end-to-end SignalR + EF Core β€œsmoke test”

Deliverables

  • βœ… GitHub repo with .github/ workflows and templates
  • πŸ“š docs/architecture.md, docs/github_workflow.md, docs/roadmap.md
  • 🐳 Docker Compose for API + PostgreSQL
  • πŸ”Œ Simple console/HTTP client that:
    • Connects to SignalR hub
    • Runs EF Core migrations

Phase 1: Core Backend & Data Model (2–3 weeks) πŸ› οΈ

Goals
β€’ Define and implement domain model, persistence, and core use cases

Features

  • πŸ“¦ Entities & relationships: Session, Participant, Availability
  • πŸ—„οΈ EF Core code-first migrations and PostgreSQL schema
  • 🎯 Application services / use-case layer
    • CreateSession(name) β†’ sessionId
    • GenerateParticipantLink(sessionId) β†’ token
    • RegisterParticipant(token) β†’ participantId
  • πŸ”— REST API for above use cases
  • ⚠️ Basic input validation and error handling

Phase 2: Real-Time Availability Flow (2–3 weeks) πŸš€

Goals
β€’ Enable clients to mark availability in real time

Features

  • πŸ”Œ SignalR hub:
    • JoinSession(sessionId)
    • ToggleAvailability(sessionId, participantId, date, isFree)
    • Broadcast AvailabilityUpdated event to group
  • πŸ’Ύ Persistence of each toggle in DB
  • πŸ“Š Service layer to aggregate β€œeveryone’s free dates” on the fly
  • πŸ§ͺ Unit tests for hub logic and aggregation service
  • πŸ› οΈ Manual validation via Postman or simple React-free client

Phase 3: Minimal Front-End (3–4 weeks) 🎨

Goals
β€’ Ship a basic Next.js/React UI for session interaction

Features

  • 🏠 Session creation page (host)
  • πŸ”— β€œJoin by link” page (participant)
  • πŸ“… Interactive calendar grid: click to mark busy/free
  • πŸ”— SignalR client integration:
    • Join session group
    • Send toggle requests
    • Listen for AvailabilityUpdated and update UI
  • 🎯 Display collective β€œall-free” dates highlight
  • πŸ“± Responsive and accessible layout (mobile first)

Phase 4: Host Controls & Polishing (3–4 weeks) πŸ–ŒοΈ

Goals
β€’ Equip hosts with management tools and improve UX

Features

  • πŸ“‹ Host dashboard:
    • List active sessions
    • View participants & their availability
    • Close or delete a session
  • βš™οΈ Session-level settings (e.g. date range limits)
  • ✨ UI/UX refinements (animations, color scheme, Tailwind CSS)
  • πŸ§ͺ Basic unit/integration tests for front-end components
  • πŸ€– End-to-end smoke test (UI ↔ API)

Phase 5: Hardening, CI/CD & Release (2–3 weeks) πŸ“¦

Goals
β€’ Production-ready deployment, monitoring, and quality gates

Features

  • πŸ€– GitHub Actions:
    • Build, lint, test on every PR
    • Deploy to Azure staging on merge to main
  • πŸ“ˆ Logging & monitoring:
    • Serilog + Azure Application Insights
    • Health check endpoints (/healthz)
  • πŸ‹ Docker image optimizations (distroless, multi-stage)
  • πŸ“ Draft v1.0.0 release notes & version tag

Phase 6: v1.1+ Extensions (Ongoing / V2) ✨

Goals
β€’ Add power-user features and deeper integrations

Candidate Features

  • πŸ”„ Recurring availability patterns (β€œevery Monday,” β€œweekends”)
  • πŸ“… Calendar integrations (Google Calendar, Outlook API)
  • πŸ” Authentication & user accounts (email link, OAuth)
  • πŸ•’ Time-zone handling for distributed teams
  • β™Ώ Accessibility audits (WCAG 2.1 AA)
  • πŸ”Ž Advanced filtering (date ranges, participant subsets)

Ongoing Practices πŸ”„

  • πŸ—“οΈ Weekly planning & retrospectives
  • πŸ“‹ Maintain prioritized backlog in GitHub Issues
  • πŸ“ Keep documentation (docs/) and Wiki in sync
  • πŸ›£οΈ Update roadmap every phase completion