Property products are media-heavy and decision-slow. A listing is thirty photos, a floor plan, a map, a document pack and a set of numbers that must agree with each other. The buyer, meanwhile, takes four months and visits the site seventeen times.
Both facts shape everything below.
The build is media handling
Image pipelines, not image tags. Uploads arrive from agents’ phones at whatever size the camera produced, and the gallery still has to open instantly on a commute. That means derivative generation, sensible formats, real dimensions in the markup and a CDN policy decided early rather than bolted on when the hosting bill arrives.
Maps are the second weight. Clustering, boundary search, draw-your-own-area — all fine, all expensive if the query layer was designed for a list view and asked to do geography later.
Document packs are the third: leases, surveys, title reports. Storage, access rules and a viewer that does not force a download are the whole feature.
Search is the product
Nobody browses a portal. They filter it. Filter design decides how the data is indexed, and getting that backwards is the most common reason a property site feels sluggish at a few thousand listings.
We plan the filter set with the people who take the phone calls, because their first question to a caller is the filter your users need first.
A four-month decision needs different marketing
Campaigns that measure a same-session conversion will always look like a failure here. The channels that work are the patient ones:
- Search — location and property-type pages that compound over quarters, planned as part of the SEO track
- Saved searches and alerts, which are product features doing marketing work
- Email and CRM, where a nurtured buyer stays reachable for the whole decision window
- Paid, used to fill the top of a funnel you can already measure — see performance advertising
Who the two audiences are
Almost every proptech product serves a consumer and a professional at once: the buyer or tenant, and the agent, landlord or manager who lists. They want opposite things from the same screen. We design them as two products sharing a database, which is more work up front and much less rework later — the same principle the UI and UX track applies elsewhere.
Other sectors are on the industries page.