Sportly — Documento di Progetto
01 — Business Plan Preliminare
Il business plan preliminare di Sportly delinea la visione strategica, il modello operativo e le proiezioni finanziarie per i primi 24 mesi. L'obiettivo è dimostrare la sostenibilità economica del progetto e la sua capacità di scalare progressivamente su base geografica.
| Voce | Mese 6 | Mese 12 | Mese 18 | Mese 24 |
|---|---|---|---|---|
| Commissioni prenotazioni | 1.500 € | 7.500 € | 16.000 € | 32.000 € |
| SaaS strutture (Standard + Premium) | 1.460 € | 4.090 € | 9.500 € | 18.000 € |
| Pubblicità ed eventi | 200 € | 1.000 € | 3.000 € | 7.000 € |
| Totale Ricavi Mensili | 3.160 € | 12.590 € | 28.500 € | 57.000 € |
| Costi Operativi Stimati | 8.000 € | 12.000 € | 18.000 € | 22.000 € |
| Margine Operativo | −4.840 € | +590 € | +10.500 € | +35.000 € |
Il break-even operativo è stimato tra il mese 12 e il mese 18, compatibile con un investimento iniziale di avvio compreso tra 50.000 e 80.000 euro (sviluppo + marketing). Lo scenario presentato è conservativo: ipotizza una crescita graduale senza picchi di viralità.
02 — Analisi SWOT
L'analisi SWOT di Sportly mappa i fattori interni (punti di forza e debolezze) e i fattori esterni (opportunità e minacce) che influenzano le probabilità di successo del progetto. Ogni quadrante include azioni strategiche concrete per massimizzare i vantaggi e mitigare i rischi.
| Strategia | Quadranti | Azione Concreta | Priorità |
|---|---|---|---|
| SO — Sfrutta forze su opportunità | S3 + O1 | Lanciare community in città con alta densità di ASD non digitali (Milano, Bologna) | Alta |
| WO — Riduci debolezze con opportunità | W4 + O5 | Partnership CONI per onboarding strutture — risolve chicken-egg con canale istituzionale | Alta |
| ST — Usa forze per neutralizzare minacce | S1 + T1 | Posizionare la multi-disciplina come moat vs Playtomic specializzato solo su racket | Media |
| WT — Limita esposizione ai rischi | W3 + T3 | Integrare secondo gateway (Satispay) per ridurre dipendenza da Stripe | Bassa |
03 — Marketing Mix (4P)
Il marketing mix di Sportly è strutturato sulle quattro leve classiche adattate alla realtà di una startup digitale B2B2C. La strategia privilegia la crescita organica e il passaparola nelle fasi iniziali, supportata da un posizionamento di prezzo accessibile che riduce la resistenza all'adozione sia degli utenti che delle strutture.
La strategia marketing privilegia il canale digitale geolocalizzato nelle fasi early per massimizzare la densità locale — è meglio avere 200 utenti concentrati a Milano che 2.000 sparsi in Italia. La densità locale crea l'effetto rete che rende la piattaforma utile.
04 — Diagramma di Gantt
Il diagramma di Gantt pianifica le 24 settimane operative del progetto Sportly, dalla fase di analisi al lancio ufficiale sugli store. Le fasi sono parzialmente sovrapposte per ottimizzare il time-to-market mantenendo la qualità. I milestones principali sono evidenziati in corrispondenza delle scadenze di consegna scolastica e degli obiettivi tecnici.
05 — Mockup Interfacce Software
I mockup seguenti rappresentano i flussi principali dell'app mobile Sportly: home page di ricerca, schermata di prenotazione con calendario, e dashboard analytics per i gestori. Il design system privilegia la semplicità operativa — un utente deve poter prenotare in meno di 4 tap dal momento in cui apre l'app.
05 — Mockup Interfacce Software (cont.)
Il portale web per i gestori delle strutture sportive è progettato per essere leggibile a colpo d'occhio. La dashboard principale aggrega i KPI operativi più rilevanti — tasso di occupazione, prenotazioni del giorno, ricavi del mese — in un layout a card che non richiede formazione specifica per essere utilizzato.
06 — Schema Database
Il modello dati di Sportly è progettato su PostgreSQL con architettura relazionale normalizzata (3NF). Il database gestisce le entità principali — utenti, strutture, risorse prenotabili, prenotazioni, pagamenti, community — con chiavi esterne per garantire l'integrità referenziale e indici ottimizzati per le query più frequenti.
06 — Schema Database (cont.)
| Scelta Tecnica | Motivazione |
|---|---|
| UUID come PK (vs integer auto-increment) | Evita enumerazione delle risorse via URL, compatibile con architettura distribuita multi-region |
| ENUM per campi stato | Garantisce coerenza dei dati a livello di database, evita valori non validi anche senza validazione applicativa |
| DECIMAL(8,2) per prezzi | Precisione monetaria garantita, evita errori di arrotondamento tipici del tipo FLOAT |
| Indici su city, sport_type, booking_date, status | Le query più frequenti (ricerca strutture per città, filtraggio per sport, slot disponibili) risultano O(log n) |
| Soft delete con is_active = false | Preserva lo storico prenotazioni e pagamenti anche dopo disattivazione di risorse o venue |
| Separazione payments da bookings | Permette rimborsi parziali, gestione multi-pagamento e audit finanziario indipendente dalla logica prenotazioni |
06 — Architettura del Sistema
L'architettura di Sportly è progettata secondo i principi del cloud-native development: stateless, containerizzata, scalabile orizzontalmente e resistente ai guasti. Il sistema è suddiviso in layer funzionali indipendenti che comunicano tramite API RESTful e code di messaggi asincroni.