Build and Deploy a Real Estate Listing Website With Claude Code

Plan the Property Website

Open your project in Claude Code, fill in the three fields, and use this prompt. It only plans — nothing changes yet.

Plan the Real Estate Website

Tell Claude what kind of properties you list, which details matter, and what visitors should be able to filter before anything is built.

I want to build a real real-estate listing website with Claude Code. Listing type: {{LISTING_TYPE}} Property information visitors should see: {{PROPERTY_DETAILS}} Search and filters: {{SEARCH_FILTERS}} Do NOT build anything yet. First inspect the existing project. If this is an empty or new project, inspect the available stack and configuration and plan the smallest appropriate implementation. 1. PUBLIC EXPERIENCE Plan: 1. A visitor opens the website 2. Sees the available properties 3. Searches or filters the listings 4. Opens one property 5. Views its photos and details 6. Sends an inquiry about that property 7. Gets a clear confirmation Do not require visitor accounts. 2. ADMIN EXPERIENCE Plan a proper protected Admin Dashboard. The business must NOT use the Supabase dashboard for normal operations. Inside the application, authorized staff should be able to: - sign in - see the listings - create a property - edit a property - manage property images - publish and unpublish a property - mark a property unavailable, sold or rented where that fits this business - see customer inquiries - update an inquiry's status 3. DATA MODEL Plan the minimum data required. The likely concepts are a PROPERTY, a PROPERTY IMAGE, an INQUIRY, and ADMIN / STAFF access. Do not add an agent table, an office table, buyer accounts, favorites or appointments unless the existing project genuinely already requires them. If property images can live cleanly on the property record for this project, consider that instead of a second table — choose based on the real implementation and do not over-normalize a simple MVP. 4. PROPERTY TYPES Keep the property types simple and use only the ones this business actually lists. Typical examples are House, Apartment, Villa, Office, Commercial and Land. Do not force every possible type into the project. 5. LISTING STATUS Use simple states: DRAFT, PUBLISHED and UNAVAILABLE. If this business needs SOLD or RENTED, represent them cleanly alongside those states. Do not build a workflow engine and do not allow arbitrary free-text publication states. 6. INQUIRY STATUS Keep the inquiry workflow simple: NEW → CONTACTED → CLOSED Add INTERESTED only if it is genuinely useful for this business. Do not turn this into a CRM. 7. SECURITY MODEL A PUBLIC VISITOR may: - read the published, public property data - view the approved property images - submit an inquiry A PUBLIC VISITOR must NOT: - create or edit a property - publish a listing - upload property images - read the private inquiries - change an inquiry's status AUTHORIZED ADMIN / STAFF may: - manage properties - manage property images - read and manage inquiries Being signed in is not the same as being staff — plan a trusted admin check. Never put a Supabase Secret or service-role key in browser code. 8. EXCLUDED FROM VERSION 1 Do not plan: mortgage calculators, MLS or Zillow integration, property scraping, automated valuation, map-based search, Google Maps, an agent marketplace, customer accounts, saved favorites, a viewing calendar, online payments, rental payments, contracts, e-signatures, AI-written property descriptions, a CRM, email automation, SMS, live chat, multiple agencies or multi-tenancy, advanced analytics, property comparison or a recommendation engine. Return: REAL ESTATE PLAN Public pages: Admin pages: Property fields: Search/filter fields: Listing statuses: Inquiry workflow: Data model: Storage approach: Admin authorization: Public permissions: Admin permissions: Features deliberately excluded: Then return exactly one: READY TO BUILD or: NEEDS A DECISION Do not modify anything yet.

What type of properties will you list?

What property details should visitors see?

Price, location, bedrooms, bathrooms, size, property type, amenities...

How should visitors search or filter properties?

Location, price range, property type, bedrooms...

Review the plan before continuing. Keep version 1 focused on listings, inquiries and property management.

Confirm the MVP

Make sure the approved plan includes exactly this:

Public property listings

Search / filters

Property detail

Inquiry form

Protected Admin Dashboard

Property management

Inquiry management

No unnecessary marketplace features

Create or Reuse Supabase

If this project is already connected to the right Supabase project, reuse it — don't create a second one.

