Divine Vision Infratech - Engineering a Transactional Real Estate Platform

The engagement began with buyer-journey mapping, an operational review, and requirements sessions with the Divine Vision team. The work was organized into three phases: a transactional foundation, an intelligence layer, and later automation and CRM improvements.

A formal requirements freeze in August 2026 established SRS v2.0 as the build baseline. It included operational needs that are easy to miss in a public website brief: recording offline and cash payments, configuring notification rules, and keeping an audit trail. New ideas after the freeze could be handled as documented changes instead of silently expanding the build scope.

The design process explored multiple distinct landing-page concepts before the client selected a direction. The final experience pairs a premium visual presentation with practical buyer information such as approvals, plot details, and location.

The booking flow connects plot selection to a reservation rather than treating an enquiry as a completed conversion. The inventory grid shows each plot as available, on hold, or sold, with pricing. A buyer can select more than one plot in a booking.

A hold protects a plot while a buyer completes the payment step, reducing the chance that two buyers reserve the same unit at the same time. The booking process also supports digital Aadhaar and PAN document uploads. The source requirements specify scannable UIDAI Secure QR validation for Aadhaar documents.

After a booking is completed, the platform generates the associated application and allotment paperwork as a PDF. Regulated e-KYC, electronic signing, and e-stamping steps are intended to use licensed providers rather than being recreated inside the application.

Instead of a static lead form, the public experience uses Divine Assist for buyer enquiries. The assistant is designed to answer questions about projects, pricing, registration status, and location using Divine Vision information retrieved from PostgreSQL with pgvector. Grounding answers in source content gives the team a way to check responses against the underlying project information.

The assistant can qualify a conversation by budget, unit type, and purchase timeline, then use tools to arrange a site visit. It can also share a project location through WhatsApp and record where an enquiry originated, giving sales staff context about the lead.

Google Gemini provides the language-model reasoning and tool-calling capability. Self-hosted, open-source Whisper handles voice input. The design supports escalation to a human for high-intent enquiries rather than expecting automation to handle every conversation.

The employee portal models how site visits are handled by the field team. Staff can record a visit with visitor details and the property shown. The associated lead is assigned to that employee for a three-day window and hidden from colleagues during that period; if no follow-up occurs, it returns to the shared pool automatically.

This explicit ownership window is intended to reduce disputes about lead responsibility while preventing an inactive lead from remaining locked indefinitely. Attendance and leave management are also included, giving staff a single portal for these day-to-day tasks.