Little World Nepal France

Bilingual platform for a French–Nepalese education charity

Year: 2026
Type: Client work
Role: Full-stack engineering
Status: In development

A French and English website for LWNF, an association supporting education, training and students in Nepal: projects, a blog, child sponsorship information, a gallery and an inquiry inbox, with a staff administration behind them.

Context

LWNF's supporters are French and English speakers following projects in Nepali schools and villages. The site replaces an ageing blog with a structured platform: projects and news, sponsorship information, and inquiries that reach a staff inbox instead of a personal mailbox.

Donations are informational and link out; the site does not process payments.

Approach

Public pages live under /fr and /en and are rendered statically, revalidated by tag when staff publish. Translatable content is stored as paired French and English fields with a defined fallback, so a half-translated post never shows an English reader a blank title.

System architecture

Select a component to read what it does.

Client

Visitors & staff · FR · EN
Supporters read projects, the blog and sponsorship information in French or English; staff manage content and inquiries.
Calls Next.js

Application

Next.js · /fr · /en · ISR
Locale-prefixed public pages rendered statically and revalidated by tag when staff publish.
Calls Django · DRF · Called by Visitors & staff
Django · DRF · Content · inquiries
Projects, blog, sponsorship profiles, gallery and an inquiry inbox, with the identity system and a staff-only content API.
Calls PostgreSQL, Redis · Called by Next.js
Celery · Mail · cleanup
Worker and Beat: outbound mail, frontend revalidation and scheduled retention cleanup.
Called by Redis

Data

PostgreSQL · Content · identity
Identity, tokens, content and inquiries.
Called by Django · DRF
Redis · Cache · lockout · broker
Caching, login lockout counters and the Celery broker.
Calls Celery (async) · Called by Django · DRF

Engineering challenges

A staff account could take over a superuser
1. Problem
  Staff could change another account's email, including a superuser's, then complete password recovery on it. Passing the original API suite had not exposed this.
2. Investigation
  A QA regression reproduced the full path against the real API and PostgreSQL: edit the recovery email, request a reset, sign in as the superuser.
3. Solution
  Identity writes now require an active superuser; editorial staff keep read access. The Django admin enforces the same boundary, so an explicit change permission cannot bypass it. Staff also can no longer deactivate accounts.
4. Result
  The original takeover now receives a 403 with the stored email unchanged, and six further identity-write cases cover member, staff and superuser targets.

Performance, security and accessibility

Before release I ran a risk-based QA pass against production images, PostgreSQL and Redis. It reported the release as not ready. Eleven defects were confirmed and fixed, and each one has a regression test that fails without the fix.

Technology

TypeScript
Next.js
Django
Django REST Framework
Celery
PostgreSQL
Redis
Docker
Nginx
Playwright