Case study / PLAYGRND
A public football record built by four people.
PLAYGRND turns scattered amateur football data into a fast public record for matches, teams, players, standings, and scorers. Four HILLS Lab employees work on the product, including three engineers.
- Team
- 4 HILLS Lab employees
- Engineering
- 3 engineers
- Scope
- Product, data, backend, and operations
- Status
- In active development
The product
A useful record has to earn trust.
Amateur football data is fragmented across league websites, match reports, messages, and spreadsheets. The sources are useful for publishing a result, but they were not designed to become a long-lived product.
PLAYGRND keeps those records searchable and fast while leaving room for claims, corrections, organizer review, and a clear source behind every official change.
Three loops
The work is wider than the website.
Bring history in
Import uneven historical records, preserve the useful source data, resolve identities, and make every season recomputable.
Make public reads fast
Serve matches, standings, scorers, player histories, and global lists without repeating the same expensive aggregation on every request.
Control every write
Players claim profiles, organizers review competition data, and consequential changes remain permissioned and auditable.
AI-assisted delivery
Where AI changes the pace.
AI is part of the daily engineering workflow. It shortens the distance between a concrete product question and a tested change, especially when work crosses the web app, API, database, and operations.
Finding the right context
Repository rules, data contracts, earlier decisions, and current product behavior can be assembled before implementation starts.
Shipping bounded changes
Small features can move through implementation, tests, copy, documentation, and responsive QA as one coherent unit.
Checking the work
Queries, fallback paths, permission checks, build output, and mobile layouts are inspected against explicit acceptance criteria.
Closing the feedback loop
Real feedback from players and organizers can be traced to the relevant workflow and turned into a narrow product change quickly.
System shape
Built for public reads and careful changes.
SSR web
Core public journeys render on the server and remain usable without a heavy client runtime.
Private Go API
The public web is the exposed surface. Domain logic and write paths stay behind a private application boundary.
Postgres and Redis
Raw records remain the source of truth. Stable season aggregates and snapshots make repeated reads cheaper.
WhatsApp identity
Passwordless magic links meet users in a channel they already use, while permissions are checked again when an action runs.
Measured after the backfill
The expensive reads moved off the request path.
These are query-level measurements from the optimized data path, not a blanket page-speed claim. The largest gain is in aggregate-heavy and player-heavy reads.
Before and now
A small team can cover more of the product.
01
Before this generation of AI tools
Cross-stack work carried more lookup and coordination cost. A small team often had to choose between product changes, data cleanup, infrastructure, documentation, and QA, or accept a longer delivery cycle.
02
With an AI-assisted workflow
Much of the mechanical search, first-pass implementation, and repetitive checking is compressed. The engineers spend more time on the domain, trade-offs, review, and production consequences.
What this proves
Speed is useful when the system stays understandable.
PLAYGRND is the same kind of work we bring to client teams: a domain-heavy product, a real data model, public performance requirements, controlled operational paths, and continuous delivery shaped by user feedback.
Related engineering notes
HILLS Lab
Need someone to carry product, backend, and operations through to production?
We can start with one concrete workflow, map the risks and constraints, and ship a useful first change with your existing team.