software engineer · backend

I build backends that don’t lose track of the money.

Django · PostgreSQL · production, not prototypes

Backend developer who spends more time in production logs than lecture halls. I'm the one who gets paged when a real-estate client's payment ledger looks off — and I like it that way.

See the work → Get in touch

AWS CCPcertified cloud practitioner

AWS DAcertified developer – associate

Django · PostgreSQLcore stack, production-grade

open to backend roles

~/about

Status report

last updated Aug 2026

I'm Areeba — a backend developer and software engineer. I'm the sole developer keeping a real-estate client's Django system running: bookings, installment plans, payment tracking, and audit logs, all of it live and handling real money.

Outside client work I'm building LexVault, a multi-tenant RAG platform with self-hosted embeddings and local LLM inference — no third-party AI API in the loop. It's how I'm teaching myself the parts of backend engineering a degree alone doesn't cover: tenancy models, observability, and the discipline of freezing scope before it freezes you.

→ everything below is real, shipped work — not coursework.

Currently: building LexVault · sharpening data-structure fundamentals through pattern-based practice on LeetCode.

languages & core cs

PythonOOPData Structures

backend

DjangoDjango REST FrameworkHTMX

data

PostgreSQLpgvectorSQLrow-level multi-tenancy

infrastructure

Linux (Ubuntu)NginxGunicornDockerGitHub ActionsCloudflare R2

cloud

AWS Certified Cloud PractitionerAWS Certified Developer – AssociateHetzner (ARM64)

ai / ml-adjacent

RAG pipeline designsentence-transformersOllamavector search

education

BS Software EngineeringVirtual University

~/leetcode

view profile ↗

Sharpening data-structure fundamentals through pattern-based practice.

~/work

Selected work

two systems — one live, one self-directed

client engagement · live in production

Royal Land PMS

A production Django system that runs a real-estate client's entire sales lifecycle — plots, installment plans, payment tracking, and the audit trail underneath all of it.

Repository ↗ Live demo ↗

Django 5HTMXTailwind CSS v4PostgreSQL 16WeasyPrintCloudflare R2GunicornNginxHetzner ARM64

Full sales lifecycle, modeled end to end: Projects → Units → Customers → Bookings → Installment Plans → Installments → Payments → Expenses.
Append-only audit logging on every financial record — this system handles real client money, so nothing gets silently overwritten.
Automated challan generation with WeasyPrint, replacing a manual paperwork step the client's staff used to do by hand.
Soft-deletes and scheduled overdue detection across financial records, so late payments surface on their own instead of living in someone's spreadsheet.

the interesting decision

Why cron, not Celery. V1 catches overdue installments with scheduled management commands, not a task queue.

Celery was deliberately deferred — a single-firm system with a few hundred installments a month doesn't need the operational overhead of a broker yet. That's a V2 problem, once there's a real reason for it.

try it yourself

username admin password admin123

Seeded with sample data on a separate deployment from the client's live system — safe to explore, click around, and reset. No real customer data lives here.

Royal Land PMS admin dashboard showing revenue, overdue installments and plot status — fig. 01 — dashboard

Installment ledger table with challan numbers, due dates and status — fig. 02 — installment ledger

Auto-generated PDF payment challan — fig. 03 — generated challan (PDF)

system overview — domain flow

Diagram: Project to Unit to Customer to Booking to Installment Plan to Installment to Payment, branching to Challan PDF and an append-only Audit Log — royal-land-pms / domain-model.svgrequest → ledger → challan

personal project

LexVault

A domain-agnostic, multi-tenant RAG platform for legal document search — self-hosted embeddings, local LLM inference, zero third-party AI API dependency.

Repository ↗

DjangoPostgreSQL + pgvectorCelery / Redisbge-small-en-v1.5Llama 3.2 1B · OllamaDocker Compose

Multi-tenant by design: shared-schema + firm_id row-level scoping, UUIDv7 primary keys throughout.
Self-hosted embedding pipeline — bge-small-en-v1.5, 384-dim vectors, CPU-only inference (which meant tracking down a [tool.uv] platform-lock issue just to get torch running clean).
A citation system with teeth: requires an exact document ID and page-number match, not "approximately relevant." Target is 90%+ accuracy across 50+ held-out test questions.
Full async pipeline — Celery + Redis handle upload → chunking → embedding → retrieval, behind a rate-limited search API with a written contract before implementation started.

the interesting decision

A citation bar most RAG demos skip. A two-gate relevance filter has to clear a floor threshold and a gap check before the LLM ever sees a chunk — if nothing survives, it says so instead of guessing.

Scope stayed frozen on purpose too: no billing in the MVP, and an early idea to port an existing legal-RAG repo was evaluated and dropped as non-defensible.

system overview & request flows

LexVault architecture diagram: firm user through auth layer, Django app, ingestion pipeline, pgvector and PostgreSQL, two-gate relevance filter, local LLM — lexvault / architecture.mmdupload → embed → retrieve

Sequence diagram of the login flow: user, Django auth, PostgreSQL, session cookie scoped to firm_id — lexvault / auth-flow.mmdlogin sequence

Sequence diagram of the search flow: user question, embedding, similarity search scoped by firm_id, two-gate filter, local LLM, cited answer or not-found response — lexvault / search-flow.mmdquestion → cited answer

~/contact

Let's talk backend.

Open to backend and platform-engineering roles — internships, junior positions, or just a conversation about the cron-vs-Celery kind of decisions. Email's the fastest way to reach me.

Email me → GitHub ↗

email github linkedin leetcode