Open Supabase

https://supabase.link/r4gdwhi

Create a new project if you don't have one Open the project's Connect panel Copy the Project URL and the Publishable key Ask Claude Code which environment variable names this project uses, then add both values locally

IMPORTANT

The browser app only needs the Project URL and the Publishable key. A Secret key belongs only in a trusted server environment, and only where one is genuinely needed — never in browser code and never committed to GitHub.

Create Property and Inquiry Data

Use this prompt in the same Claude Code session.

Create the Real Estate Database

Create the smallest Supabase structure for public property listings, private inquiry management and secure admin access.

Using the approved real-estate plan, create the minimum data model, storage model and access rules. Reuse correct existing structures where appropriate. Do not duplicate existing profiles or admin infrastructure. Never print secret values. 1. PROPERTIES Store only the fields approved in the plan. Typical fields where relevant: id, title, slug, description, price, listing type, property type, city or location, bedrooms, bathrooms, size, amenities, status, published, created_at, updated_at. Do NOT automatically add every possible real-estate field. Use only what the plan needs. 2. PRICE Use an appropriate numeric or decimal money representation, consistent with this project's database pattern. Do not store a formatted string such as "$450,000" as the authoritative price — store the value cleanly and format it in the UI. Do not add mortgage calculations, currency conversion or tax calculations. 3. PROPERTY IMAGES If image upload is part of the approved plan, use Supabase Storage with an appropriate bucket model. Public property photos may be publicly READABLE if that is the intended public listing behaviour. Writing is different: only authorized staff may upload, replace or delete property images. Do not give public users broad Storage write permission, and do not expose a Secret or service-role credential to perform uploads. 4. IMAGE OWNERSHIP Associate each uploaded image with its intended property safely. Arbitrary public browser input must never be able to attach an image to, or delete an image from, another property. 5. INQUIRIES Store only the approved fields. Typical fields where relevant: property id, customer name, email, phone if genuinely needed, message, status, created_at. Do not collect unnecessary sensitive information. 6. PUBLIC PROPERTY READ Public visitors may read only the listings intended to be public. Draft and unpublished properties must not be readable simply because the UI filters them out — the database and access rules must respect publication status themselves. Do not depend on an "if (published)" check in the frontend as the protection. 7. PUBLIC INQUIRY SUBMISSION Visitors must be able to submit an inquiry safely. Do NOT grant broad anonymous table permissions just to make inserts work — use the smallest secure approach the existing architecture supports, and validate important fields on the trusted path. Trusted logic assigns the internal defaults, including the initial status NEW. A public visitor must NOT be able to set the status, staff notes, or any other admin-only field, and must NOT be able to read, list or edit inquiries or modify properties. 8. STAFF AUTHORIZATION Use proper authenticated admin / staff authorization. Do not treat every authenticated Supabase user as real-estate staff. Do not rely on hidden admin navigation, localStorage, frontend role state or a profile field the user can edit about themselves. The database or server rules must enforce staff access for property writes, image management and private inquiry reads. Reuse the closest admin authorization pattern this project already uses. Tell me how to grant the FIRST admin safely — for example one reviewed SQL statement run once in the Supabase SQL Editor — never through self-service sign-up. 9. SEARCH Design the data and query model so the approved filtering can be performed efficiently, without downloading every record into the browser where that can be avoided. Add an index only where a filter genuinely needs one. Do not add Elasticsearch, Algolia, Meilisearch or any external search service — database filtering is enough for this MVP. Give me: 1. Tables reused 2. Tables created 3. Property fields 4. Publication and access model 5. Image Storage model 6. Inquiry submission model 7. Inquiry privacy model 8. Admin authorization model 9. Search and filter query model 10. ONE reviewed SQL / migration block where appropriate 11. The Storage setup I need to do myself 12. Any blocker Do not use destructive DROP statements. If a table with the same name already exists, warn me instead of replacing it. Do not execute destructive database changes automatically, and do not build the UI yet.

Review the database plan and SQL, then apply it with your project's Supabase workflow — usually the SQL Editor in your Supabase project. Create the Storage bucket the report asks for, then create your own staff account and grant it admin access the way the report describes.

