Sealect
Management software for water sports schools, centres and rentals, with the marketplace where customers find and book them.
Sealect keeps bookings, calendar, staff, payments and rentals of a surf, sailing, kitesurf or diving school in one place. On the other side is the marketplace where people find an activity and book it, also from a widget inside the school's own website.
- My role
- Founder and sole developer: product, front end, back end and infrastructure.
- Who it is for
- Water sports schools, centres, clubs and rentals. And anyone who wants to book a session at sea without making a phone call.
The problem
A water sports school works with the weather, with limited places per session, instructors, rental gear and customers who book by phone, in person or online. Often all of this lives across spreadsheets, chats and a separate payment system, and every change of plan has to be redone by hand.
How I built it
I wrote Sealect on my own: the back end, the management app, the marketplace, the website and the infrastructure.
It is a monorepo with a REST API in Node.js and MongoDB, a worker for queues, emails and payments, three Next.js front ends and a status page written in Go. What holds for more than one app, such as the contracts between services, permissions and time zones, lives in shared packages with one rule: dependencies go in one direction only, and a test checks it.
The money path is the most protected one. Payments with Stripe, events processed on a queue, confirmations and refunds computed automatically from the rules of each offer. Every night an end-to-end test makes a complete booking against the staging environment, from payment to confirmation, with Stripe in test mode.
Recurring work, such as reminders, closures and syncs, runs on queues with a health check that verifies every expected job is actually registered. Sealect is also the first software connected to Goable, my other product, for the sea and weather conditions of each slot.
Technical choices
Contracts between services
API and worker talk through shared schemas, and the OpenAPI spec is generated from the same schemas that validate requests. Documentation and code don't drift apart.
The money path, tested every night
An end-to-end test goes through API, payment and worker against staging, with Stripe in test mode: the space that unit tests can't see.
Jobs that check themselves
Recurring work runs on Redis queues. A health check compares the expected jobs with the registered ones, so a job that stops running doesn't go unnoticed.
Backups and restore
Every night the database is exported to separate storage, kept for 30 days in production, and a monitor flags a missing night. The restore is written down in a runbook.
Two levels of monitoring
A status page written in Go checks API, payments and worker every minute and alerts when something breaks. School owners only see what affects them, the rest is for me. Sentry collects the errors of every app.
Infrastructure as code
Cloud account, DNS, service variables and CI configuration described in Terraform, with the plan checked in CI on every pull request.
In numbers
Counted on the product's source code.
- 7apps: API, worker, management app, marketplace, website, status page and backups
- 13shared packages
- 2,903test files across apps and packages
- 28recurring jobs on the queues
- 6status page checks on API, payments and worker
- 3languages: Italian, English and Spanish
- 2end-to-end scenarios run every night against staging
- 30days of nightly backups kept in production
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
