PLAYGRND is becoming a public record for local and amateur football: matches, tables, scorers, teams, players, venues, tournaments, and the history that usually disappears after a season ends.
There are four of us from HILLS Lab working on it, three engineers included. That is a small team for a product that already has a real surface area: public pages, two languages, live data, player and team profiles, profile claiming, admin foundations, search, match pages, league pages, and a dedicated organizer direction.
The interesting part for me is not only what is being built. It is how quickly the loop closes from idea to implementation, verification, and deployment.
It is already more than a landing page
PLAYGRND already has the shape of a product, not a brochure.
- a home dashboard with results, activity, tables, scorers, and featured players
- league and season pages with standings, scorers, matches, rounds, and season switching
- match pages with results, linked teams, goals, lineups, and a correction entry point
- player profiles with seasons, appearances, goals, trophies, sharing, and profile claiming
- team profiles with seasons, players, matches, standings, and honors
- search with suggestions, recent searches, and popular results
- venue, organization, about, status, legal, and privacy pages
The idea is simple: amateur football deserves a better public record. For organizers, the bigger promise is that a league or tournament should not lose its story inside spreadsheets, chats, and half-manual archives.
The product direction is not abstract. I want schedules, results, standings, scorers, lineups, team profiles, player profiles, and competition history to live in one place. I also want familiar input channels, like WhatsApp, to reduce organizer work without letting unverified AI updates rewrite the official record.
What AI changes
Before AI, this kind of product would usually move in heavier phases.
First the data model. Then imports. Then public pages. Then auth. Then admin. Then bilingual copy. Then a bug list that sends everyone back into another round.
That is not a joke. That is how many real products get built: a lot of waiting between phases, a lot of manual translation from product notes into code, and many small decisions deferred because every change is expensive.
AI changes the rhythm.
Not because AI builds the product by itself. It does not. But it compresses the small loops:
- turning a product note into a route, component, or copy draft
- comparing a new request with the existing codebase
- drafting migrations, handlers, SSR loads, and tests
- localizing copy in Croatian and English
- reading logs, errors, edge cases, and regressions faster
- capturing why a decision was made
Before AI, a lot of that energy would have gone into mechanical work. With AI, more of it can stay on the product question: is this the right loop for the user?
The architecture has to keep up
PLAYGRND is intentionally server-rendered. The public web app is SSR. The backend is a separate Go service behind the web layer. The data is relational. Cache is used for expensive and repeated reads. Public assets live in object storage.
That setup matters because it lets the product stay fast while the surface area grows.
- public pages are fast and indexable
- Croatian and English are part of the product, not an afterthought
- public reads are separated from private write/admin flows
- profile claims and corrections are built around verification
- WhatsApp can be an operating channel without becoming the source of truth
The technical choices and product choices are not separate here. If the public record needs to be fast, reliable, and correctable, the architecture has to support low-friction reading, verified writing, and a clear enough trail when something changes.
The part I care about most
PLAYGRND is also a test case for the way I think software teams will work with AI.
A small team can build a wider product when it has a strong context layer:
- what already exists
- which decisions are still current
- where the safety boundaries are
- which parts are public and which are private
- what AI can suggest but not change directly
- how a change is tested before deployment
That is the same reason I keep writing about context infrastructure for AI-assisted software work. Speed is not just generating more code. Speed comes from keeping context reliable while the product changes quickly.
PLAYGRND is still being built. Organizer tools are not final. Claim and correction loops still need more hardening. But the direction is clear: a fast public sports record first, then workflows that reduce real organizer work.
In the pre-AI era, this scope would have meant much more waiting for a small team. In the AI era, it can mean more iterations, more product evidence, and more time left for decisions that actually need people.