PLAYGRND is being built as a public record for local and amateur football: matches, tables, scorers, teams, players, venues, tournaments, and history that remains useful after a season ends.
Four HILLS Lab employees are on the project, three of them engineers. That is a small team for a product that already has real surface area: a public web app, two languages, live data, player and team profiles, profile claiming, admin foundations, search, match pages, league pages, and a dedicated organizer surface.
The interesting part is not only what is being built. It is how quickly the loop closes from idea to page, verification, and deployment.
What is already visible
PLAYGRND is not just a landing page.
The public product already covers:
- 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 a “Claim profile” entry
- 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 about page states the core idea clearly: amateur football deserves a better public record. The organizer page takes that further: a league or tournament should not lose its story inside spreadsheets, chats, and half-manual archives.
For organizers, the direction is specific:
- fixtures, results, standings, scorers, and lineups in one place
- team and player profiles connected across seasons
- public competition history that stays useful after the season ends
- result and match-sheet input through familiar channels such as WhatsApp, with AI preparing the update for human confirmation
That last point is deliberately careful. AI should not directly rewrite an official table because it understood a message. The better workflow is: AI prepares, the system shows what it understood, a person confirms, and the change remains visible and traceable.
What AI changes
Before AI, this kind of product would usually move more slowly and more rigidly.
First the data model would be refined for weeks. Then imports. Then public pages. Then auth. Then admin. Then bilingual copy. Then the bug list would pull everything back into another round.
That is not a caricature. It is how a lot of real software was built: long waits between phases, too much manual translation between product notes and code, and many small decisions deferred because every change was expensive.
AI changes the rhythm.
Not because AI “builds the product by itself.” It does not. But it compresses small cycles:
- turning a product note into a route, component, or copy draft
- comparing existing code with a new requirement
- drafting migrations, handlers, SSR loads, and tests
- localizing interface copy in Croatian and English
- reading logs, edge cases, errors, and regressions faster
- documenting why a decision was made
Before AI, much of that energy went into mechanical work. With AI, more of it can stay focused on the question that matters: is this the right product loop?
Architecture that keeps pace
PLAYGRND is intentionally built as a fast, server-rendered product. 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, and public images/assets are served through object storage.
That setup matters because it helps the product stay fast while new surfaces are added.
- public pages are fast and indexable
- Croatian and English are part of the same system, not an afterthought
- public reads are separated from private write/admin flows
- profile claiming and corrections are built around verification, not uncontrolled writes
- WhatsApp is treated as a practical operating channel, while the official sports record still needs confirmation and traceability
In other words, the technical choices are not separate from the product decisions. If the public record needs to be fast, reliable, and correctable, the architecture has to support exactly that: low-friction reading, verified writing, and a clear enough trail when something changes.
Why this matters for HILLS Lab
PLAYGRND is not only a sports product. For us, it is also a practical example of the working style we expect to become normal for software teams.
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 security boundaries are
- which parts are public and which are private
- what AI is allowed to suggest but not change directly
- how a change is tested before deployment
That is the same pattern behind our work on context infrastructure for AI-assisted engineering. Speed is not just more generated 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 genuinely reduce work for organizers.
In the pre-AI era, this scope would have meant much more waiting for a small team. In the AI era, it can mean something else: more iterations, more product evidence, and more time spent on decisions that actually need people.