Sealect
Il gestionale per scuole, centri e noleggi di sport acquatici, con il marketplace dove i clienti li trovano e prenotano.
Sealect tiene in un posto solo prenotazioni, calendario, staff, pagamenti e noleggi di una scuola di surf, vela, kitesurf o sub. Dall'altra parte c'è il marketplace dove le persone trovano un'attività e la prenotano, anche da un widget dentro il sito della scuola.
- Il mio ruolo
- Fondatore e unico sviluppatore: prodotto, front end, back end e infrastruttura.
- Per chi è
- Scuole, centri, circoli e noleggi di sport acquatici. E chi vuole prenotare un'uscita in mare senza telefonare.
Il problema
Una scuola di sport acquatici lavora con il meteo, con posti limitati per ogni uscita, istruttori, attrezzatura a noleggio e clienti che prenotano al telefono, di persona o online. Spesso tutto questo vive tra fogli di calcolo, chat e un sistema di pagamento a parte, e ogni cambio di programma va rifatto a mano.
Come l'ho costruito
Ho scritto Sealect da solo: il back end, il gestionale, il marketplace, il sito e l'infrastruttura.
È un monorepo con un'API REST in Node.js e MongoDB, un worker per code, email e pagamenti, tre front end in Next.js e una pagina di stato scritta in Go. Quello che vale per più app, come i contratti tra i servizi, i permessi e i fusi orari, sta in pacchetti condivisi con una regola: le dipendenze vanno in una direzione sola, e un test lo verifica.
Il percorso dei soldi è quello più protetto. Pagamenti con Stripe, eventi elaborati in coda, conferme e rimborsi calcolati in automatico secondo le regole della singola offerta. Ogni notte un test end to end fa una prenotazione completa contro l'ambiente di staging, dal pagamento alla conferma, con Stripe in modalità test.
Il lavoro ricorrente, come promemoria, chiusure e sincronizzazioni, gira su code con un controllo di salute che verifica che ogni job atteso sia davvero registrato. Sealect è anche il primo software collegato a Goable, l'altro mio prodotto, per le condizioni meteo-marine degli slot.
Scelte tecniche
Contratti tra i servizi
API e worker si parlano attraverso schemi condivisi, e la specifica OpenAPI è generata dagli stessi schemi che validano le richieste. Documentazione e codice non si separano.
Il percorso dei soldi, testato ogni notte
Un test end to end attraversa API, pagamento e worker contro staging, con Stripe in modalità test: è lo spazio che i test unitari non vedono.
Job che si controllano da soli
I lavori ricorrenti girano su code Redis. Un controllo di salute confronta quelli attesi con quelli registrati, così un job che smette di girare non passa inosservato.
Backup e ripristino
Ogni notte il database viene esportato su uno storage separato, con 30 giorni di conservazione in produzione, e un monitor segnala la notte che manca. Il ripristino è scritto in un runbook.
Monitoraggio a due livelli
Una pagina di stato in Go controlla API, pagamenti e worker ogni minuto e avvisa quando qualcosa si rompe. Ai titolari arriva solo quello che li tocca, il resto lo vedo io. Sentry raccoglie gli errori di tutte le app.
Infrastruttura come codice
Account cloud, DNS, variabili dei servizi e configurazione della CI descritti in Terraform, con il piano controllato in CI a ogni pull request.
In numeri
Contati sul codice sorgente del prodotto.
- 7app: API, worker, gestionale, marketplace, sito, pagina di stato e backup
- 13pacchetti condivisi
- 2.903file di test su app e pacchetti
- 28job ricorrenti sulle code
- 6controlli della pagina di stato su API, pagamenti e worker
- 3lingue: italiano, inglese e spagnolo
- 2scenari end to end eseguiti ogni notte contro staging
- 30giorni di backup notturni conservati in produzione
Stack
- TypeScript
- Node.js
- Express
- MongoDB
- Redis
- BullMQ
- Zod
- OpenAPI
- Next.js
- React
- Tailwind CSS
- TanStack Query
- next-intl
- Stripe
- Resend
- Go
- Railway
- Vercel
- AWS S3
- Terraform
- Sentry
- GitHub Actions
- Vitest
- Playwright
- Turborepo
