How to Hire a Real Estate Website Developer

Most articles on choosing a real estate website developer read the same. They tell you to check the portfolio, ask about timelines, request references, and watch out for vague contracts. That advice could apply to hiring a plumber. It does not tell you whether the person you are about to spend twenty or eighty thousand dollars with understands that a property website is a sales tool with very specific demands: heavy galleries, mobile-dominant browsing, slow connections in second homes and remote regions, and a lead path that has to stay polite while still converting.

I run DignuzDesign, a studio that builds custom property websites on Astro, Webflow, and Cloudflare, and Faraday3D, which produces the architectural renders and virtual tours that end up on those sites. I also built AmplyViewer, an interactive 3D viewer that real estate developers embed directly into their listing pages. That intersection of web technology, 3D visualisation, and property marketing is where I work every day, and it is the angle a generic web developer cannot bring to a real estate project. This article is the filter I apply when a property developer or estate agency asks me whether a vendor they are evaluating is the right call.

What a Real Estate Website Actually Has to Do

Before you can judge a developer, you need to be clear about what the brief really is. A real estate website is not a brochure site with a contact form. It carries thirty to a hundred high-resolution photos per listing, a floor plan or two, sometimes a 3D tour or video, a map, neighbourhood context, and a lead form, all of which has to load fast on a phone over patchy mobile data while a buyer is sitting in their car outside the property.

The National Association of Realtors Profile of Home Buyers and Sellers shows that essentially every buyer uses the internet at some point in the search, and about half find the home they end up buying online. Their most-valued content on those sites is photos, detailed property information, and floor plans, in that order. Zillow Group's Consumer Housing Trends Report shows the majority of searchers are doing this on a mobile device, and a meaningful share now expect at least one advanced media feature, like a virtual tour or drone capture, before they will consider a listing seriously.

Read those two findings together and the brief becomes specific. The website has to deliver heavy visual content quickly to a phone, present a floor plan clearly, and make a 3D or video tour feel like a first-class element rather than a bolted-on iframe. If a developer talks about a real estate project without talking about any of that, they are pitching you a generic website with property data poured into it.

The Portfolio Test: Looking Past the Case Study Screenshots

Every developer's portfolio looks beautiful on their own marketing page. Hero shots, lifestyle imagery, careful framing. That tells you almost nothing about how the site actually behaves once it is in the wild. There are three things I do when I am asked to review a competitor's portfolio for a client.

First, I open one of their live real estate projects on my phone, on a normal cellular connection, and I scroll a listing page. I am watching for the things buyers feel: how fast the first image renders, whether the gallery is touch-friendly, whether the floor plan opens without a separate page load, whether the page becomes janky once a few photos have loaded. Most real estate sites I test this way feel fine on the homepage and fall apart on the listing detail page, which is the page that matters.

Second, I run their public listing pages through Google's PageSpeed Insights and look at field data, not lab data. The relevant metric is Interaction to Next Paint, which Google introduced as a Core Web Vital to measure responsiveness to taps and scrolls. The threshold for a good user experience is under 200 milliseconds. A surprising number of real estate sites built by reputable agencies blow past that on listing pages, because the developer used a heavy WordPress slider plugin and never measured what happens once a buyer starts tapping through fifty photos. If a developer cannot explain how they would handle that, they have not built enough real estate sites under load. There is more detail in our guide on real estate website speed optimisation.

Third, I look at how old their best-looking work is. A portfolio full of sites launched three years ago that still look current is a good sign. A portfolio full of recent launches with no aged work is either a young studio or a studio that loses clients quickly. Both are worth asking about directly.

Stack Choices: Why the Tooling Matters More Than the Pitch

When a developer pitches you, they will usually skim past the question of what they will actually build the site on, because most clients are not technical and the answer feels like a detail. It is not a detail. The stack choice is the single largest determinant of whether your site will be fast, maintainable, and affordable to keep running.

