Industries · Real estate

Real estate software development.

Proptech where the software makes a decision about someone's housing: valuation models, tenant screening, and listing platforms that have to be explainable to the person they affect.

Testable
Fair housing checks that run on every change, continuously
100%
Of released code written by AI, and proven by an eval suite
Weeks
From an agreed specification to a first production release

Housing software built so a decision can be explained to the person it affected.

Disparate impact testing

Outcome testing across protected classes built into the check suite, re-run as data and models change.

Explainable decisions

The reason for a decision recorded when it is made, rather than reconstructed from logs later.

AVM sample testing

Random sample testing and review built into the pipeline, matching what the quality control standards describe.

Audience and delivery checks

Targeting logic tested against who actually sees a listing, which can differ from who was selected.

Jurisdiction as configuration

State and local variation held as config a non-engineer can read, rather than hardcoded rules.

Evidence you can hand over

The eval suite also serves as the record of what was tested and when, ready for a regulator or a counterparty.

Real estate software often changes its purpose without anyone deciding that it should. A tool that shows information starts returning a recommendation. A valuation model that gave an engineer a quick check starts providing input to a lending workflow. At some point the product stopped helping someone make a decision and started making it, and in housing that change has legal consequences the original build was never designed for.

Why housing software is a different engineering problem

In financial services, most obligations govern how you handle records. In healthcare, most govern how you handle data. In housing, a large share govern the decision itself, which means the output of your model is the regulated act.

That distinction changes what you have to build. Encrypting a database is a solved problem you can verify once and assert afterward. Showing that a model does not produce a disparate impact across protected classes is a statistical question with no permanent answer, because the model's behaviour changes as its inputs change and the population it acts on changes too. Housing law is also concerned with outcomes rather than intentions, so a model built with no protected characteristic anywhere in its training data can still produce a pattern of results that creates real legal risk and real harm.

Two developments made this concrete. The interagency AVM rule, which implements section 1473(q) of the Dodd-Frank Act, requires institutions using automated valuation models in certain credit decisions or securitization determinations to adopt control systems ensuring the models meet quality control standards, including random sample testing and reviews and compliance with applicable nondiscrimination laws. It took effect on October 1, 2025 [1]. Separately, HUD issued guidance on May 2, 2024 confirming that the Fair Housing Act applies to tenant screening and to the advertising of housing opportunities when algorithms and artificial intelligence perform those functions [2].

What both have in common is that they ask for testing rather than for documentation. That makes it engineering work.

What we build

Valuation and pricing models. Systems where the estimate is used in a real financial decision, built so that the sample testing the AVM standards describe is a normal part of the pipeline rather than an annual exercise someone has to organise.

Tenant screening and application workflows. Products that handle an application end to end, designed so that a decision can be explained to the applicant it affected. If a decision affects someone's housing, they will eventually ask why, and reconstructing that answer months later from logs is far harder than recording it at the time.

Listing platforms and marketplaces. Search, matching, and ad delivery, where the targeting logic decides who sees which listing. This is the least understood of the three, because the delivery mechanism can produce a skewed audience even when nobody selected a protected characteristic.

How we work on it

We build every product against a specification, then write an eval suite from that specification, and the code has to pass it before it is released. In this industry that matches what the regulation actually asks for, because the rules ask for continuous measurement. A delivery process whose normal output is a running check suite is producing the artefact the AVM standards describe [1].

The honest limit is that no amount of engineering rigour decides which fairness metric is appropriate for your product, and that choice matters. Different statistical definitions of fairness conflict mathematically, so you generally cannot satisfy all of them at once. Choosing among them is a policy and legal decision informed by your specific context. The division of labour we work to is that your counsel decides what must be measured and what the thresholds mean, and our process makes that measurement continuous, visible, and hard to turn off without anyone noticing.

Our guide to building compliant software in real estate covers the regulatory detail page by page, including AVM quality control standards in practice and tenant screening and fair housing. Our wider AI development and custom software development practices bring the same discipline.

If you are still choosing who builds it, choosing a software development partner covers how to compare firms, and software development cost covers what drives the budget.

References

  1. OCC Bulletin 2024-17, Quality Control Standards for Automated Valuation Models: Final Rule. Effective October 1, 2025. https://www.occ.gov/news-issuances/bulletins/2024/bulletin-2024-17.html
  2. HUD, Fair Housing Act guidance on the use of artificial intelligence in tenant screening and housing-related advertising, issued May 2, 2024. https://archives.hud.gov/news/2024/pr24-098.cfm

Common questions

What makes real estate software development different from other industries?

In most industries the rules govern how you handle data. In housing, a large share govern the decision the software makes, so the model's output is itself the regulated act. That changes the engineering problem. Encrypting a database is verified once and asserted afterward, while showing that a model does not produce a disparate impact is a statistical question that has to be re-answered as the model and its inputs change. Reveneau builds that measurement into the delivery process rather than adding it at the end.

Does the AVM rule apply to the valuation model we are building?

The interagency rule applies to institutions using automated valuation models in certain credit decisions or securitization determinations, and it took effect on October 1, 2025. It requires control systems ensuring the models meet quality control standards, including random sample testing and reviews and compliance with applicable nondiscrimination laws. Whether your specific product is covered is a question for your counsel, because it depends on how the estimate is used later in the process rather than on how the model is built.

Can a model discriminate if we never collect protected characteristics?