The tables and access rules exist in Supabase

The property image storage is set up

My staff account has admin access

Build the Property Listing Experience

Build the Real Estate Website

Build the public property listings, search filters and property pages using real Supabase data.

Build the public real-estate experience from the approved plan, using the Supabase structure we just created. Reuse the current website design and components. Do not redesign unrelated parts of the website. 1. PROPERTY GRID Load the published properties from Supabase and show them as property cards. A card shows only what is useful at a glance — typically the main image, the title, the price, the location, the property type and a short bedroom / bathroom summary where that is relevant. Do not put every database field on the card. 2. SEARCH AND FILTERS Implement only the filters approved in the plan. Depending on that plan they are typically some of: a text or location search, property type, sale or rent, a minimum and maximum price, and bedrooms. Filtering must work against the real property data. Once Supabase is connected, do not fake search with a hardcoded sample array. Do not add filtering controls nobody asked for. 3. NO RESULTS Add a clean "No properties match your filters" state with an obvious way to reset the filters. 4. PROPERTY DETAIL Create ONE reusable dynamic property page. Do not generate a separate hardcoded page for each property. Show the image gallery, the title, the price, the location, the approved property details, the description, the amenities if they were approved, and a clear inquiry call to action. 5. ROUTING Use clean property URLs that fit this project, for example /properties/modern-villa-casablanca. Make sure a direct visit to a property URL, and a browser refresh on one, both work in production — not only through client-side navigation. An unpublished property must not be reachable by guessing its slug or id. 6. RESPONSIVE Prioritize property browsing on a phone. The cards, the gallery, the filters and the inquiry call to action must all stay usable on a small screen. When you are finished, tell me which routes and components you created or reused, which filters are live, and how an unpublished property is kept out of the public pages.

IMPORTANT

Hiding a draft property with an if-check in the browser is not privacy. Anyone can read the data the page requested, so an unpublished listing has to be refused by the database itself.

Build the Inquiry Flow

Add Property Inquiries

Let visitors contact the business about one specific property without exposing private inquiry data.

Add the customer inquiry flow to the property detail page, using the trusted submission path we created earlier. 1. CONTEXT The inquiry is tied to the property the visitor is currently viewing, automatically. Never ask the visitor to type or choose a property id. 2. FIELDS Use only the approved fields — typically the customer's name, email, a phone number where it is genuinely needed, and a message. 3. SUBMISSION On submit: validate the input, create a real inquiry through the trusted path, let trusted logic assign the initial status NEW, and preserve the relationship to the current property. Prevent an accidental double submission where that is practical. A public visitor must not be able to choose the internal status, write staff notes, or attach the inquiry to a different property than the one the trusted route already knows. 4. SUCCESS Show a concise confirmation such as "Thanks — your inquiry has been sent." Do not promise an email or SMS reply: notifications are not part of this build. 5. FAILURE Keep the values the visitor already typed where that is practical, and show a useful generic error. Do not display raw Supabase or database errors to the visitor. Tell me how the property relationship is established and where the initial status is set.

Then run the app and check the public side works before you build the dashboard:

The property listings page loads real properties

A filter narrows the results correctly

An empty result shows the no-properties state

A property page opens and survives a refresh

Submitting an inquiry shows the confirmation

Checking the stored inquiry in Supabase is fine while you test. The business itself will use the dashboard you build next.

Build Property Management

Build the Real Estate Admin Dashboard

Create the protected dashboard the business will use to manage properties and inquiries without touching Supabase directly.

Build the protected real-estate Admin Dashboard using the approved authorization model. This is the business's normal operational interface — it exists so nobody has to open Supabase to run the business. 1. ADMIN LOGIN Use Supabase Auth. If this project already has trusted admin authentication, reuse it — do not add a second login system. Otherwise add the smallest secure staff login. Visitors do not need accounts. Only staff sign in. 2. DASHBOARD Show the two sections the business actually works in: Properties and Inquiries. Do not invent analytics. A few genuinely useful counts — published properties, drafts, new inquiries — are fine if they are simple and real. 3. PROPERTY LIST Show each property with its thumbnail, title, price, status and published state, and give clear actions: Edit, Publish / Unpublish, and Mark unavailable. Do not expose database internals such as raw ids, column names or timestamps the business does not need. 4. SECURITY Every admin route and every admin read must be protected by the trusted staff check from the database layer, not by hiding a link in the navigation. A signed-in non-staff user, and a signed-out user, must both be refused. Tell me which routes are protected and where that protection is enforced.

