Real estate app development for brokerages, portals and property managers.
We build listing and search platforms, property management systems, agent and tenant portals, and the integration layer that keeps the data current: MLS, RETS, IDX and direct portal APIs.
Property products fail on data freshness far more often than on features. We will tell you which listing route your market actually supports on the first call, and scope the build to what that route can keep fresh.
- 120+Projects delivered across 12 countries since 2012
- 100+Senior in-house engineers, six countries
- 2 to 4 weeksTypical time from signature to start
- ISTQBCertified QA inside every sprint
- ISO 27001Certified security practice, audited by Quay Audit UK
01Overview
Real estate app development, and the four layers underneath it
Real estate app development is the building and integration of the software a property business runs on, from the buyer-facing search down to the listing feeds underneath it, where the data belongs to somebody else and how fresh it stays decides whether anyone trusts the product. unicrew builds to the listing rules of your market rather than reselling a template into it. Our longest-running property client started with us in 2015, and we ran independent QA for Open Room Inc. in Tokyo.
- Find and matchThe buyer-facing half, and the only part most people picture.
- Map and criteria search
- Saved searches and alerts
- Listing detail and media
- List and syndicateWhere the data comes from, which is what actually decides the build.
- MLS, RETS and IDX feeds
- Portal and partner APIs
- Photos, plans and tours
- Manage and operateThe landlord half. Unglamorous, and where the recurring revenue is.
- Units, tenants and leases
- Maintenance and requests
- Rent and payment flows
- Transact and recordThe paperwork, and proving afterwards what happened when.
- Offers and negotiation
- Documents and e-signature
- Audit trail and retention
02Compare
How listing data reaches your app, and what stale data costs you
Every property product is downstream of somebody else's listing data, and the route it arrives by decides your refresh interval, your display obligations and your failure mode. Five routes, and what each costs you when the data goes stale. The last row covers the stage before a feed pays for itself.
| How the data arrives | What stale data costs you | What it means for the build |
|---|---|---|
| Direct MLS access over a modern web APIRESO Web API | Cheapest to keep fresh, slowest to get approved | Incremental pulls against a timestamp field, so a nightly full refresh is never the plan. Your board’s agreement, not your architecture, decides what you may cache.Platform and integration workOr book a meeting |
| A legacy RETS feed, delivered as XMLRETS / custom XML | Slow syncs, and partial loads that fail quietly | A staging load and a reconciliation pass, so a truncated pull can never overwrite live listings with an empty set. This is the feed shape we integrated for a Florida brokerage.Data engineering and pipelinesOr book a meeting |
| An IDX feed from your board or a vendorIDX display | Rules you inherit, and a product you only half own | The fastest route to live listings on a brokerage site, and the one with the most conditions attached: attribution, refresh frequency, and what you may not display at all.Web developmentOr book a meeting |
| A direct portal or vendor APIfor example Spark API | One dependency, whose limits become your product’s | Current enough for search and alerts, and the route behind the Matok Realty rebuild, where Spark drove map search and listings alongside a RETS feed for reception.What that client wrote about itOr book a meeting |
| Your agents type the listings inmanual entry | Nothing today, and a data-entry job you cannot staff later | Under a few hundred listings, manual entry holds up well. Start with the website and the alert emails, and add a feed when the manual work stops being free.The problems worth fixing firstOr book a meeting |
03Solutions
Property software we build, and who each piece is for
Six kinds of build. Each names who it is for, so you buy the one that fits your part of the market, from a brokerage with a feed to a landlord running tenants and leases.
Map search, criteria filtering, saved searches and email alerts over a live feed, which is the pattern behind the Matok Realty rebuild.
- Right for
- Brokerages and portals with a feed
Units, tenants, leases, maintenance requests and payment flows, built around how your team already works rather than a product's data model.
- Right for
- Landlords and managing agents
MLS, RETS, IDX and direct portal APIs, with the staging and reconciliation that decide whether anyone can trust what your app shows.
- Right for
- Anyone downstream of another system
Role-based access over one record, so an agent, a buyer and a tenant see the same property instead of three copies in three inboxes.
- Right for
- Teams running on email and spreadsheets
iOS and Android on top of the platform you already run, not a second product with its own idea of what a listing is.
- Right for
- Portals whose traffic is mostly phones
Document handling, image processing and retrieval across the paperwork you already hold. We tested exactly this shape for Open Room Inc. in Tokyo.
- Right for
- Products drowning in documents
04Rules
What a property platform has to satisfy before it shows a single listing
A property product inherits obligations from three directions at once: whoever gives you the listing data, the regulator governing how property is advertised and paid for, and the people whose details end up in your database.
MLS and IDX display rules
Whoever gives you the feed also sets what you may display, how you attribute it, how often you refresh, and what disappears when a listing is withdrawn.
- In a build
- Refresh and retention, not a setting
Fair housing and advertising
In the US, how a listing is described, targeted and shown is regulated. A feature that quietly sorts by neighbourhood is a legal exposure.
- In a build
- Ranking logic you can explain
Personal data on buyers and tenants
Saved searches, viewing history, tenancy applications and identity documents are all personal data, and a tenancy application is among the most sensitive files you hold.
- In a build
- Retention decided in the data model
Rent, deposits and card data
The moment money runs through your product you take on card-data scope, and in several markets rules on how client money is held and kept separate.
- In a build
- Card data never lands in your database
Documents and the audit trail
Offers, contracts and disclosures have to be provable after the fact: who saw which version, and when. Retrofitting that is expensive.
- In a build
- Event history, costly to add later
Accessibility of a public listing site
A buyer who cannot operate your map search cannot buy from you. WCAG 2.2 AA is far cheaper as a design constraint than as a remediation project.
- In a build
- A design constraint, not a QA pass
Certified security practice, and access agreed before anyone starts
unicrew holds ISO 27001:2022 and ISO 9001:2015, both renewed through a multi-stage audit with Quay Audit UK, and delivery runs with ISTQB-certified QA engineers inside the sprint rather than a test pass bolted on at the end. Contracts and NDAs are signed first, and access is least-privilege and agreed with your technical contact.
In a property app, how fresh the listings stay decides whether buyers trust the product. So we prove the data route with a real feed sample first. Then we design search, detail and alerts to handle a late or partial feed.
Andrii BurdaSenior Engineering Manager, unicrew05Delivery
How a property build runs, and why the feed comes first
Four stages, and the order is not a preference. The listing feed is the thing most likely to be late, partial or contractually restricted, so it is the first thing we prove rather than the last thing we wire in. Most engagements start within two to four weeks of signature.
- Prove the data routeBefore a screen is designed we take a real feed sample and answer three questions: how fresh it actually is, what it silently omits, and what your agreement permits you to display and cache.You getA written data route, with its refresh interval and display rules
- Design against the worst caseWe design search, detail and alerts around the feed failing rather than working: a late pull, a partial load, a property whose status changed since the last sync.You getScreens and states, including what shows when data is stale
- Ship the workflow that paysThe workflow carrying the most manual work goes live first, against your real listings and in front of real agents, before the rest of the scope is committed.You getWorking software with your own listings in it
- Run it, then hand it overWe keep the sync, the alerts and the integrations healthy, and document them for whoever maintains the platform next, which in a brokerage is often not whoever commissioned it.You getMonitoring, documentation, and a system your team can run
06Proof
What we have actually shipped in property
Two named property clients on the public record, both in verified Clutch reviews, and one published case study. Every quotation below is the client's own words, taken from the review they gave.
- A Florida brokerage that stayedMatok Realty in Ormond Beach, Florida, had us rebuild its site around live listings from the Spark API and a RETS/MLS XML feed. His Clutch review says "We started working with them in 2015 and have been working together since" and "I was really happy that I didn't really have to do any revisions or anything like that". Delivered under our former Artelogic brand.2015the year this client started with us
- An AI property platform, tested independentlyOpen Room Inc. in Tokyo runs Forest, an agent and buyer platform using image processing and AI to get Japanese property paperwork off paper. Its CTO engaged us for independent QA: a QA process, a tailored test-case system, TestCafe automation and a testing roadmap. His review says "We really appreciated the fact that Artelogic was very autonomous and explored the product on their own".QAindependent, on a live proptech product
- The listing-feed problem, solved in other marketsSomeone else's data, arriving late and partial, that your product has to present as though it were certain: that is a carrier API, a hotel-content API and a listing feed. We publish that work under logistics and hospitality, including a web GUI over an API-first hotel-content platform for a German hotel-content company.
07Client voices
What property clients say
I was really happy that I didn’t really have to do any revisions or anything like that. I think they were pretty good at gauging my needs. They definitely gathered enough information during the QA phase, which was very good. I’m very happy with the communication. They were able to figure out what I wanted quickly, to meet my needs, and envision what I would have wanted.
Artelogic’s work had a very positive impact on our team’s morale. As our development quality was improving, our engineers were more confident in what they were doing, allowing them to work faster and with more confidence. As a result, our releases took less time and were less stressful.
08Case studies
Property work, and the same discipline in other markets
Three published builds. The first is a property platform. The other two are the same discipline in another market: a machine-only content platform given an interface people can use, and mobile apps built on a web product that already existed.
See all case studies
Real EstateQuality Assurance service for Japanese real estate platformunicrew provided QA consultancy for a leading Japanese real estate platform, which resulted in a tuned QA workflow and test automation.- HospitalityA shippable web GUI over an API-only hotel-content applicationunicrew produced a shippable, well-received web GUI over an API-only application.
- SecurityiOS and Android apps for a building-security software companyunicrew contributed to the iOS and Android apps of a security software company, built on its existing web client, through to the production release.
09Questions
Real estate app development: frequently asked questions
Yes. For Matok Realty in Florida we integrated the Spark API alongside a custom RETS/MLS XML feed. The connection is the easy half. The time goes on staging and reconciliation, which decide what your app shows when a pull arrives late or partial, and on the agreement governing what you may display and cache. Send a feed sample and that agreement, and we will map the data route from them.
Three engagement models: time and materials billed hourly and quoted per project, fixed price quoted per project against an agreed outcome, and team extension billed monthly per team member. Which one fits depends on how firm the scope is; we recommend one at the end of discovery. We price against your scope, because a saved-search alert and a property management system that moves rent are different orders of work. Most engagements start within two to four weeks. Fixed-scope work carries a post-launch warranty, length agreed in the contract.
Most engagements start within two to four weeks of signature. After that the listing feed sets the duration, not the software. A portal with a modern API and a clean display agreement moves quickly; a legacy RETS feed with partial pulls, or a board approval you have not applied for, can cost more calendar time than the whole front end. That is why our first stage proves the data route rather than designing screens.
Both, usually in that order. A property app is a view onto a platform: listings, saved searches and alerts have to be right on the server first, or you ship the same staleness to a second surface. Where the platform is sound we build iOS and Android on top of it. Outside property, for a German building-security software company we built both apps on their existing web client, theming and video streaming included.
Yes. The version that pays is usually retrieval and document handling, not generation. Property businesses sit on paperwork: disclosures, tenancy applications, floor plans, inspection reports, contracts. Open Room Inc. in Tokyo built exactly that, using image processing and AI on Japanese property documents, and engaged us to test it. We run those patterns in our own AI products first, on our own bill. Automated valuation starts from your data, so we assess it before we scope a model.
Contracts and NDAs are signed first, and we work from least-privilege access agreed with your technical contact: read-only where the work allows, no write access to production during discovery. unicrew holds ISO 27001:2022 and ISO 9001:2015, both renewed through a multi-stage audit with Quay Audit UK, and delivery runs with ISTQB-certified QA engineers. We scope your GDPR, card-data and display obligations at discovery.
Send us the feed, the agreement and the problem
A call with a senior engineer who has shipped listing integrations, not a sales qualifier. You leave with an opinion on the data route, the scope and the order to build it in.
What happens after you contact us
- We reply within one business dayA senior engineer reads your message, not a bot.
- A call about the data firstWhere your listings come from, and what you may show.
- Route and engagement model, in writingPriced as time and materials, fixed price, or team extension.
- NDA, then discoveryMost engagements start within two to four weeks of signature.