WordPress remains the default. For a small agent with a handful of listings pulled from an MLS feed, it is often fine, and the plugin ecosystem covers most needs. The trade-off is that WordPress sites accumulate plugins over time, and each plugin adds JavaScript that slows down the listing pages. I have inherited WordPress real estate sites where simply removing four plugins moved the Core Web Vitals score from failing to passing, without changing a line of the design. If your developer is proposing WordPress, ask them how they will keep the plugin footprint small and what their position is on page builders like Elementor, which are particularly heavy.

Webflow is the middle path. It produces clean code, the visual builder is genuinely powerful, and for property developers showcasing a finite set of projects rather than a constantly updating MLS feed, it is often the right answer. The catch is that Webflow has hosting and CMS limits that matter once you cross a certain scale, and those limits should be discussed before the contract is signed, not after.

Headless and static stacks, including Astro, are where I have moved most of my work for property developers who care about speed. The site is rendered ahead of time, delivered from a CDN, and the only JavaScript that runs is what is genuinely needed for interactivity. Listing pages load almost instantly, even with heavy galleries, because images are properly optimised and lazily loaded. The trade-off is that headless requires a developer who actually understands modern build pipelines, not someone who has only worked in WordPress. Our piece on Jamstack property developer websites covers the reasoning in more depth.

There is no universal right answer. There is, however, a right answer for your specific situation, and a developer who cannot articulate why they are recommending one stack over another for your project, in your business context, is not bringing judgement to the engagement. They are bringing a template. That alone is reason to look elsewhere, and the broader argument for going custom is laid out in why custom real estate websites outperform template solutions.

How They Treat Visual Content: The Make-or-Break Signal

If I had one filter to apply to a real estate web developer, this would be it. Real estate is the most image-heavy category of web work outside of fashion and travel. The way a developer talks about visual content tells you immediately whether they have built property sites before or just put property data into a normal site.

Listen for these things in your first conversation: do they mention image optimisation formats like AVIF and WebP, lazy loading, a content delivery network, responsive image sizes, and gallery performance under load? Do they distinguish between the marketing photos that get featured on the homepage and the listing detail gallery, which has its own performance profile? Do they have a position on whether floor plans should be inline SVG, image files, or interactive components? These are not technical trivia, they are the things that determine whether your buyer waits two seconds or twelve to see the kitchen.

The other half of the visual story is video and 3D. The market expectation for these has shifted, and the share of buyers who consider an advanced media feature essential keeps rising. The cheap option is to embed a YouTube video and call it done. The serious option, which I build for clients through Faraday3D and AmplyViewer, is to make 3D walkthroughs a native part of the property page, so that a buyer can rotate, walk, and inspect rooms without being kicked into a third-party viewer that pauses the rest of their journey. A developer who treats virtual tours as an iframe afterthought has not thought hard enough about how buyers actually use these sites.

Timeline and Budget: What Is Real and What Is Theatre

The figure that gets repeated in most developer-hiring articles, four months and roughly twelve hundred hours, is genuinely true for a full custom build with MLS integration, multiple user roles, and a content management system that admins will actually use. It is not true for most projects. A property developer who needs to present a single project with twelve units can have a site that performs brilliantly in three to six weeks on Webflow or Astro, with no compromise on quality. An estate agent who needs basic listing pages backed by a property feed sits somewhere in between.

Watch for two specific kinds of theatre in proposals. The first is an inflated discovery phase. A two-week discovery is fine. A six-week paid discovery for a project where the requirements are already obvious is the agency padding the engagement. The second is a phantom "design system" sub-project. For a website with twelve to thirty unique pages, a real designer needs no formal design system, because the components are not numerous enough to justify the overhead. If the proposal carves out a separate line item for design tokens, brand systems, and component libraries, ask what concrete deliverable that produces and how it changes the final website.

