How One Founder Builds a Live Sports Platform Without a Database Team

Gabriel Gil Graña is building Xeito, a live sports platform, without turning database infrastructure into the work.

Xeito started as a small script for coordinating squash matches in Malta. Less than a year later, Gabriel Gil Graña is building a live sports platform for clubs, teams, and players.

The product already handles leagues, match results, standings, payments, player workflows, and live scoring. During league nights, referees submit points from the court while players watch the standings change.

That is a serious data product. But Xeito does not have a database team behind it. Gabriel is keeping the product moving by letting Prisma handle the defaults that would otherwise eat his build time.

That is the core of the story: Xeito needs a real data layer, but Gabriel's attention belongs on the product.

What Xeito is building

Xeito helps racket-sports communities manage the work around a match: availability, rosters, leagues, scores, standings, registrations, payments, and events.

In the demo, it already looked far beyond a scheduling tool.

The live referee workflow is the technical proof point. Xeito sends many queries that need fast responses while players are watching the standings update.

For a small team, that matters. Sports software looks simple from the outside, but the data model keeps growing: clubs, players, teams, rosters, calendars, lineups, matches, points, standings, payments, notifications, and live streams.

Why Prisma

Gabriel had used Prisma professionally before, but Xeito was the first time he used Prisma for the data layer in one of his own products.

The deciding factor was not a long checklist. It was the way Prisma keeps the data model visible, explicit, and connected to the application.

With Prisma ORM, the schema becomes the place where Gabriel defines how the product works. The model translates into migrations, and the generated client keeps application code strongly typed as the product changes.

That matters because Xeito keeps expanding. A tournament workflow adds registrations and schedules. A live scoring workflow adds points and standings. AI coaching will add match analysis, statistics, heat maps, and recommendations.

Prisma Postgres gives Gabriel a managed path for the database layer, while Prisma ORM keeps the model close to the code. The combination lets him spend more time on Xeito and less time managing database operations by hand.

The stack

Xeito runs on a simple, modern stack:

• App: Next.js on Vercel
• Data access: Prisma ORM
• Database: Prisma Postgres
• Prisma's role: Keep schema, migrations, typed queries, pooling, backups, and database defaults off the critical path

That last part is the value. The database is still critical, but it does not become the work Gabriel has to sell to users.

How the data layer works

The technical challenge in Xeito is not just storing users and matches. It is keeping a fast-moving sports domain consistent while the product keeps adding new workflows.

A league night touches many parts of the model at once:

• referees submit points from the court
• matches update game and point state
• team standings change as results come in
• captains check rosters and availability
• clubs publish events, registrations, schedules, and payments
• players follow the results from their dashboard

That makes the schema important product surface area. When Gabriel adds a workflow such as tournament registrations or live referee scoring, he is not only adding UI. He is changing the relationships between clubs, players, teams, matches, points, standings, payments, and events.

Prisma gives him one place to make those relationships explicit. He models the data in the Prisma schema, turns schema changes into migrations, and uses the generated Prisma Client to keep queries typed in the Next.js application.

That matters when the product grows quickly. A live referee panel can send many reads and writes while players are watching the table move. A tournament workflow can add registrations, brackets, venue screens, court calls, organizer controls, and notifications. Future AI coaching will introduce match events, statistics, heat maps, and recommendations.

Each new feature expands the model. Prisma keeps that expansion close to the code path where Gabriel is already working, instead of splitting it across hand-written SQL, migration scripts, generated types, and infrastructure configuration.

There is still engineering judgment involved. Gabriel mentioned that schema changes across development, preview, staging, and production require understanding how migrations work and how to recover when something unexpected happens. But that is a smaller surface area than running the full database platform himself.

For Xeito, the practical loop is:

1. model the new sports workflow in the Prisma schema
2. generate and review the migration
3. use the typed client in the Next.js feature
4. deploy without spending the release cycle tuning database infrastructure

That is what keeps the article from being only a story about defaults. Prisma is not hiding the data layer from Gabriel. It is making the right parts explicit, typed, and close to the product code, while the operational defaults stay handled in the background.

What comes next for Xeito

Next comes tournament software: brackets, schedules, venue screens, organizer controls, and notifications. After that comes AI coaching: match analysis, player statistics, heat maps, and recommendations.

Both depend on the same thing: a data layer that stays easy to change as the product gets more ambitious.

Build the product, not the database team

Xeito is a good reminder that "small team" does not have to mean "small product."

For Gabriel, the priority is clear: work on features, make the product better for players and clubs, and let Prisma handle the database defaults every serious product needs.

That is the platform promise Prisma should make to builders: make me successful by default, keep the escape hatches visible, and let me keep building.

Building a data-heavy product with a small team?

Start with Prisma ORM and Prisma Postgres. If you want the app and database in one Prisma project, explore Prisma Compute. If you want to see where Prisma's type-safe data layer is heading next, try Prisma Next.