Public web
SvelteKit SSR with Croatian-first content and an English toggle
In Build
PLAYGRND
I am building PLAYGRND to give amateur footballers and organizers a credible public record: competitions, matches, teams, player profiles, honors, claims, and corrections in one fast, shareable product.
GoPostgresRedisSvelteKitWhatsAppHetzner
Founder-built product case study
The product bet
Local amateur football history exists, but it is fragmented across league sites, spreadsheets, social posts, and private organizer knowledge. The first job is not adding another social feed. It is turning that history into a trustworthy public record, then creating a controlled path for players and organizers to improve it.
- Role
- Founder and hands-on engineer
- Period
- 2025 - Present
- Stage
- Live product, active development
Product loop
From public record to trusted input
- 01Publish fast, searchable league history with shareable player, team, match, and season pages.
- 02Let players claim an existing profile through a channel they already use, without weakening identity checks.
- 03Route claims and corrections through scoped admin review before they change the public record.
- 04Use organizer workflows and real season feedback to decide what deserves to become native product functionality.
System shape
Simple boundaries, explicit sources of truth
Application API
Private Go service reached over local sockets, with public writes kept behind the web layer
Source of truth
PostgreSQL for imported records, claims, identity, audit state, and deterministic aggregates
Hot reads
Redis snapshots for stable and short-lived public data, with PostgreSQL fallback
Identity and claims
WhatsApp magic links, short claim codes, pending profiles, and guarded approval flows
Operations
Hetzner releases, health checks, recompute tooling, backups, and documented rollback paths
Engineering judgment
Decisions that keep the product legible
Trust before creation
The product starts from explainable imported history. New write surfaces are added only when they close a real claim, correction, or organizer loop.
SSR-first public reads
Player and league pages should be fast, indexable, and useful when shared. The private API remains an implementation boundary rather than a public contract.
Recomputable derived data
Finished-season standings, scorers, and player statistics can be rebuilt transactionally from source records instead of becoming cache-shaped truth.
WhatsApp as a user channel
Login and claims meet local users in a familiar channel, while raw webhook storage, credentials, admin actions, and official record changes stay deliberately constrained.
Current proof
What is already delivered
- Public league, match, team, player, standings, scorers, honors, search, and share flows
- Croatian-first SSR product with responsive mobile search and profile discovery
- WhatsApp magic-link login, pending-profile onboarding, profile claims, and admin review foundation
- Persisted season aggregates, Redis hot-read snapshots, explicit recompute commands, and raw-data fallbacks
- Operational tooling for deployment, health checks, backups, cache warming, derived-data audits, and rollback
Next proof
The next proof is operational rather than cosmetic: harden real-phone claim flows, run the product with active competition organizers, and use that feedback to shape result entry, corrections, and recurring organizer workflows.