Then sign in with your staff account and check:

The dashboard opens for your staff account

Properties and Inquiries are both there

A signed-out visitor cannot reach the dashboard

Add the Property Editor

Add Property Management

Let authorized staff create, edit, publish and update property listings from the Admin Dashboard.

Build the property create and edit experience inside the protected Admin Dashboard. 1. CREATE Let authorized staff create a property using the approved fields. Do not force every optional field to be filled. 2. EDIT Let staff update the title, description, price, location, property information, status and the other approved fields. Validate the important values. A malformed or negative price must not be accepted. 3. IMAGES Let authorized staff upload property images, remove them, and choose or reorder the primary image if this project's existing pattern supports that cleanly. Use the established Supabase Storage pattern from the database step. Do not build a full digital-asset manager. 4. PUBLISH Keep DRAFT and PUBLISHED genuinely separate. A property must not become publicly visible merely because a row exists — staff publish it intentionally, and unpublishing takes it back out of the public listings. 5. UNAVAILABLE, SOLD OR RENTED Support the smallest status behaviour approved in the plan. When a listing becomes unavailable, either remove it from the normal public search or mark it clearly as unavailable — whichever the approved plan chose. Do not delete a property's history just because it is no longer available. 6. SECURITY Only authorized staff can write a property or touch property media, and that is enforced in the database or on a trusted server path. Do not rely on the admin page simply being hidden. Tell me what a non-staff user gets if they call the property write path directly.

Then check:

Create a property and save it as a draft

Upload images to it

The draft does not appear on the public site

Publishing it makes it appear

Add Inquiry Management

Add Inquiry Management

Show incoming property inquiries inside the Admin Dashboard and let staff track which leads have been contacted.

Add an Inquiries section to the protected real-estate Admin Dashboard. 1. LIST Show the incoming inquiries with the fields staff actually work from: the customer, the property, the date it arrived, and the status. 2. DETAIL Opening an inquiry shows the property it is about, the customer's contact details, their message and the current status. Do not display unrelated database fields. 3. STATUS Use the simple approved workflow: NEW → CONTACTED → CLOSED Staff move an inquiry along it. Do not build a CRM pipeline, assignment rules, or automated follow-up. 4. PRIVACY Inquiry data is private business data. A public visitor must not be able to query, list or read it, and must not be able to change a status. Confirm that is enforced in the database, not only by the dashboard being protected. Tell me where the inquiry privacy rule is enforced.

Then check:

Your test inquiry appears in the dashboard

Opening it shows the property and the customer's message

Its status can move New → Contacted

Run the Full Property Workflow

One pass through the whole business, as the agent and then as a visitor.

Admin — sign in and create one test property:

Title: Modern Villa

Price: $450,000

Location: Casablanca

Bedrooms: 4

Add a few test images, then publish it

Public — open the site as a visitor, in a signed-out or incognito window:

Open the listings and filter until Modern Villa appears

Open it and check the photos and details

Submit a test inquiry

Admin — back in the dashboard:

Open Inquiries and see the new inquiry for Modern Villa

Open it and change New → Contacted

Unpublish Modern Villa

Public: it is no longer a normal published listing

Verify the Real Estate Website

Verify the Real Estate Website

Verify public listings, property privacy, admin management and inquiries before deployment.

