Culver Realty Group: How We Rebuilt an Ormond Beach Brokerage Site With a Daily Listing Sync

Web Development · 5 min read · October 30, 2026

By Heath Daniel, Founder & AI Platform Architect, HD Connex · Published: October 30, 2026

Direct answer: Culver Realty Group is a full-service real estate brokerage and property management company in Ormond Beach, Florida. HD Connex rebuilt its website as a React and FastAPI application deployed to Railway, with an admin dashboard, listing import, lead capture and a daily listing sync, shipped between September 8 and October 8, 2026.

Culver Realty Group is a full-service real estate brokerage and property management company in Ormond Beach, Florida. HD Connex rebuilt its website as a React and FastAPI application deployed to Railway, with an admin dashboard, listing import, lead capture and a daily listing sync, shipped between September 8 and October 8, 2026.

What the brokerage gets day to day

• Listings that stay current: a sync runs every morning, updates prices, adds new listings and recent sales, and marks sold and off-market listings as such, without deleting anything.
• Leads in one place: the public inquiry form posts each lead with the listing it came from, and the admin moves it through new, contacted and closed.
• A conventional codebase: a React frontend and FastAPI backend in a repository, built with a Dockerfile and deployed to Railway.

What the site covers

The public site at culverrealtygroup.com, titled Culver Realty & Property Management, covers buying and selling residential property, sourcing and managing investment properties, property management with tenant screening and owner reporting, and a home-watch service for second-home owners. Its navigation runs to eleven items, from sale and rental listings to property management and the team. The build began with recovery, not design.

The one hard problem: there was no codebase

The site existed as a preview deployment on the Emergent platform, and that preview was the only artifact we had to work from. So the first job was recovery. We captured the live HTML, the compiled CSS and the API responses, pulled the frontend source back out of the live bundle's source map, and rebuilt the project around it: every page, the admin dashboard, the theme, and the seed data, which came to 28 listings (14 live, 14 sold) and 36 images captured from the live site. The only things left out were the platform's own analytics and editing instrumentation.

The baseline commit on September 8, 2026 was that recovered site plus its Railway deploy config. The same day we fixed what recovery had exposed: every property coordinate was corrected and the map tightened, the property model learned to accept a null price, and real listing ingest, image storage and a photo backfill replaced the seed-only data.

What we built, and what it runs on

The frontend is React 19 on Create React App with craco, Tailwind 3, react-router 7, framer-motion and TanStack Query. The backend is FastAPI with PyJWT authentication and a JSON file store by default, with MongoDB as an option. In production it is one process: a two-stage Dockerfile builds the React app on Node 20, then a Python 3.12 image runs uvicorn, serving the built frontend and the API from the same origin. Deploys are manual with the Railway CLI. Photos written at runtime go to a Railway volume so they survive redeploys.

One early container build taught a lesson: the API base compiled to the literal string undefined/api because the build depended on a gitignored env file that was absent from the upload context. The Dockerfile now sets the backend URL to an empty string explicitly, so the app always calls /api same-origin.

The admin sits behind a JWT login. Its dashboard shows live listings, drafts, new leads, failed imports and recent imports and leads, and properties are created and edited there. The import screen takes a listing URL, shows a preview, and publishes it; with an Apify token configured, the photos are copied onto the site's own storage.

Keeping listings current: the daily sync

The sync shipped on October 8, 2026. It runs inside the web process every morning at 6am Eastern and reads the agents' public listing profiles through Apify. From there it updates prices on live for-sale listings and adds new ones, adds recent sales where the agents represented the seller over the last two years, marks listings pending or sold when they drop off the profiles, and re-checks every live rental for price changes, retiring the ones no longer for rent.

The best design choice: nothing is deleted. A listing that disappears goes off-market only after two runs in a row, and drafts are never touched, so one bad morning at the source cannot wipe the inventory. New rentals still arrive through the admin import screen, because the brokerage files rentals under the company and the agent profiles never list them. The dashboard shows the last run and has a Run now button; per the project README, the sync costs a few cents a day.

Footage, motion and SEO

Drone footage went in on September 8 with a shared page-hero component, and by September 16 every page hero was footage, from an Intracoastal aerial on the home page to a live-oak canopy drive on Sellers. The same day we ran a motion pass across the public site against a written spec: one set of easing, duration and spring tokens, crossfade route transitions, staggered reveals, a single CSS hover recipe and hero parallax, across the twelve marketing pages, listing detail and the 404.

On October 8 we added server-rendered meta tags, JSON-LD and page snapshots, plus robots, sitemap and llms.txt files. The FAQ copy is shared between the FAQ page and the pre-rendered FAQPage structured data, so the two can never drift apart.

What shipped, and when

Thirty-four commits: 14 on September 8, 2026 (recovery baseline, deploy config, footage heroes, listing ingest, data fixes), 18 on September 16 and 17 (footage on every hero, the motion pass) and 2 on October 8 (the daily sync and the SEO layer).

What we would do differently

The motion spec said reduced motion would be respected everywhere, and the next day we shipped a commit that turned motion always on and stopped honoring the operating system's reduce-motion preference. Ignoring that preference has a real cost for motion-sensitive visitors, so that question belongs before a motion pass, not after it. We would also set build-time variables in the Dockerfile from the first commit, so the undefined/api fix is never needed. Create React App came with the recovered code, and the React team deprecated it for new apps in 2025, so a move to a current build tool belongs on the list. And while a JSON file store was a reasonable default for a recovered site, a brokerage that keeps importing and syncing listings will typically want the database option on sooner rather than later.

Need a site that keeps itself current?

HD Connex builds websites like this one from Daytona Beach for businesses across Volusia County and Florida, Ormond Beach included. Every engagement starts with a free consult and a fixed quote before any build.

Topics: Project Story, Real Estate Websites, React, FastAPI, Railway, Ormond Beach

Related: Web design for Ormond Beach businesses · Website design services · Everything HD Connex builds · Book a free consult · Industry solutions (Daytona Beach) · Website design packages

← Back to blog · Industry solutions