Budget transparency matters more than the headline number. A developer who says "between twenty and eighty thousand depending on scope" without specifying what each band actually includes is not being honest, they are leaving themselves room to upsell. A serious proposal breaks down what is fixed and what is variable, and which features can be deferred to a phase two without compromising the launch. Our detailed look at Webflow development cost walks through one of those breakdowns in practice.

💻 Let us help you create a stunning online showcase for your projects that works seamlessly across all devices. Ready to amplify your real estate business? 👉 Explore AmplyViewer now

Red Flags That Actually Predict Trouble

The standard red flags list in most articles is correct but obvious: no contract, no portfolio, suspiciously low price. The ones below are the patterns I have actually seen go wrong on real estate projects, drawn from clients who came to me to rescue or rebuild work that failed the first time.

• They cannot show field-data Core Web Vitals from their existing work. If a developer says their sites are "fast" but cannot show real PageSpeed Insights data with actual scores on a recent client project, they are guessing. Almost half of all websites fail Core Web Vitals in field data, and real estate sites with heavy galleries fail at higher rates. A developer who is not measuring will not be optimising.
• They quote SEO as a deliverable without specifics. "We handle SEO" is meaningless. Ask what they will configure: structured data for listings, sitemap generation, meta tag templating per property, image alt text strategy, performance work tied to ranking. A developer who cannot give specifics is treating SEO as a checkbox.
• They have no opinion on which CMS your team should use. The CMS is the tool your marketing person will use every day after the developer is gone. If the developer has no opinion, they are not thinking about your post-launch life, they are thinking about delivery.
• They quote a 3D tour as a feature without explaining the integration. Anyone can embed Matterport. The question is whether the tour pauses the page, whether it preloads correctly, and whether it works on a mid-range Android phone, which is the majority of mobile traffic worldwide. If the developer has not thought about that, the tour will be a checkbox feature that buyers do not actually use.
• Their proposal makes no mention of analytics and measurement. If they are not setting up event tracking on lead forms, gallery interactions, and tour opens, you will have no way to know what works after launch. That is not a maintenance item, that is launch scope.

The Questions That Separate Good Developers From Average Ones

Most articles publish a long list of questions to ask vendors. The list below is shorter and aimed at the answers that actually predict competence.

Show me one of your real estate sites on your phone right now

Watch how they navigate it, what they show you first, and what they apologise for. A good developer will pull up a listing detail page, scroll the gallery, open the floor plan, and point out specifics. A weak developer will show you the homepage and click through to the team page.

What is the slowest page in your last real estate project, and what is on it?

Every site has a slowest page. A developer who knows immediately which one it is, and what they would do about it given another month, has been paying attention. A developer who says they are all fast is not measuring.

How would you handle a listing page with eighty images?

This is a question about responsive images, lazy loading, image formats, and gallery architecture, all at once. The answer should mention at least three of those. Compare what they say with the patterns in our property listing design best practices guide.

What would you push back on if I asked for it?

A developer who has built enough real estate sites will have opinions about features that look good in a brief and perform badly in production. Common ones: full-screen video backgrounds on a homepage, gated lead walls before the property details, autoplay tours. A developer with no pushback either has no experience or no spine.

Who will own the code, the design files, and the domain after launch?

The answer should be: you. If any part of the answer is unclear, get clarification in writing before signing. This question is straightforward and there is no good reason for it to be answered with anything other than a direct yes.

Working With a Solo Studio Versus an Agency

Property developers and agents often default to thinking that an agency is safer than a solo operator, and there are situations where that is true. A national franchise rolling out fifty regional sites needs project management capacity a solo studio cannot provide. A boutique developer launching one prestige project with a six-figure marketing budget does not.

The honest trade-off is this: agencies have backup and process, but the cost is layered. You pay account managers, project managers, designers, and developers, and the work passes through each layer. A solo studio gives you direct access to the person actually building the site, faster decisions, and tighter quality control on small projects, at the cost of capacity if you suddenly need ten new pages next week. For a single property developer site or a focused agency rebuild, the solo route is often better value, provided the person on the other side has the breadth to handle design, development, performance, and a 3D pipeline without subcontracting too aggressively.