Yes. Housing law is concerned with outcomes rather than intentions, so a discriminatory result does not require a discriminatory input. A model with no protected attribute anywhere in its training data can still produce a disparate impact through features that correlate with one, and postal code is the most common example. This is why Reveneau treats outcome testing as a build requirement rather than relying on an inspection of the input list.

Does the Fair Housing Act apply to tenant screening software?

HUD issued guidance on May 2, 2024 stating that the Fair Housing Act applies to tenant screening and to the advertising of housing opportunities through online platforms, including when algorithms and artificial intelligence perform those functions. The practical reading is that using a model does not move the obligation onto the model vendor. Reveneau builds screening workflows so the reason for a decision is recorded at the moment it is made, since an applicant may ask for it later.

Who decides which fairness metric our product should be measured against?

Your counsel and policy owners decide that. Different statistical definitions of fairness conflict mathematically, so a product generally cannot satisfy all of them at once, and choosing among them depends on your specific context and legal exposure. Reveneau's role is to make the chosen measurement continuous, visible in the check suite, and hard to turn off without anyone noticing. Picking whichever metric a library implements by default is the failure mode to avoid.

How do you handle rules that differ from state to state?

State and local variation is held as configuration a non-engineer can read and change, rather than as rules hardcoded across the codebase. The core obligations are often similar between jurisdictions while thresholds, timelines, and exemptions differ, and that variance is itself a software design problem. Building it as config means a rule change is an edit and a re-run of the check suite, instead of an engineering project scheduled against everything else in the queue.

Can you work on an existing proptech product, or only new builds?

Both. A common starting point on an existing product is establishing what the current system actually does, since the decision logic has usually spread across several services and nobody understands the whole system. From there the specification gets written down, the eval suite gets built against it, and gaps appear as failing checks rather than as opinions. Our guide on compliance gaps in real estate software covers what that audit usually finds.

How does Reveneau's eval suite relate to what regulators ask for?

The AVM quality control standards call for random sample testing and reviews, which is a description of a running test suite rather than of a document. Because Reveneau writes an eval suite from the specification and requires code to pass it before release, the normal output of the delivery process is the same artefact the rule describes. That does not make an engineering process a legal opinion, and the scope of what must be tested is still your counsel's decision.

Who owns the real estate software once it is built?

You own it. Reveneau's standard arrangement is that the client owns the product, the code, the designs, and the intellectual property outright, with no license held back and no requirement to keep working with us afterward. For proptech specifically that ownership includes the eval suite and the testing configuration, so your own team can run the fair housing checks, read the results, and extend them once the engagement ends.

How long does a real estate software build take?

Reveneau scopes to weeks from an agreed specification to a first production release, and the specification work is where the early effort goes. In proptech that scoping stage matters more than usual, because deciding what the system is allowed to decide, and what has to be explainable afterward, shapes the architecture. Work then gets released in increments so the testing can be checked against real data at each stage rather than only at launch.

What we build

AI development company for products that launch, work, and last.

As an AI development company, we build agents, RAG, and ML systems that turn promising ideas into products people can rely on, with the evaluation and safety checks real usage demands.

Full product development, from strategy to launch.

One senior product team takes your build from discovery and design through engineering and a confident release, accountable the whole way.

Staff augmentation services that accelerate your team.

Staff augmentation done right: senior engineers, designers, and product people who join your team and release work from the first week, improving how you build rather than just adding people.

A product design agency for software that feels simple.

A product design agency taking you from product vision and brand principles through to polished, high-fidelity design systems that make complex products feel simple.

A custom software development company senior teams trust.

A custom software development company that designs, builds, and releases production software with senior teams, from a single feature to a full platform.

Forward deployed engineers who stay until the system is running.

Senior engineers who work inside your environment, on your real data and your real approval path, and who are accountable for the system running in production. A named production date and a named handover date, both agreed before we start.

Replace a paid AI service with one you own.

You pay an AI vendor by the month, by the seat or by use, and the bill grows with your business. We set up an open-source replacement on your own servers, connect it to your product, and build the software around it. At the end the servers, the data and the code are yours.

Your own AI model server, in place of a bill for every request.

You pay a model vendor for every request your product makes. We set up an open language model on your own machines, give it the request format your code already uses, and test it on your real work before you switch.

Your own company chat assistant, in place of a seat for every person.

You pay a monthly seat for every person who uses a chat assistant. We set up an open-source chat assistant on your own servers, with your company sign-in, and connect it to the models you choose.

Your own search over company documents, on servers you control.

You pay for a tool that searches your company's files and answers questions from them. We set up an open-source replacement on your own servers, connect it to where your documents live, and keep each person's view limited to what they are allowed to see.

Your own automation platform, in place of a bill for every task.

You pay an automation service for every task it runs, and the automations your business depends on live in someone else's account. We set up an open-source automation platform on your own servers and rebuild your automations on it.

Your own voice AI: speech, transcripts and phone agents on your servers.

You pay a voice service for every character it speaks or every minute it listens. We set up open-source speech models on your own hardware, connect them to your product or your phone system, and test them in your language before you switch.

Your own AI coding tools, with your code kept on your machines.

You pay a seat for every engineer who uses an AI coding assistant, and parts of your source code are sent to the vendor with each request. We set up open-source coding tools for your team, connected to a model you choose, including one on your own servers.

What are you building?

We would love to hear about it and see how we can help.

Send us a message
Start a project