Sports coaching
Sports academy website
Thunder XV is a working name used for this write-up. The client isn't identified, so their actual product name isn't either.
A website for a sports academy, built so a parent standing at the ground can find the programme, the age group, the timing and the person to call.
Interface built in code for this case study — not a client screen capture.
01Business problem
A parent deciding where to enrol a child needs four facts — age group, timing, location, and who to speak to — and academy websites are usually built to communicate atmosphere instead.
Who feels it
Enquiries for a coaching academy come from parents, and the decision has a narrow set of inputs. Is there a batch for a nine-year-old. Does it run on days that work around school. Is the ground reachable. Who do I call. Everything else — the coaching philosophy, the facilities, the photographs — matters only after those four are satisfied.
Most sites in this category invert that. The homepage is a full-screen action shot, the programmes are described in paragraphs of encouragement, and the schedule is either absent or in an image. A parent who cannot find a timing in thirty seconds sends a WhatsApp message asking for it, and then the academy is answering the same four questions by hand all week.
The other half of the problem is where the visit happens. A significant share of first visits are from a phone, sometimes literally at the ground, on a connection that is not good. A site that needs four seconds and a large hero video before showing anything has already lost that visitor.
02Product overview
Programmes as structured, scannable entries with age group and timing on the surface, and an enquiry route that already knows which programme it came from.
Engineering notes
Programmes are structured records, not prose. Each has an age range, days, times, a level and a location, and those fields are visible on the card without opening anything. A parent can scan the list and eliminate most of it immediately, which is what they are trying to do. The descriptive copy sits underneath for the ones that survive the scan.
The programme list filters by age, because that is the first cut every parent makes. Typing a child’s age narrows the list to the batches they can actually join. It works without JavaScript as a plain grouped list, since a filter that fails silently is worse than one that was never there.
The enquiry form is attached to programmes rather than sitting on a separate contact page. Starting an enquiry from a programme card carries the programme, age group and batch timing into the message, so the academy receives a question it can answer in one reply instead of a message saying "interested, please share details". There is a direct call link and a WhatsApp link alongside it, because for this audience those are used more than any form and pretending otherwise would be a design decision made for the portfolio rather than for the client.
The team and facilities content is real photography, presented as a gallery that loads only what is on screen. Squad and coaching profiles are short and factual. The temptation on a sports site is atmospheric copy, and atmospheric copy is what makes a parent scroll past the section with the answer in it.
Performance was the thing I spent most of the build on, and none of it is visible. Images are sized to the layout rather than uploaded at camera resolution, the fold renders from static output with no client-side fetch, and there is no video anywhere on the landing view. The result is a site that shows the programme list before a parent has finished waiting for it.
03Key features
8 capabilities, described by what they let someone do rather than by the technology underneath.
Age range, days, times, level and ground on the card itself. The four facts a parent needs are readable without opening a page or a PDF.
Entering an age narrows the list to eligible batches. Degrades to a plain list grouped by age band when scripting is unavailable.
An enquiry started from a card carries the programme, age group and timing with it, so the academy can answer in one reply.
The routes this audience actually uses, given equal prominence rather than hidden in a footer. The form is one option, not the only one.
Timings are content: selectable, searchable and readable by a screen reader. A timetable posted as a JPEG is the most common failure on sites like this.
Short entries with real credentials rather than paragraphs of encouragement. Trust here comes from specifics.
Real ground and session photographs, sized to their display slot and deferred until in view. No stock imagery.
One tap to navigation from the programme entry, since reachability is one of the four deciding facts.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
Age, days, times and level are fields, and treating them as fields is what makes filtering, consistent display and a future schedule change possible without touching layout.
Trade-off
Adding a programme with an unusual shape — a one-off camp, say — needs a schema decision rather than a paragraph. There is a free-form field for exactly that case.
Why
This audience calls. Funnelling them into a form so the enquiry lands somewhere tidy optimises for the academy’s convenience at the cost of the parent’s.
Trade-off
Enquiries arriving by phone are not captured anywhere, so the academy sees only part of the picture. Stated plainly to the client rather than solved by removing the option.
Why
The landing view exists to answer four questions on a weak mobile connection. A video is the largest possible obstacle to doing that.
Trade-off
The site opens with type and photography rather than motion, which is less immediately arresting than what competitors do. It is also legible three seconds sooner.
Why
A filter is the primary navigation on this page. If it depends on a bundle, a parent on a bad connection gets a list they cannot narrow.
Trade-off
The server-rendered grouping duplicates some markup that the client filter also produces. A small amount of redundancy for a guaranteed baseline.
06Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Transcribed it into structured records with the client checking each entry, then built the display from those records so a timing change is a data edit rather than a new image.
Outcome
Timings became searchable text. This is unglamorous work and it is the single largest improvement on the site.
Approach
Generated responsive sizes at build time, served modern formats with fallbacks, and deferred anything below the fold. Cropping was reviewed with the client so subjects survived the narrow layout.
Outcome
The gallery kept its impact on a phone connection instead of being the reason the page felt slow.
Approach
Carried the programme, age group and batch timing from the originating card into the enquiry, and pre-filled a WhatsApp message with the same detail.
Outcome
The academy started receiving answerable questions rather than opening a conversation to find out what was being asked.
07Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
08Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Programme list
Cards with age range, days, timing and ground visible before anything is opened.
Age filter
An entered age narrowing the list, with the no-script grouping it falls back to.
Enquiry
The programme context that travels with the message, and the call and WhatsApp routes beside it.
The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.
09Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
Implementation detail
10Technical preview
This build was delivered to a client, so the source belongs to them and is not republished here in any form — not as excerpts and not as a repository link.
Delivered work
For private client work, contact me for a walkthrough. On a call I can screen-share the build, go through the component structure, the decisions behind the interaction work and the parts that needed rewriting — the same ground a technical preview covers, without republishing a client's property to do it.
Or email directly: surajk86808@gmail.com
What is not published here
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.