Back to projectsPROJECT 02 / 03

Vacation-rental catalog and management

Alquileres Uspallata

Full-stack platform for publishing properties, reviewing listings, tracking availability, and connecting visitors with owners.

Status
Active development
Role
Domain analysis, architecture, and full-stack development
Year
2026

Project overview

Product problem, system shape and current evidence

Problem
A listing needs controlled review and publication, freshness-aware availability and owner contact without exposing private operational data.
System
A NestJS API and Vue interface use Prisma and PostgreSQL, separating public catalog data from owner and administration workflows.
Evidence and validation
The repository contains API and authorization tests plus reproducible catalog and listing captures made with synthetic data.
Limitations
These are reproducible synthetic captures of the NestJS/Vue product. There is no public deployment. Review/publication and administrative-audit workflows are not shown; reservations, payments and real-time flows are out of scope. A live link depends on the community product’s own release gates.

Problem

A vacation-rental catalog is not solved by displaying cards alone. It also needs to control who can edit a listing, when publication is approved, whether availability is still current, and how a visitor inquiry reaches the correct owner without exposing internal data.

Alquileres Uspallata addresses that journey as a full-stack system with a public catalog, private owner and administration workflows, timestamped availability, and auditability for sensitive actions.

Context and constraints

The domain combines public information with private operations. A visible listing must pass explicit review and publication steps, while availability can become stale even if the listing remains published.

The main constraints were:

  • separate ownership, review, and publication;
  • derive the owner from the authenticated session;
  • never trust arbitrary owner identity sent by the client;
  • expose only allowed fields through public routes;
  • preserve rejection reasons and administrative actions;
  • avoid presenting stale availability as currently confirmed availability.

Architecture

The NestJS API organizes authentication, owners, listings, review, contact, and auditing. Prisma and PostgreSQL support the transactional model. Vue consumes separate routes for the public experience, owner workflows, and administration.

The system separates public fields from ownership, storage, review, and audit data. Private operations derive owner context from the session, and administrative actions are associated with actor, action, entity, target owner, and timestamp.

Engineering decisions

Review and publication are separate states. A listing can move from DRAFT to SUBMITTED, then to APPROVED or REJECTED; only an approved listing can be published. Editing or reviewing does not automatically make a listing visible.

Availability has explicit freshness. Availability stores a last-confirmed timestamp so the UI can distinguish fresh information from potentially stale information.

Server-side authority. The browser does not decide which owner controls a listing or which internal fields become public.

Auditable assisted actions. Relevant administrative operations leave a trace tied to the actor and affected entity.

Implementation

The implemented flow covers:

  • drafts and submission for review;
  • approval or rejection with a persisted reason;
  • controlled publication;
  • paginated public catalog with filters;
  • public listing with availability;
  • direct contact with the correct owner;
  • administrative actions with audit records.

The core stack combines NestJS, Vue, TypeScript, Prisma, and PostgreSQL with a clear separation between API, persistence, and user experience.

QA and validation

The repository includes versioned migrations, API and guard tests, linting, builds, secret validation, and a health smoke test. Documented checkpoints cover catalog, review, availability, contact, and audit workflows.

Validation focuses especially on authorization boundaries, public responses without internal data, and consistent state transitions.

Current result

The product core is implemented and remains in active development. The platform already models the full journey from listing creation and review through publication, public discovery, and contact without mixing client authority with server authority.

Evidence and limits

Available evidence is in the repository, automated tests, and documented case study. Reproducible captures of the catalog and a public listing with availability, generated with synthetic data, appear above. A verifiable public deployment and visual walkthroughs for review/publication, direct contact, and administrative audit remain pending.

The current scope does not include reservations, payments, realtime flows, notifications, full tourism operations, or a public production deployment. The demo therefore remains unset and the project is presented as active development rather than a finished production product.