Skip to content
Hen HeangHen Heang.
Back to Projects
VSTV Agent — Real Estate Platform & Operations Console

Full-Stack Application · Personal Project

VSTV Agent — Real Estate Platform & Operations Console

Solo Developer — Full-Stack 2024 — Present 1 developer
Live
GitHubLive Demo
  • Next.js 14
  • React 18
  • TypeScript
  • Tailwind CSS
  • Drizzle ORM
  • Neon PostgreSQL
  • Spring Boot
  • Telegram

Project Summary

Problem

Real-estate listings, staff operations, and Telegram updates need one trustworthy workflow. VSTV Agent brings the public property experience and the private inventory console together so agents can manage verified units, publish safe summaries, and help renters find options in Phnom Penh.

Approach

VSTV Agent is a full-stack real-estate application for VSTV Agent (Cambodia) Co., Ltd. The public site presents rental properties, services, agents, contact paths, and location information; the protected admin console manages staff, units, availability, imports, inquiries, and operational settings.

What I Built

  • Public property discovery and agent/contact flows
  • Protected staff workspace with role-aware access
  • Searchable unit inventory and availability workflows
  • Two-step CSV preview and confirmed import

Implementation

The application uses Next.js 14 App Router, React 18, TypeScript, Tailwind CSS, TanStack Query, Drizzle ORM, and Neon PostgreSQL. Browser code talks to typed API clients; server-only route handlers and services own database access. The migration keeps Spring Boot as the current backend for authentication and staff domains while Next.js serves the unit inventory and import domains. Telegram delivery is scheduled through the application workflow.

Architecture Flow

Next.js App Router public site + admin console
Typed browser API clients
Next.js route handlers + application services
Drizzle ORM + Neon PostgreSQL
Spring Boot API during incremental migration
Telegram scheduled delivery
The UI is deliberately insulated from backend ownership: screens call lib/api clients, which call /api/v1 paths. Some paths still reach Spring Boot while migrated domains run through Next.js route handlers, services, repositories, and Drizzle. Private owner fields stay server-side and never enter public property or Telegram payloads.

Backend Evidence

Core data

staffunitspropertiesproperty_imagesinquiriesloanstelegram_unit_broadcastaudit_log

Key endpoints

  • GET/api/v1/units

    Searchable, paginated private unit inventory

  • POST/api/v1/units/import/preview

    Parse and classify a CSV without persisting rows

  • POST/api/v1/units/import

    Persist confirmed unit import rows

  • PATCH/api/v1/units/{id}/availability

    Change a unit's availability state

Engineering Decisions

  1. Challenge

    Moving backend ownership incrementally without breaking a live public site

    Decision

    A stable /api/v1 boundary lets Spring Boot and Next.js migrate domain by domain

  2. Challenge

    Keeping private owner contacts and internal notes out of public and Telegram payloads

    Decision

    Server-side mapping and public-safe formatting omit sensitive fields before delivery

  3. Challenge

    Making imports and scheduled delivery safe to retry

    Decision

    Preview/confirm imports and durable delivery claims make operational workflows recoverable

Takeaways

  • Incremental backend migration works best when the client contract remains stable and ownership is documented per domain
  • Operational safety is part of product design: preview, permissions, redaction, retries, and audit records matter as much as CRUD screens
Next Project

H-Phsar — B2B Marketplace API