Perform a focused verification of this real-estate website. Use test properties and test inquiries only. Do not add features. 1. PUBLIC LISTINGS - published properties are readable - draft and unpublished properties are not exposed publicly - the unavailable behaviour matches the approved plan - each filter returns the correct properties 2. PROPERTY DETAIL - the property route works, including a direct visit and a refresh - the correct images and details appear - guessing the slug or id of an unpublished property does not expose that draft 3. INQUIRIES - a public visitor can submit a valid inquiry - the inquiry is tied to the correct property - its status begins as New - a public user cannot read or list inquiries - a public user cannot set the admin status 4. ADMIN - authorized staff can sign in - staff can create and edit a property - staff can upload and manage images - staff can publish and unpublish - staff can view an inquiry - staff can update an inquiry's status 5. UNAUTHORIZED ACCESS Confirm a public or non-staff user cannot: create a property, edit a property, publish a listing, upload or delete property images, read the inquiry data, or change an inquiry's status. Test the data layer directly, not only the UI. 6. STORAGE - published images load publicly where that is intended - an unauthorized user cannot upload or delete listing media 7. SECRETS Confirm no Supabase Secret or service-role credential exists anywhere in browser code. Return exactly one: REAL ESTATE WEBSITE VERIFIED or: NEEDS ATTENTION Use REAL ESTATE WEBSITE VERIFIED only if the public listing flow works, search and filters work, the property detail works, inquiries work, admin management works, and draft and private data stay protected. If NEEDS ATTENTION, list only the remaining real-estate workflow issues.

Create one final test property, publish it, submit an inquiry and confirm the inquiry appears in the Admin Dashboard before deployment.

Deploy the Real Estate Website

Before pushing to GitHub, check:

The project builds successfully

No .env or other secret files are being published

No Supabase Secret or service-role key is in browser code

You know the production environment variable names

A property URL still works after a refresh in a production build

Push the project to GitHub with Claude Code or your normal GitHub workflow. If it already has a repository, use it.

Deploy on Hostinger

Recommended plan: Business

USED IN TUTORIAL

https://www.hostg.xyz/SHK1P

Hostinger Websites Add Website Node.js Web App

Choose Import Git repository Connect GitHub and select the property website's repository Review the detected framework and build settings Add the environment variables with your project's exact names Click Deploy and wait for the result

IMPORTANT

Add the Supabase Project URL and Publishable key under the names your project already uses. Private server keys stay private — never rename one to a VITE_ or NEXT_PUBLIC_ variable to make the deployment work.

Fix a Failed Website or Web App Deployment with AI

Use this if the Hostinger deployment fails.

/video/fix-a-failed-website-or-web-app-deployment-with-ai

Test the Live Website

First add your live Hostinger URL in Supabase so staff sign-in works in production:

Supabase Authentication URL Configuration

Set the Site URL to your live URL and add it to the Redirect URLs. Then ask Claude Code to update any other production setting that depends on the live address. Then open the live site and check:

Public: the homepage and the property listings load

Public: the filters work

Public: a property page opens and survives a direct refresh

Public: the property images load

Public: submit a test inquiry

Admin: sign in and see that test inquiry

Admin: create, edit, publish and unpublish a property

Security: a draft property stays private

Security: a public user cannot reach the inquiry list

Security: a public user cannot change a listing

Mobile: browsing properties and sending an inquiry both work

Mobile or tablet: the dashboard is still usable

Verify the Live Real Estate Website

Check the complete live property and inquiry workflow on Hostinger before using the site with real listings.

Perform a focused production verification of this real-estate website now that it is live on Hostinger. Do not add features. 1. GITHUB - the approved source is what is actually deployed - no real secret file is committed 2. HOSTINGER - the deployment succeeded - the intended repository and branch are connected - the build and runtime configuration are correct - every required environment variable is configured 3. SUPABASE - the intended project is in use - admin authentication works in production - admin authorization is enforced in production - Storage works - private credentials remain private 4. PUBLIC - published properties load - the filters work - the property details work - the property images work - inquiry submission works 5. ADMIN - property management works - the publication state works - image management works - inquiry management works 6. PRIVACY - drafts remain hidden - inquiries remain private - unauthorized users cannot perform admin operations Return exactly one: REAL ESTATE WEBSITE LIVE or: NEEDS ATTENTION If REAL ESTATE WEBSITE LIVE, summarize: the listings result, the filters, the property detail, the Admin Dashboard, the inquiries, and the deployment. If NEEDS ATTENTION, list only launch blockers.

Publish one final test property on the live site, submit a test inquiry from the public page and confirm it appears in the Admin Dashboard before adding real listings.