AFGJI
AFGJI is the Air Force Golden Jubilee Institute, a real school in Subroto Park, New Delhi, founded in 1986. It's been running for four decades and its web presence didn't reflect that.
AFGJI is the Air Force Golden Jubilee Institute, a real school in Subroto Park, New Delhi, founded in 1986. It's been running for four decades and its web presence didn't reflect that. An institution with that kind of history deserved a site that read as credible on sight, not something that looked like it was thrown together by whoever's nephew knew HTML. That's the actual brief, even though nobody wrote it down that formally: make a forty-year-old school's homepage look like it belongs to a forty-year-old school.
The headline I landed on is "India's First Inclusive School, Shaping Leaders Since 1986," and everything else on the page is built to support that one claim rather than compete with it. Navy and gold form the core palette: #0B1F5C for the navy, #C9A230 for the gold, an ivory #FAFAF7 for the background. Institutional trust, visually, tends to live in exactly those colors. Nobody trusts a school that looks like a startup. I wasn't trying to make AFGJI look modern in the tech-industry sense. I was trying to make it look established, which is a different design goal with a different, more conservative palette than most of what I build.
What's actually in the build
One file. index.html, about ninety-eight thousand bytes, somewhere around sixty-five hundred words of real content once you strip the markup. No separate build step, no compiled CSS or JS: Tailwind loaded straight from a CDN script tag, Google Fonts for Inter, Iconify for icons, all pulled in live rather than bundled. That's a real, deliberate shortcut, not an oversight: for a single-page institutional site that isn't going to be iterated on weekly, setting up a full build pipeline (a bundler, a Tailwind compile step, a deploy process wired to that pipeline) costs more setup time than it returns in value. A single well-structured HTML file with CDN-loaded utilities gets to a finished, deployable result faster, and "faster to a finished result" mattered more here than "architecturally ideal for long-term iteration," because this wasn't a product that was going to keep growing feature by feature. It was a homepage that needed to exist, look right, and be done.
Nine or so distinct sections carry the page: a hero with a scroll-progress bar and the headline, a stats block, a parallax quote section, a programs overview, testimonial cards, a call-to-action block, and a footer that ties it together. The scroll-progress bar and the parallax backgrounds are small touches, not headline features, but they're the difference between a page that feels static and one that feels considered. Motion that responds to how far you've scrolled reads as more finished than a page that just sits there, even when the actual content underneath is identical either way.
Where the README doesn't match reality, and why I'm not fixing it retroactively here
The README describes a Next.js, React, Tailwind, Vercel stack. None of that's what's actually in the folder. What's actually in the folder is one static HTML file with Tailwind loaded via CDN: no React, no Next.js, no framework at all. That's boilerplate README text, almost certainly copy-pasted from a template I use for other projects and never customized for this one, because AFGJI's actual build genuinely doesn't need any of the machinery that README implies. It's a mismatch worth naming plainly rather than pretending the README was ever accurate, because the actual build choice (plain HTML, CDN Tailwind, no framework) was the right call for a single static institutional page, and I don't want the wrong README to make it look like an unfinished React project instead of what it actually is: a complete, simple, correctly-scoped static site.
The stock photography, and what it signals
The background imagery throughout is Unsplash stock: professional, well-composed, and not a single actual photo of AFGJI's real campus, students, or staff. That's a placeholder state, not a finished one. Institutional sites eventually need real photography, because stock imagery of generic classrooms and generic students undercuts the exact credibility the navy-and-gold palette is trying to build. A careful visitor will eventually notice the photos could belong to any school anywhere, which is the opposite of what "since 1986" is supposed to communicate. The build is otherwise complete. The photography is the piece still waiting on the client to supply real assets, and until that happens, the site is honestly still in a pre-launch state even though every section, every animation, and every line of copy is finished.
What this project actually taught me
Not every client needs the same tech stack, and pretending otherwise (reaching for React and a full build pipeline out of habit, because that's what I reach for most days) would have been the wrong call here specifically. A school's homepage that needs to load fast, look trustworthy, and not require ongoing framework maintenance from a client who has no engineering staff of their own is genuinely better served by a single well-built static file than by a more "impressive" architecture that adds maintenance surface nobody on the client side is equipped to handle. Matching the tool to the actual constraint, instead of matching it to what I'd personally rather be building, is a discipline I don't always get right on instinct. The pull toward the stack I'm most comfortable in is real, and this project is one of the cleaner examples of getting that discipline right.
Why the stats block does more work than it looks like
The stats section sitting under the hero (years running, students taught, whatever specific numbers a school like this actually has to show) is doing quiet, disproportionate work in a page like this. A parent or prospective family scrolling past the headline needs a fast, legible reason to keep reading before they've committed any real attention, and a row of concrete numbers reads faster than a paragraph of prose ever could. I built it deliberately plain, with no counting animations and no scroll-triggered reveal, because a forty-year-old institution's credibility shouldn't be delivered with the same flashy count-up effect I'd use on a startup's landing page. The numbers just sit there, stated, the way a school's actual reputation sits there: not performed, just true.
What I'd tell the client before this actually launches
If I were handing this off today rather than describing it after the fact, the one thing I'd flag loudest isn't a code issue at all. It's the stock photography. A navy-and-gold palette and a well-structured page can only carry institutional trust so far before a visitor's eye catches that the "campus" photos are clearly generic stock, and once that's noticed, it quietly undercuts everything else the page is trying to say about the school being real, established, and specific. Real photography is the single highest-leverage thing left to do here, and it's the one piece that isn't a coding task at all. It's a request sitting with the client, waiting on them to supply what only they can supply.
Full stack developer. Founder of Yashveer Labs. Sometimes the right architecture is the one with no architecture at all.
Start a conversation about this.
Whether it's afgji itself or the next system worth building, the lab is reachable.