Marketplace Expansion Strategy

Purpose: Guide UX, architecture, and product decisions with future expansion in mind. Last Updated: January 2026 Status: Active

---

Overview

Juniro is building a marketplace for children's activities. This document outlines our phased expansion strategy to ensure early decisions don't block future growth.

Core Principle: Build for activities now, but architect for schools later.

---

Phase 1: Activities (Current)

Scope

Included	Examples
Individual Instructors	Piano teacher, soccer coach, tutor
Studios & Academies	Dance academy, coding bootcamp, art studio
Camps	Summer camps, sports camps, STEM camps
Franchise Education	Kumon, Eye Level, Mathnasium, Sylvan

Provider Types

├── Individual Instructor
└── Business / Studio

Characteristics

• Booking model: Session-based, class-based, drop-in
• Decision maker: Parent (direct)
• Sales motion: Self-serve signup
• Enrollment: Rolling / flexible start dates
• Compliance: Minimal (no student records)

What's NOT in Phase 1

• Traditional schools (K-12)
• Preschools / daycares with admissions
• Programs with academic year cycles
• Anything requiring admin approval workflows

---

Phase 2: Schools & Institutions (Future)

📚 Detailed Strategy: See Juniro Schools Product Strategy for the comprehensive India-first schools expansion plan.

Scope

Included	Examples
K-12 Schools	Private schools, charter schools
Preschools	With formal admissions process
Learning Institutions	Multi-program educational centers

Provider Type

├── Individual Instructor
├── Business / Studio
└── Institution / School  ← NEW

Characteristics

• Booking model: Admissions-based, term/semester cycles
• Decision maker: Parent + school admin
• Sales motion: Enterprise sales, contracts
• Enrollment: Application process, cohort-based
• Compliance: FERPA, student records, background checks

Schools Product Phases (India-First)

Phase	Focus	Key Features
Phase 1	Discovery + Trust	School profiles, search, reviews
Phase 2	Inquiry Layer	Lead forms, school dashboard
Phase 3	Fee Collection	Payments, receipts, GST
Phase 4	Platformization	Rosters, communication, SaaS

UX Implications

Schools will be a separate surface, not mixed into activity search:

Activities (Phase 1)	Schools (Phase 2)
"Find a class"	"Find a school"
Class cards	Program cards
Book Now	Apply / Inquire
Session times	Grade levels, terms
Price per class	Tuition / fees

Do NOT:

• Show schools in activity search results
• Use same card components for both
• Mix booking flows

DO:

• Create separate "Schools" or "Programs" section
• Different filters (grades, curriculum, etc.)
• Different CTAs (Apply vs Book)

---

Architecture Principles

These principles ensure Phase 1 decisions don't block Phase 2.

1. Provider Type as Extensible Enum

type ProviderType =
  | 'individual'      // Phase 1
  | 'business'        // Phase 1
  | 'institution'     // Phase 2 (future)

Don't hardcode assumptions about provider types.

2. Offerings, Not Just Classes

Think in terms of Offerings that can be:

Phase 1	Phase 2
Class	Program
Session	Term
Workshop	Course
Camp	Academic Year

Data model hint:

interface Offering {
  id: string
  providerId: string
  type: 'class' | 'session' | 'camp' | 'program' | 'course'  // extensible
  enrollmentType: 'booking' | 'application'  // Phase 2 adds 'application'
  // ...
}

3. Flexible Enrollment Flows

Phase 1: Search → View → Book → Confirm Phase 2: Search → View → Apply → Review → Accept/Decline

Build booking flow as one implementation of enrollment, not THE enrollment.

4. Provider Profiles Are Reusable

The provider profile pattern works for both:

• Business/Studio profile → shows classes
• Institution profile → shows programs

Same structure, different content types.

5. Reviews & Trust Apply to Both

Review system should be provider-agnostic:

• Review a piano teacher ✓
• Review a dance academy ✓
• Review a school ✓ (future)

---

Signals to Enter Phase 2

Don't add schools until:

Signal	Threshold
Activity provider liquidity	100+ active providers per market
Booking volume	Consistent repeat bookings
Inbound demand	Schools asking to join
Team capacity	Dedicated enterprise/sales resource
Compliance readiness	Legal review of school data requirements

Leading indicators:

• Parents asking "do you have schools?"
• Franchise education centers asking for multi-location tools
• Providers with "academy" or "school" in name signing up

---

Decision Log

Date	Decision	Rationale
Jan 2026	Phase 1 = Activities only	Focus, faster liquidity
Jan 2026	Franchise education in Phase 1	Operates like studios, not schools
Jan 2026	Schools = separate UX surface	Different mental model, don't pollute search

---

References

• Product Roadmap
• PLG Strategy

---

Open Questions (Future)

• Should "Programs" be a middle tier between Activities and Schools?
• How to handle after-school programs run BY schools but open to external students?
• Multi-location management for franchises — feature tier or provider type?