Boffin Coders does real estate website design for estate agencies with three to thirty branches whose CRM gave them a template site. The site reads your listings from Reapit, Alto, Street, Rex or VaultRE through their published APIs once access is approved, puts property pages that rank on your patch on your own domain, and writes every enquiry back to the right branch. The CRM stays. The front end stops embarrassing you.
Builds from US$4,000. Developers at US$12-30 an hour, or from US$2,000 a month full time.
3-30
Branches
The agencies this is built for
Your CRM
Is the source of truth
We read from it. We never replace it.
Yours
Code, domain, data
In your accounts from the first commit
2017
Shipping software since
Same owners, same team
Before anything else on this page: what exists today, what is design work, and how we build the CRM side of your new site. Real estate website development is a sector where a vendor list reads like experience, so we label ours.
The riskiest part of leaving a template site is the old addresses that portals, Google and past emails still point at. We rebuilt our own 10,723-page site on Next.js and lost none of them, counted from its sitemap before and after the move. The method is written up in full.
Read how the rebuild kept every URL →A property website interface and a property app interface, both designed in Figma, plus brand and brochure work. These are designs, not software, and each is labelled as a design project where it appears further down.
See the property app design →Every system on the list below has a documented interface. We read its documentation first, build the listing read and the enquiry write-back against the vendor’s sandbox where one exists, and confirm access before we commit to a launch date. Much of our client work is under NDA, so we walk you through the architecture and the access plan on a call.
What we can also show is the same work in other sectors, applied to property pages. Neither of these is an estate agency, and neither is presented as one.
A property site is a dataset turned into pages: one page per listing and one per area, each from a template. timezones.in, our own site, has the same shape. It had 10,723 server-rendered pages from six templates when we moved every one of them to a new framework without losing a URL, counted from its sitemap before and after the move. The work that mattered most was removing near-duplicate pages, which is exactly what goes wrong when every area page differs only by its place name.
Area and branch pages are local search work, and that we have done for paying clients. For a cleaning company serving fifteen nearby towns we built location pages, one per town, and rewrote the service pages around what people search for. For a painting company we rewrote the service pages, fixed speed on a phone and completed the Business Profile. Your area pages and branch pages would get the same method.
Studios building for estate agents: we build this under your brand, on a fixed two-week sprint, and your client never hears from us. That is our white-label development for agencies.
The CRM is usually fine. It is the website and app that came with it, or the one an agency built once and left, that loses the buyer, the vendor and the lead. Four things come up on almost every call.
It came free with the software, it looks like every other agency on the platform, and the competitor in the next town has the same one. Buyers cannot tell you apart.
A search for "3 bed house in your town" finds the portal, not your site. The enquiry goes through the portal, the portal owns the relationship, and you pay for the lead you generated.
Template sites load a whole CRM widget to show one property. Buyers on a train do not wait. The listing page is the one page that has to be fast.
Valuation requests in an inbox, viewing requests in another, nobody sure which negotiator picked up which. The lead should land in the CRM against the right branch, automatically.
Estate agency website design usually means a template from the CRM vendor. This is the other kind, an estate agent website with CRM integration: listings that arrive on their own, pages that rank on your patch, and enquiries that land in the CRM against the right branch. The CRM you already run stays the source of truth throughout, and the same data can feed an agency app later.
Every property, branch, negotiator and status is read from the CRM through its API and kept current. A new instruction is on the site within minutes, and a sold one comes off. Nobody re-keys anything, and the CRM stays the only place data is edited.
Interfaces and tools:
Key Features:
One fast, indexable page per listing and per area, with the structured data search engines read, so a search for a street or a postcode can find you and not only the portal. The listing page is the one page that has to be fast, so it is server-rendered in Next.js with no CRM widget in the way. Moving off the template site keeps every old URL working, and this is how we prove it.
Interfaces and tools:
Key Features:
Each branch with its own page, its own listings and negotiators, and its own Google Business Profile link. Valuation requests, viewing requests and enquiries are written into the CRM against the right branch and property, with the source recorded, so the inbox stops being the system. This is the part that makes it an estate agent website with CRM integration rather than a brochure with a contact form, and the part a template site usually leaves out.
Interfaces and tools:
Key Features:
Not a valuation robot and not a chatbot that promises viewings it cannot book. Three jobs where a model saves a negotiator an hour, every draft reviewed before it goes anywhere, and the CRM record always the source of truth.
We do not train models. We wire one into your workflow where it is worth the review.
Each of these is optional, priced on its own, and switched off by default. If an agency wants none of them, the site and app work exactly the same. If it wants one, it lives behind the same login and writes to the same CRM as everything else.
A first draft of the description from the facts the CRM already holds (beds, baths, EPC, tenure, features) for the negotiator to edit. It saves the blank page. It does not publish unreviewed.
Incoming enquiries classified as valuation, viewing, general or spam, and assigned to the right branch and negotiator in the CRM. A human still replies. The model only sorts.
Drafted from your own sold data and public sources, reviewed by you before they go live, refreshed on a schedule you set. Labelled as a guide, never as a valuation.
From the CRM record. Nothing re-typed.
A three-bedroom semi-detached house with a private garden and off-street parking, offered freehold. Close to excellent schools Five minutes' walk from Didsbury village. EPC rating C.
Illustration. Property and names are invented.
The life of one listing, from the moment a negotiator adds it to the CRM to the moment a vendor's enquiry lands back in it, plus the one step that happens only once, when you switch. Each card says where that step stands here: done on our own site, done for clients in other sectors, or how we build it for your CRM.
The negotiator adds the property in Reapit, Alto, Street, Jupix or whichever CRM the agency runs, exactly as today. The website reads it through the CRM’s documented API or feed, on a schedule and on webhooks where the CRM sends them, so nobody types it twice. The read is tested against the vendor’s sandbox first, and every field the property and area pages need is checked before launch.
The listing becomes a server-rendered page on your own domain, with photos sized for a phone and the RealEstateListing structured data that search engines read. Turning one dataset into thousands of fast pages from a handful of templates is what we did on timezones.in. The pattern is done on our own site. A property site uses the same method, with listing fields in the templates.
Every listing also appears on the page for its area, street or postcode, which carries a guide written for your patch, so a local search can find you and not only the portal. Location pages written for one town at a time are work we have done for a paying client, a cleaning company, not an estate agency.
Most CRMs already send listings to the portals, and when yours does, that is left alone. Where a listing has to reach a portal from outside the CRM, the site sends it in the portal’s own format, such as the Rightmove Real Time Data Feed or REAXML. Each portal approves each feed, so the approval request goes in early and the feed is tested against the portal’s specification before it goes live.
A valuation request, a viewing request or a general question is written into the CRM against the right branch, property and negotiator, with its source recorded. The inbox stops being the system. This is the step a template site usually leaves out, and we test it against the CRM’s sandbox, branch by branch, before launch.
When the agency moves off its template site, every URL that portals, Google and old emails point at is mapped to its new page before launch and checked after it. We did this for all 10,723 pages of timezones.in and lost none of them. If the site move is all you need, without the CRM work, we take it on as a website migration company, with the same URL list and checks.
What the website needs from each CRM, and how a developer gets access to it. Access is the part that sets the timeline, so it goes into the scope before any design work starts.
Reapit publishes its developer platform, Reapit Foundations, so a developer can sign up, read the documentation and build against a sandbox. A site that reads live listings in production needs its app listed on Reapit’s marketplace, where the agency installs it. We build the Reapit website against that API, and the marketplace listing is a step in the plan, not an afterthought.
Alto’s API is a partner API, opened through Alto and Zoopla. We apply with you, and approval can take two to six weeks, so the request goes in during the first week of scoping. Once access is open, an Alto CRM website works like any other on this page: listings read from the CRM, enquiries written back per branch.
Street.co.uk works with partner integrations, so access is agreed with Street before the build starts. We confirm what the interface returns for listings, branches and new leads before we quote a timeline, and then build to it.
Jupix provides an XML feed, or API access, through the agency’s account manager. We ask for it with you and check that it carries every field the property and area pages need. If only the feed is available, enquiries go back by the route Jupix supports, and the scope says which one.
Rex, VaultRE, Dezrez, AgentBox and Box+Dice work the same way, and every system is on the full integration list with its market. Each card follows the same method: access confirmed first, the build tested in the CRM’s sandbox, and enquiries checked branch by branch before launch.
API, GraphQL and feed integrations only. Every name here has a documented interface, published by its vendor. None is marked as a past project, because only work a buyer can open is shown here: we build against the interface you run, test it in the vendor’s sandbox, and the quote sets out each step. Market in brackets where a system is regional.
The source of truth. Listings read from here, leads written back.
Where a listing must be pushed to a portal from outside the CRM.
Where it is, what is nearby, what it is worth.
The listing page is the product. The media is most of it.
Sales viewings, lettings applications, deposits, rent, and the affordability question.
A buyer or tenant proves who they are before an offer or a tenancy goes ahead. The check has to be in the flow.
Reaching the buyer or tenant where they are, and logging it. The pieces every agency app needs and none should build from scratch.
What worked, by branch, by source.
Thousands of listings, filtered in under a second.
Status of every name above: documented interface, published by its vendor, ready to scope. Not on the list? If it has a documented API or feed specification, it is a scoping question. If it does not, we say so on the call rather than promise it.
Nothing exotic. A stack we have run for years, chosen so a listing page loads fast on a phone and so any competent developer can take it over from you later.
In USD. Hourly and monthly rates move with the stack and the seniority, from a junior on routine work to a senior on complex builds. Nothing is quoted outside them, and if the number does not work for you, you have saved yourself a meeting.
Websites and apps that read listings from the CRM your branches already use, and write enquiries back. Take the build, or hire the developers and direct it yourself. Studios building for estate agents: we build this under your brand, on a fixed two-week sprint.
US$12-30 an hour depending on the stack, or from US$2,000 a month for a dedicated developer. Shortlisted profiles within two working days, and whoever you pick starts within one to two weeks.
The questions that come up before anyone books a call: which CRMs we can read from, what we have built and how we build the rest, what happens to the site you have now, and who owns what when it is done.
No, and that is the point. The CRM stays exactly as it is and stays the source of truth. We read listings from it through its API and write leads back into it. Your negotiators change nothing about how they work.
Not answered here?
Two of these are interface designs, labelled as design projects. Nook is a home loan platform we built. An agency site reading from a CRM follows the six steps set out above, from the listing read to the enquiry write-back.
Twenty minutes. We look at both, tell you what the CRM's API can and cannot give you, and quote a scoped build, not a monthly package.