feat: flatten routes and merge marketing and onboarding directories

2026-06-06 18:52:03 -07:00
parent 47417d13a0
commit 0480b306f1
139 changed files with 36409 additions and 229 deletions
--- a/prd-template/open-source-and-api-references.md
+++ b/prd-template/open-source-and-api-references.md
@@ -0,0 +1,239 @@
+# Open-Source and API References for CampMatch + CampReg
+
+**Version:** 0.1  
+**Date:** 2026-06-01
+
+---
+
+## 1. Purpose
+
+This document collects useful reference products, APIs, and open-source projects that can inform CampMatch + CampReg product design.
+
+These are not recommended as direct forks unless reviewed technically and legally. They are references for workflows, architecture, data models, feature expectations, and integration strategy.
+
+---
+
+## 2. Camp Management API References
+
+## 2.1 CampMinder API
+
+CampMinder publicly positions its API as a way to connect camp data with external tools including marketing platforms, Salesforce, Zapier, Google Sheets, dashboards, and accounting/reporting workflows.
+
+Useful lessons for CampReg:
+
+- API-driven data syncing is valuable to camps.
+- Marketing integration is a major API use case.
+- Status changes should sync to outreach tools.
+- Financial data and staff/session data matter.
+- API support can be a services-led product, but CampReg can differentiate by making API access more self-serve.
+
+References:
+
+- https://campminder.com/features/api/
+- https://campminder.com/features/api-services/
+- https://help.campminder.com/en/articles/6988427-get-to-know-campminder-api
+
+## 2.2 CampSite API
+
+CampSite publicly documents REST API support for multiple camp domains.
+
+Supported public areas include:
+
+- Families
+- Campers
+- Staff
+- Groups
+- Guests
+- Donors
+- Medical
+- Advanced reports
+- Financial transactions
+- Enrollment
+- Custom fields
+- Bunking boards
+- Bunking assignments
+- Transportation
+
+Useful lessons for CampReg:
+
+- A serious camp API needs broad operational coverage.
+- Enrollment, financial, medical, bunking, and transportation are important data domains.
+- CampReg should add webhooks so external systems do not need to poll.
+- API docs should be accessible through a developer portal.
+
+References:
+
+- https://support.campmanagement.com/hc/en-us/articles/6375219096205-What-can-we-do-with-CampSite-s-API
+- https://support.campmanagement.com/hc/en-us/articles/4405656076557-Does-CampSite-integrate-with-any-third-party-softwares-e-g-QuickBooks
+
+## 2.3 ACTIVE Network Activity API
+
+ACTIVE’s public Activity API exposes searchable public activity data including youth camps, but it is read-only.
+
+Useful lessons for CampMatch:
+
+- Marketplace/search data can be modeled as public activity assets.
+- Public discovery APIs are distinct from operational provider APIs.
+- Read-only APIs support distribution but not provider operations.
+
+Reference:
+
+- https://developer.active.com/docs/read/Activity_APIs
+
+---
+
+## 3. Open-Source References
+
+## 3.1 eCamp v3
+
+Type: Camp planning software  
+Relevant to: Camp planning, activity scheduling, responsive planning, printable plans  
+Not relevant to: Registration/payments as core system
+
+Useful lessons:
+
+- Camp-specific planning workflows matter.
+- Responsive/mobile planning matters.
+- Printable camp plans remain important in the real world.
+- Activity planning can become a future CampReg module.
+
+References:
+
+- https://www.ecamp3.ch/en/
+- https://github.com/ecamp/ecamp3
+
+## 3.2 Hi.Events
+
+Type: Open-source event ticketing and management platform  
+Relevant to: Registration, ticketing, checkout, analytics, add-ons, webhooks, self-hosting
+
+Useful lessons:
+
+- Event/session sales can be modeled cleanly.
+- Promo codes, product add-ons, offline payments, invoicing, and exports are useful patterns.
+- Webhooks are important for ecosystem integrations.
+- Self-hosted/event infrastructure offers useful deployment and developer-experience references.
+
+References:
+
+- https://github.com/HiEventsDev/Hi.Events
+- https://hi.events
+
+## 3.3 Attendize
+
+Type: Open-source event registration/ticketing platform  
+Relevant to: Checkout, custom questions, attendee management, messaging, QR check-in, affiliate tracking
+
+Useful lessons:
+
+- Custom questions during checkout map to CampReg registration forms.
+- QR/browser-based check-in concepts are useful for staff mobile workflows.
+- Messaging by attendee/ticket type maps to provider session messaging.
+- Affiliate/source tracking maps to CampMatch attribution.
+
+Reference:
+
+- https://github.com/Attendize/Attendize
+
+## 3.4 Youth/Student Attendance Projects
+
+There are smaller open-source attendance/student projects that may provide lightweight ideas for rosters, attendance, and check-in. These should be inspected selectively, but CampReg should not rely on them for core architecture because camp requirements around parents, payments, child safety, pickup authorization, and provider operations are more complex.
+
+---
+
+## 4. Competitor Feature References
+
+## 4.1 Campium
+
+Relevant features observed:
+
+- Registration and forms
+- Billing and payments
+- Attendance
+- Medication tracking
+- Communication
+- Parent portal
+- Mobile app references
+- Reporting and analytics
+- Canteen/store
+- Staff scheduling
+
+Useful lessons:
+
+- Camp management buyers expect broad operational coverage.
+- Medication tracking and parent portal are serious buying factors.
+- Canteen/store and mobile app can become advanced differentiators.
+- Analytics such as year-over-year registration and revenue comparisons are valuable.
+
+Reference:
+
+- https://campium.com/features/
+- https://campium.com/features/medication-tracking/
+- https://campium.com/features/canteen
+
+---
+
+## 5. Product Design Implications
+
+CampMatch + CampReg should adopt the best ideas from the reference landscape:
+
+From CampMinder:
+
+- API-connected marketing and data automation
+
+From CampSite:
+
+- Broad operational REST API coverage
+
+From ACTIVE:
+
+- Public activity/discovery data model
+
+From eCamp:
+
+- Camp planning and schedule orientation
+
+From Hi.Events:
+
+- Modern event/ticketing checkout and webhooks
+
+From Attendize:
+
+- Custom questions, messaging, QR check-in, affiliate/source tracking
+
+From Campium:
+
+- Full camp management feature breadth
+
+---
+
+## 6. CampReg Differentiation
+
+CampReg should not simply clone incumbent camp software.
+
+Differentiators:
+
+- Direct CampMatch marketplace demand
+- Kid-centered matching
+- Parent-first mobile registration
+- Provider operating system
+- API-first architecture
+- Webhooks from the beginning
+- VibnAI growth automation
+- Missinglettr campaign execution
+- Marketplace attribution
+- Underfilled session automation
+- Local SEO and content generation
+
+---
+
+## 7. Legal and Licensing Caution
+
+Open-source references must be reviewed before reuse.
+
+Important considerations:
+
+- AGPL projects may impose obligations if code is reused or hosted as network software.
+- Some projects may be useful for learning but not safe to copy.
+- Product concepts are safer to reference than source code.
+- Legal review is required before incorporating any third-party code.