Realtor Website Builder

Build a website that makes the agent's real strengths visible and gives a visitor a useful next step. Deliver the implementation and test the inquiry path; a polished screenshot alone does not finish the job.

Establish the brief without a long questionnaire

Use the conversation, existing website, supplied brand kit, and authorized files first. Ask only for missing information that changes the build. Continue independent research and a local draft while waiting.

Capture:

• Agent and brokerage identity, actual service area, audience, specialty, and verifiable story or credentials.
• One primary action: request a seller preparation plan, ask about a property, download a useful guide, or book a conversation. Choose it to match the real offer and traffic source.
• Approved portrait, logo, property or community photos, asset rights, testimonials, and examples of the agent's own voice.
• Existing domain, current website and host, chosen destination host, booking URL, lead destination, and the owner's access to each. Keep URLs and identities exact; do not substitute a similarly named account.
• Scope and existing authorization for publication, domain connection, account writes, test submissions, and paid services. Installing this skill grants none of those actions by itself.

Make a brief with verified facts, open questions, and proposed decisions. Keep unavailable proof visible in the working draft; omit it from the published page rather than inventing it. Do not make the agent learn hosting terminology to approve a visitor experience.

Research before choosing the page

1. Inspect the current site and actual visitor journey when one exists. Identify what should be retained and the first observable failure.
2. Study a small, relevant set of original public agent sites and local buyer or seller questions. Record URLs, review dates, useful design or content patterns, and their limits. Popularity or a creator's revenue claim does not establish conversion performance.
3. Research local facts through primary sources appropriate to the claim. Give market figures a geography, period, definition, and source; do not reuse an old number as current. Avoid declaring a neighborhood safe, suitable for a protected demographic, or guaranteed to appreciate.
4. Translate the research into an original page architecture and a short positioning statement grounded in this agent. Do not copy a competitor's prose, testimonials, photos, or identity.

Use only listing data and imagery the agent is permitted to publish. If MLS or IDX data is requested, inspect the actual license, feed, brokerage requirements, and supported integration. Use the user's permitted authenticated session or exports for research when available; never promise universal MLS access or fabricate a live listings feed. Keep a source register for factual claims and an asset-rights register for published media.

Design the visitor experience

Map source → useful page → inquiry or booking → recorded lead → confirmation → agent's next action. Give each handoff an owner and observable evidence.

Start with the smallest complete site that serves the brief:

• First screen: verified agent identity, audience or place, concrete offer, and clear main action.
• Useful substance: the agent's process, relevant local or property guidance, and genuine proof. Add pages only when they answer a distinct visitor need.
• Action: a short form or the exact booking destination; a working phone or email path can be a secondary option.
• Trust and required information: brokerage identity and applicable notices, attribution, privacy information reflecting actual collection, and a clear description of the next step.

Choose a coherent type, color, spacing, and image system from the real brand kit. Use authentic photos and specific local context instead of generic luxury imagery. Make mobile text readable, headings fit their actual columns, and controls usable by keyboard. Check form labels, contrast, visible focus, image alternatives, and error messages. Do not add AI implementation details to public copy unless they help the visitor decide.

Show a rendered first screen and action flow before committing to a full visual direction. Incorporate the user's feedback into the same implementation.

Implement the complete handoff

1. Use the chosen environment. Inspect the existing project or builder and its instructions. Use currently documented APIs and callable tools; honor the user's host choice. Explain a real limitation before proposing a different provider. Do not create paid accounts or silently choose a new stack.
2. Build the pages and assets. Use responsive layouts and optimized media. Add accurate page titles, descriptions, canonical URLs once known, and social previews. Put only verified business details into structured data; do not promise rankings.
3. Connect capture. Inspect the actual CRM or form provider schema and account connection. Collect only needed fields, persist a submission before declaring success, and preserve source, campaign, page version, timestamp, and channel consent where relevant. Keep server secrets out of client code and deliverables.
4. Handle failure. Add useful validation, duplicate-submit protection appropriate to the platform, error and retry states, spam controls, and a fallback contact path. Treat a failed CRM write as failure even if the browser displayed success.
5. Connect delivery. For a guide, make the real asset available and verify its download or authorized delivery. For an inquiry, route it to the right owner and show a truthful confirmation. Prepare follow-up drafts and tasks; do not enroll a visitor in unrelated marketing merely because a form was submitted.
6. Connect booking. Verify the exact calendar owner and event, available times, timezone, duration, and confirmation behavior. An outbound scheduler link is acceptable when an embed adds friction. Opening the calendar is not a completed booking.

If a connector, API, or browser capability is unavailable, complete the independent local build and prepare the exact field mapping or authorized manual handoff. Label simulations and unresolved connections. Do not create a fake working form to hide a missing backend.

Preview and publish to the chosen host

Run the project's relevant checks and inspect the rendered desktop and mobile pages. Test navigation, downloads, phone/email links, empty and invalid forms, retries, and the recorded inquiry path. Use a sandbox or the user's designated test identity and destination; obtain any missing permission for real writes or notifications. Never use a real prospect as a test.

Prepare the exact deploy target and a reviewable result. Follow the user's existing authorization for publication; ask only if required authority is missing. Confirm the provider's actual deployment status and open its public URL in a fresh session. A local preview, saved HTML file, build success, or deployed placeholder is not the finished public site.

Connect GoDaddy with a simple user experience

Tell the user: “Sign in to GoDaddy in the in-app browser, then ask me to connect your domain to this website.” Have the owner complete sign-in and identity verification personally. Inspect the available browser controls and permitted session; do not ask for passwords or one-time codes in chat or promise the current app can control a browser if it cannot.

Keep the technical work with the assistant:

1. Verify the exact domain, authoritative DNS provider, selected host, and healthy destination deployment. GoDaddy registration does not prove GoDaddy controls the DNS.
2. Read the live host's domain instructions and capture its exact required records. Snapshot existing records and check email dependencies, including mail hostnames that might share a website record.
3. Prepare the exact before/after change with a plain-language purpose and restoration plan. Check the scope against existing authorization; when approval is needed, show this concrete change after the site is ready.
4. Apply only authorized website-connection changes through supported controls. Preserve email and unrelated services. Have the owner complete any security verification. Do not change nameservers, transfer the domain, or buy an upgrade as an incidental shortcut.
5. Confirm host verification, DNS resolution, HTTPS, the chosen root/www behavior, and the actual site content. Re-test inquiry and booking from the custom domain. Report propagation or certificate work as pending until observed complete.

Read domain-connection.md during domain work for the record plan and verification receipt. If controls are blocked or missing, provide the exact supported manual steps from the current provider documentation and finish all independent checks; do not route around the restriction.

Deliver and improve

Provide the working public URL or precisely labeled preview, editable source or builder location, lead destination and owner, booking destination, source and asset registers, and a short verification receipt. Separate built, published, custom-domain verified, inquiry recorded, asset delivered, and booking confirmed. Name the remaining dependencies without claiming a guarantee of leads.

Define the first useful measurement window and funnel events by source. Count submitted inquiries, qualified conversations, scheduled appointments, and attended appointments separately. Use real feedback and observed failures to choose the next change; small traffic does not justify declaring an A/B winner. Scheduling recurring monitoring requires its own user request.