The broader question of how to evaluate any kind of website partner, agency or solo, is something I covered separately in our piece on choosing a web design agency. The principles overlap, but the specifics of real estate, which is what this article is about, are the part that generic agency-selection advice misses.

What Happens After Launch (And Why That Conversation Matters Before You Hire)

The day the site launches is the start of the relationship, not the end. Property feeds change format. Photos accumulate. New listings get added. The lead form integration breaks because the CRM updated its API. Plugins need updating. A new buyer-side feature like a finance calculator gets requested.

Before you sign anything, ask the developer two specific things. First, what is the realistic retainer cost to keep this site healthy for the next year, in their experience with similar clients. Second, what is the documented handover, in writing, that would let another developer pick up the project if your studio became unavailable. If both answers are clear and specific, you are working with someone who plans for the whole life of the site. If they are vague or defensive, you are working with someone who treats launch as the finish line.

The handover question matters particularly for property developers, because the development cycle of a real estate project, from launch to sell-out, often runs longer than a typical developer engagement. The site that launches with the first phase needs to live through the last unit being sold, which can be two or three years. A site that no one else can maintain is a liability disguised as an asset. The right developer treats handover documentation as part of the deliverable, not an afterthought.

Frequently Asked Questions

How much should a real estate website actually cost in practice?

For a single property developer presenting one project with under fifty units, expect five to fifteen thousand for a well-built Webflow or Astro site, more if 3D tours, custom floor plans, or animation are part of the brief. For an estate agency with an MLS feed and a few hundred listings, ten to forty thousand for a serious headless build is realistic. Anything quoted above fifty thousand should come with a detailed line-by-line breakdown that justifies it, not a vague reference to "enterprise complexity." The numbers also depend on geography: rates in Western Europe and North America run roughly two to three times higher than in Central and Eastern Europe for equivalent quality.

Do I need a developer or can I use a template?

A template works if your needs are genuinely simple: a few static pages, a contact form, no listing feed, no 3D, no concern about Core Web Vitals. The moment you cross any of those thresholds, a template starts costing you in lost leads, slow pages, and visual mediocrity that buyers feel even when they cannot name it. The article I wrote on why custom real estate websites outperform template solutions goes through specific scenarios where the trade-off shifts.

How do I know if a developer's portfolio is real or made up?

Visit the live URLs yourself, not just the case study screenshots. Check who the site is hosted by, who is named in the footer, and whether the developer is listed as the builder anywhere on the live site. If they cannot provide live links to projects they claim to have built, the safest assumption is that they were a junior contributor to those projects, not the lead.

How long should I expect the entire process to take?

For a focused project developer site: four to eight weeks from kickoff to launch. For an agency site with a property feed: eight to sixteen weeks. For a custom enterprise build with multiple integrations and many user roles: four to six months. Anyone promising significantly less is either using a heavily templated solution or is going to compromise quality. Anyone insisting on significantly more is padding scope.

What is the single biggest mistake property clients make when hiring a developer?

Hiring on portfolio aesthetics without checking how those portfolio sites actually perform. A beautiful site that takes nine seconds to load on a phone loses leads silently, and the client almost never notices, because they themselves are on fast home internet. The buyer who bounces never tells anyone they bounced. Always test on a mobile device, on a slower connection, and look at field data, not lab data. The conversion implications are covered in detail in our real estate web page design conversion guide.

Closing

Hiring a real estate website developer is not really a procurement decision, it is a judgement about whether the person across the table understands property the way you do. The questions, the portfolio test, the stack choices, the visual content handling, all of those are proxies for one underlying thing: does this developer think like a property marketer first and a coder second. If they do, the technical details will follow. If they do not, no contract clause will save the project from being a generic website with property data poured into it. Most of the rescues I have done over the last few years started exactly there, with a client who hired on portfolio prettiness and discovered six months later that the site was not built for the work it had to do.