CampusGarh: a discovery platform built to be found

EdTech · India · Launched 2024 · Sole engineer, end to end

Visit CampusGarh (opens in a new tab)

The problem

College discovery in India is fragmented across thousands of individual institutional websites. A student comparing fees, courses, location, entrance requirements and placement outcomes has to assemble that picture themselves, from dozens of sources.

Aggregating the data is the obvious part. The harder truth is that aggregated data creates value only if students can find it — which makes the rendering architecture a commercial decision, not a technical preference.

The constraint that shaped everything

The platform’s entire acquisition model is organic search. So the question wasn’t “what’s the best way to build this?” It was: “what will still be true if Google has to be able to read every page?”

That reframing determined the stack, the data model and the URL scheme before any code was written.

What we built

  1. A normalised institution data model. Institutions, courses and entrance exams modelled as related entities rather than flat records. This is what makes cross-comparison possible at all — comparing a course across colleges, or an exam across institutions.
  2. An addressable discovery surface. Every institution and every course gets its own URL with its own metadata. Search filters live in URL parameters, not component state — so a filtered comparison is shareable, bookmarkable and indexable. A student can send a friend a link to exactly what they were looking at.
  3. Progressive web app delivery. Service-worker caching for offline access and fast repeat visits, with an installable manifest for an app-like experience. Chosen over a native app deliberately: acquisition depends on ranking, and a native app cannot be a search result. A native build would have been the more impressive-sounding decision and the wrong one.
  4. Contextual enquiry capture. Admission enquiries carry the context of what the student was actually looking at, so the institution receives intent rather than a bare form submission.

Why one engineer owned the whole stack

SEO requirements were baked into the architecture and the data model instead of being handed to a separate team after launch. When the same person owns the data model, the routing and the rendering, “make it indexable” stops being a retrofit and becomes a design constraint from day one.

Stack

  • React
  • Node.js
  • MongoDB
  • PWA
  • Service Workers

Scale

5,000+ institutions covered.

Your business depends on being found too?

Get a project estimate

More work

See all work