Prominence Football Academy

Prominence Football Academy is a real youth football academy in Vikaspuri, West Delhi, founded in 2024, running out of Holy Innocents Public School, with more than two hundred players between five and seventeen years old and AFC and AIFF-licensed coaches actually on staff. This isn't a hypothetical client brief. It's a working academy with real trial bookings and real parents deciding, right now, whether to enroll their kid, and the site exists to convert exactly that decision: someone lands on the page wondering if this academy is legitimate and worth the monthly fee, and needs to leave convinced, with a clear next step.

The build, and why it's more than a landing page

Four real pages under public_html (home, about, programs, contact) plus a proper custom 404, which is a small thing that signals more care than it costs to build. But the site itself is the smaller half of this project. The larger half is the build pipeline sitting in build-tools, and it's genuinely more sophisticated than most sites this size get: optimize-images.mjs for compressing and resizing assets, favicons.mjs for generating a full favicon set instead of one lonely .ico, fetch-fonts.py and convert-picture.py for asset preparation, fix-lqip.py for generating low-quality image placeholders so pages feel like they're loading instantly even on a slow connection, relativize-paths.py for keeping the build portable, and screenshot.mjs plus shot-regions.mjs for automated visual QA: screenshotting the actual rendered pages so I can catch a layout break by comparing images instead of eyeballing every page by hand after every change.

Deployment isn't manual either. There's a real GitHub Actions workflow wired to Vercel, vercel.json and .vercelignore configured properly, so a push to the right branch ships to production without me needing to remember the deploy steps or run them by hand. For a single small-business marketing site, that's more infrastructure than strictly required: plenty of sites this size get FTP'd up by hand and nobody notices the difference. I built it properly anyway, because "properly" here cost an afternoon once and saves me from ever thinking about deployment again for the life of the project, which is exactly the kind of investment that's worth making even when nobody but me will ever see the pipeline behind the finished pages.

The content doc that's doing the real work

prominence-content.md is the single most useful file in this project, and it's not code: it's a meticulously maintained twenty-kilobyte source-of-truth document covering the brand fonts (Oswald, Inter, Bebas Neue), the exact hex codes for the brand palette, and the full three-tier program structure down to the minute: Little Champs at fifteen hundred rupees a month, Rising Stars at twenty-five hundred and marked "Most Popular," Elite Squad at thirty-five hundred, each with its own real weekly schedule. Real address: C Block, Holy Innocents Public School, Vikaspuri. Real phone and WhatsApp number. This is the kind of document that doesn't show up in a portfolio screenshot but is genuinely the backbone of the whole project, because a marketing site is only as trustworthy as the specificity of what it claims, and specificity requires someone keeping the actual facts straight in one place instead of scattered across a dozen half-remembered client conversations.

There's a small, honest moment in that doc worth naming: an earlier draft claimed "4+ Years of Excellence," which directly contradicts the academy's real founding year of 2024. I caught it, and the fix wasn't to fudge the founding date to make the years-of-excellence claim true. It was to change the claim itself, to "10+ Yrs Coaching Experience," which is honest about the coaches' individual backgrounds without falsely implying the academy itself has existed longer than it has. Small correction. It's also exactly the kind of overclaim the whole point of good client work is supposed to catch before it ships, not after a parent notices the math doesn't add up.

What's still marked placeholder, on purpose

The content doc is explicit about what isn't locked yet: the contact email is an assumed address pending confirmation, coaching staff bios don't have real names or photos attached, the testimonials on the page are sample quotes standing in for real ones with actual permission behind them, and the social handles are assumed rather than confirmed live accounts. None of that is hidden or glossed over: it's flagged directly in the source doc as [PLACEHOLDER], which matters, because a site that quietly ships fake testimonials without labeling them internally as fake is a site where nobody remembers, six months later, which quotes were ever real. Naming the placeholders explicitly, in the doc that actually gets read before launch, is the difference between "temporarily incomplete and clearly tracked" and "quietly dishonest and easy to forget."

Why the image-optimization workflow matters more than it looks like it should

There are several large raw images sitting at the repo root (two, sometimes two-and-a-half megabytes each), alongside smaller, renamed, optimized versions clearly produced by the build pipeline. That's evidence of a real, working asset pipeline in active use, not a finished, static state. A youth academy's site lives or dies partly on how fast it loads on a parent's phone during a school pickup line with mediocre signal, and every unoptimized multi-megabyte hero image is a real, measurable cost against that. The pipeline exists specifically to make sure the images that ship are never the raw ones sitting at the root, and the fact that both versions still coexist in the repo tells you the optimization step is a deliberate, repeatable part of the workflow, not a one-time manual pass I did once and forgot about.

The screenshot tooling, and why I bothered

screenshot.mjs and shot-regions.mjs exist because manually checking every page, every viewport size, every time I touch shared layout code is exactly the kind of tedious verification step that gets skipped under time pressure, and skipped verification is how a small CSS change silently breaks the mobile nav on a page nobody happened to look at that day. Automated screenshotting turns "did I break anything" from a manual, easy-to-skip chore into a quick visual diff I can actually be disciplined about running before every deploy. For a site this size, that might read as overengineering. I'd argue it's the opposite: it's exactly the kind of small investment that makes a solo developer's QA process actually hold up over time instead of degrading the moment things get busy, which for a real client with real trial bookings on the line is not a place I want to be cutting corners.

What "done" actually means for a site like this

I don't think of this project as finished in the way a piece of software can be finished. The build pipeline is complete, the deployment is automated, the four pages are built and content-complete against the source-of-truth doc, but a marketing site for a growing youth academy is closer to a living document than a shipped product. Real coach bios need to replace the placeholder cards. Real testimonials need to replace the honest-but-fictional sample quotes. The contact email needs confirmation from the client, not an assumption I made on their behalf. Calling it "launched" before those are resolved would be technically true and practically premature, and I'd rather hold the line on that distinction than let a mostly-done site get treated as a fully-done one.

Full stack developer. Founder of Yashveer Labs. Real kids, real coaches, real fees: the site just has to tell the truth clearly enough that a parent trusts it on the first visit.