GharBazaar

The feature the whole product rests on. Properties and universities both carry a PostGIS geography point, and the distance between a linked pair is computed by a database trigger — never supplied by a user.

• ·PostGIS extension enabled; properties and universities both store geography(point) locations
• ·property_universities join table with a composite primary key and a computed_distance_m column
• ·A trigger computes st_distance on link creation; a second trigger recomputes every linked distance when a property's pin moves
• ·Distance is explicitly never user input — a seller cannot claim to be closer to a campus than they are
• ·Composite index on (university_id, computed_distance_m) so 'nearest first' is an index scan
• ·Google Maps integration for pin placement and map-based browsing

A 58-table schema where authorization is a database concern. Row-Level Security covers every table, and the migration history shows security being tightened deliberately over time.

• ·58 tables, 67 indexes, 16 functions and 21 triggers across 8 migrations
• ·128 Row-Level Security policies, with RLS enabled on all 58 tables
• ·Dedicated hardening migrations for RLS gaps, financial record protection and view-counter abuse
• ·Hard deletion of properties blocked at the database, preserving audit history
• ·Separate audit_logs and activity_logs tables for administrative and user actions
• ·Security-definer functions used deliberately and scoped with an explicit search_path

Trust is the core problem in a housing marketplace. Verification is tiered rather than binary, so the platform can distinguish a verified identity from a verified property.

• ·Three verification levels: identity, property, and trusted
• ·Verification request states: pending, approved, rejected, expired
• ·KYC documents stored in a private bucket with MIME-type and file-size restrictions
• ·Admin endpoints to verify or reject a submission
• ·Property images kept in a separate public bucket — private documents never share a bucket with public assets

Properties move through submission, moderation and publication, and expire automatically so the catalogue does not fill with stale listings.

• ·Admin approve and reject endpoints backing a moderation queue
• ·Separate publish action, so approval and going live are distinct steps
• ·Automated daily expiry job for listings past their active window
• ·Price history retained per property
• ·Stable slug management so a renamed listing keeps a working URL
• ·Amenities, property types, room types and areas maintained as seeded reference data

Student contact details are never exposed on a listing. A lead is an explicit act, and only then does contact information become visible.

• ·Inquiry model capturing student interest against a property
• ·Contact reveals recorded separately, so who saw which details is auditable
• ·In-app conversations and messages between parties
• ·Visit appointment scheduling
• ·Lead export endpoint for sellers working their pipeline outside the platform
• ·Engagement events captured across eight types: view, gallery open, reveal, WhatsApp click, call click, share, favourite and visit request

Notifications use a transactional outbox. A notification is written in the same transaction as the action that caused it, then delivered asynchronously by a scheduled job.

• ·notification_outbox table written as part of the originating transaction
• ·A scheduled job drains the outbox on a daily cadence
• ·Delivery failure cannot roll back or lose the business action that triggered it
• ·Per-user notification feed with read-state tracking

Search combines university proximity with the ordinary filters a renter needs, and remembers searches so students hear about new matches.

• ·Dedicated search feature module with a student-housing entry path
• ·Filtering across property type, room type, amenities and area
• ·Saved searches persisted per user
• ·A nightly alert-matching job pairs new listings against saved searches
• ·Search events recorded for relevance and zero-result analysis
• ·Favourites, comparison sets and recently-viewed lists per user

Sellers and dealers subscribe to plans; the platform tracks payments, issues invoices and consumes provider webhooks.

• ·Subscription plans and per-user subscriptions
• ·Payment records with invoices
• ·Webhook event table for reconciling provider callbacks
• ·A dedicated migration protecting financial records from modification

A marketplace needs enforcement as much as features. Reports, strikes and blocks are first-class, and admins have a purpose-built surface.

• ·Property reports with resolve and dismiss actions
• ·Progressive enforcement via user strikes and account deactivation
• ·User blocks and blocked identifiers to stop repeat abuse
• ·Support ticket system with threaded admin replies and status transitions
• ·Reference-data seeding endpoints for cities, areas, universities, amenities and property types
• ·19 dedicated admin endpoints out of 59 total route handlers

The project has a unit test suite and a CI pipeline wired to run it. The tests pass locally; the pipeline itself is currently red at the lint step, so the later stages have not yet run green.

• ·196 Vitest unit tests covering schemas, storage, formatting and API invariants — all passing locally
• ·23 Playwright end-to-end specs — 10 run against the deployed app; the other 13 self-skip without service-role credentials, so they never write to live data
• ·Coverage reporting configured
• ·GitHub Actions pipeline: install, lint, typecheck, unit tests, build, then end-to-end tests
• ·The lint failures that were blocking CI are fixed; the change is committed but not yet pushed, so the remote pipeline is still red
• ·SEO infrastructure with robots, dynamic sitemaps and structured data
• ·Vercel Analytics and Speed Insights instrumented
• ·Image upload pipeline with client-side compression, cropping and a media job queue