Skip to content

Nikunja Seva Pty Ltd · Australia

Radhakundah Platform

A research library, a publishing house and a membership platform sharing one codebase — built for an Australian client, delivered end to end, and running as a single service in Azure.

Client
Nikunja Seva Pty Ltd
Location
Australia
Engagement
Full-stack build, design to deployment
Delivered by
MaHaVi — mahavi.tech

128

Documented API endpoints

28

Database models

60s

Signed link lifetime on gated papers

1

Azure service running site and API

The brief

Nikunja Seva Pty Ltd needed a public home for a body of scholarly and devotional work centred on Radha Kunda: peer-quality research papers, long-form articles, a blog, photography, recorded talks, and the people behind all of it. The brief asked for a website, a content management system, and an architecture that could carry future modules without being rebuilt.

The hard part was never the pages. It was that a research library, a publishing operation and a media archive have genuinely different needs, and the client's team is small enough that one person has to be able to run all three from the same screen.

What we built

One platform with a public site, a member layer and a staff CMS, served by a single documented API. The public side carries research papers with full citation metadata, articles and blogs, author profiles, photo galleries, a video library, search, and a newsletter. The staff side manages every one of those content types, plus media, taxonomy, redirects, comments, subscribers and an audit trail.

  • Research papers with DOI, journal, volume, issue, page range and keywords — rendered only where filled in
  • Author records with affiliation, biography, photograph, ORCID identifier and a public profile page
  • Byline order preserved, with the corresponding author marked
  • Articles and blogs unified behind one model, so a piece published to both places still has one canonical address
  • Galleries, a YouTube-backed video library, tags shared across posts and research, and site-wide search

Papers that are gated without disappearing from search

Research PDFs live in a private container and never receive a public address. Opening one requires a signed-in reader and mints a link that expires in sixty seconds, shown in-page with the download toolbar suppressed. Every open is recorded — who, when, which file, from which address.

Abstracts, citations and metadata stay fully public, so gating the file costs nothing in search visibility. The paper is still indexable, quotable and citable; only the PDF itself is behind the door.

Search that reads inside the PDFs

Uploaded papers are parsed and their full text folded into the search index. A visitor can find a paper by a phrase buried on page twelve rather than only by its title. Matches are weighted — title outranks abstract, abstract outranks body — so results are ranked rather than merely filtered.

The extracted text drives ranking only and is never returned to a client, so gated papers stay gated while remaining findable.

SEO built into the platform, not bolted on

The API is the single source of SEO truth: every detail endpoint returns a resolved block — title, description, canonical, robots, Open Graph, Twitter and JSON-LD — with all fallbacks already applied, and the front end renders it verbatim.

  • Renaming published content writes a permanent redirect automatically, and re-points older redirects so a link is never more than one hop from its destination
  • A post published to both articles and blogs gets one canonical address instead of two copies competing in search results
  • A paginated sitemap index served from the site's own domain, not the API's
  • Structured data for every content type — papers carry their DOI and journal, videos their duration and thumbnail
  • Thin category, tag and search pages are marked noindex so they cannot dilute the pages that matter
  • Any environment that is not the live site refuses indexing at both the robots and the header level, so a staging copy cannot outrank the real one

Security that assumes the worst

Authentication is Google sign-in only. There is no password database to breach and no reset flow to abuse. Refresh tokens are stored only as hashes and rotate on every use; the access token never touches browser storage.

A token presented twice — the signature of a stolen session — revokes every session on that account instantly and records the event. Each user gets a devices and sessions panel to end any session individually or sign out everywhere.

Every staff action is written to an audit trail with actor, target and IP, filterable from its own screen and pruned on a twelve-month retention window. The database is dumped, compressed and written to a dedicated backup container on a schedule, with no human step to forget.

One service instead of two

The website and the API deploy together onto a single Azure App Service rather than one instance each, so the recurring hosting bill carries one instance instead of two. The site reaches the API over an internal address, so traffic between them never leaves the host — no egress charges, no added latency, and no second public endpoint to secure.

Sitemaps and SEO files are proxied through the site's own domain, so the API needs no public hostname, no separate certificate and no DNS record of its own.

Beyond the brief

Several things were built that the agreed scope did not ask for, because they were cheap to add during the build and expensive to retrofit afterwards.

  • A membership layer: visitors read everything without signing in, and signing in adds full papers, likes and comments — the groundwork three future modules already depend on
  • Comment moderation, switchable per post, with hidden-comment handling on a dedicated screen
  • All 128 endpoints published as a live, browsable reference with a built-in console, so the next developer does not reverse-engineer anything
  • One consistent response envelope with a fixed set of error codes and field-level validation messages
  • Separate liveness and readiness checks, so the host can take a sick instance out of rotation instead of serving errors
  • Exactly one protected super-admin re-asserted on every start-up — the site cannot be locked out of its own administration

An identity built for the subject

A considered palette — white ground, saffron reserved for actions, nila blue for depth, gold as ornament — with a deep-blue night mode applied before the first pixel is painted, so there is no flash of the wrong theme.

The homepage centrepiece is a three-dimensional mandala generated entirely in code, with no model or texture files for a visitor to download. The homepage itself assembles its hero, research, articles, blogs, videos, gallery and updates feed from a single cached request rather than eight, and non-essential reads have defined fallbacks so an interruption degrades one section rather than the whole page.

What it is built on

Front end

  • Next.js 15 (App Router)
  • React 19
  • TypeScript
  • Tailwind CSS v4
  • Three.js

Back end

  • Fastify
  • TypeScript
  • Prisma
  • PostgreSQL 16
  • Zod

Platform

  • Azure App Service
  • Azure Blob Storage
  • Google OAuth
  • OpenAPI / Swagger

Want one like this?

Platforms of this size start with a scoping conversation, not a template. Tell us what you are trying to build.