Football Statistics Website from PostgreSQL Database

I have a complete, clean PostgreSQL database of a football club's entire match history — 120 years, roughly 6,900 matches, with lineups, goals, cards, players, managers, referees and venues. **The data work is finished.** I need a developer to build the website on top of it.

There is a full written specification and a technical appendix documenting every table and data convention. Both go to shortlisted bidders. This is a well-defined build, not a discovery project.

### What exists already

- A PostgreSQL 17 dump (~10 MB, 35 tables) that restores cleanly, with a documented schema
- A working read-only reference viewer you can browse: **https://chelsea-data-viewer.vercel.app/**
- A ~15-page specification covering every page, every form, colours, and an acceptance checklist
- A technical appendix covering data conventions, edge cases and known quirks

### What I need built

**1. A public statistics site** — fast, and fully usable on desktop, tablet and phone. No login for visitors:

- Match pages: full lineups, substitutions, scorers, cards, referee, attendance, half-time score, cup round, league position
- Player profiles with career records, transfers, and a per-opponent breakdown
- Season summaries, league tables, all-time records, head-to-head pages, sequences and streaks
- An all-time league table that can be shown **as it stood on any past date** back to 1992
- Supporting pages: managers, referees, penalties, trophies, birthdays, and a fully sortable current-squad table

**2. A private admin area** — used by one non-technical person:

- A form to enter a new match in 10–15 minutes: lineups with autocomplete, subs, goals, penalties, cards, attendance
- Forms for everything else the owner enters occasionally: manager changes, new players, transfers and departures, deaths, trophies, and other clubs' league results
- Corrections: edit a match and **every** dependent total, table and sequence recalculates automatically
- A one-click "download full backup" button

**3. A natural-language question box** — visitors type a plain-English question and get an answer.

**Critical requirement:** it must work by translating the question into a real query against the database and reporting only what that query returns. It must never answer from the model's general knowledge. The results page has to show the underlying data, not just a sentence. Wrong-but-confident answers are a failed deliverable. It also ships with a hard monthly spending cap and per-visitor rate limiting.

### Key technical points

- **All statistics are computed from match records at query or build time. Nothing is cached as a stored total.** The correction workflow depends on it.
- **Season is a stored, editable field on each match**, defaulted from the match date but correctable by hand. Two documented cases in the data break the date rule and the spec explains both. Do not derive the season at query time.
- Two supplied HTML datasets need importing — one is ~12,800 historical league results across 33 seasons (malformed markup, windows-1252, documented in the appendix), the other is a 37-item honours list.
- Authentication must use an established off-the-shelf library. Do not build your own.
- **The layout must work on desktop, tablet and phone.** Desktop is where the dense tables are read; phones are where most traffic will come from. Both are firm requirements, and both apply to **every page and every table, including pages added later in the build** — this is not a final-milestone pass over a few screens.
- Domain and hosting are registered in **my** name and accounts throughout.

### Milestones

Fixed price, paid in three stages. Each ends with something I click through and approve.

1. **Read-only site** — every viewing page working against the full historical data, including both imports, plus a colour mockup for sign-off
2. **Data entry** — the admin area; I enter a real match and watch every total, table and sequence update
3. **Polish** — mobile, search, final colours, private visitor analytics, and the question box

### Also required

- Documentation good enough that a different developer could take over the project
- A written and tested restore procedure for the backup file

### Not in this project

- No data entry, scraping or cleaning beyond the two documented imports — the database is done
- **No native mobile app.** The site is a normal website — visitors open a web address in any browser, on any device, with nothing to install. It must work well on a phone; that is what "responsive" covers, and it is in scope.
- No user accounts for visitors, and no contributor or reviewer accounts on the admin side — there is one admin role
- No automated feeds from BBC / Premier League / UEFA. That is a possible later phase, not this one

## Screening questions

**Answer all five questions in your bid.** Bids that skip them, or answer with generic copy, will not be reviewed and will not be shortlisted. Please answer in the bid itself, not in a follow-up message.

1. Every total on this site is computed from match records rather than stored. What is the main performance risk in that approach for a 120-year dataset, and how would you handle it?
2. How would you stop the natural-language question box from ever inventing an answer that isn't in the database?
3. Which stack would you use, and why that one for this project specifically?
4. Roughly how long would each of the three milestones take you?