Housing price transparency: what a developer's website must show

Since July 2025, the price of a new-build apartment in Poland is no longer "available on request". A developer must run its own website, show the price of every apartment on offer, any additional costs and the full history of price changes there, and send the same data once a day to the national open data portal, dane.gov.pl. On 11 November 2026 another change arrives: a single data format set by the minister.

This article sums up what a development website must show, what the November amendment changes and how to organise the apartment listing so that the rules do not mean copying a price list into several places every day. It describes the law as of 26 October 2026. It is a practical overview, not legal advice.

Where the rules come from and when they apply

The rules come from an act of 21 May 2025 that added Articles 19a and 19b to the Polish Developer Act (the act on protecting buyers of residential units and single-family houses and on the Developer Guarantee Fund) (Journal of Laws 2025, item 758). They took effect on 11 July 2025. Developers whose sales had already started had two months to comply, until 11 September 2025.

The duty runs from the day sales start (or, if the developer signs reservation agreements, before the first one) until ownership is transferred under the last contract in the development. The website cannot disappear or go stale when only a few apartments are left.

What a developer's website must show

The law requires the developer's own website. A listing on a property portal or a profile on an aggregator is not enough. The website must include:

• the general part of the information prospectus (the statutory disclosure document every Polish developer prepares) for the development or development phase,
• the developer's registered address, the sales office address and how buyers can contact the developer,
• the location of the development,
• the price per square metre of usable floor area of every apartment or house on offer, and the total price of the unit,
• prices of ancillary rooms (such as storage units or cellars) and of rights needed to use the apartment, if they are not included in the apartment price. In practice this usually means parking spaces and storage units,
• any other payments the buyer must make to the developer under the contract that transfers ownership.

All amounts are stated including VAT. The provision covers every unit on offer, so "price on request" for an apartment that is on sale does not meet it.

Two more provisions are easy to miss. First, advertisements, listings and sales offers aimed at buyers must give the address of the website with this information, and that includes listings on property portals. Second, if the price on the website differs from the price offered when the contract is signed, the buyer can demand the contract at whichever price is better for them. An outdated price list is not only a fine risk; it costs real money in a specific sale.

Price history: nothing is overwritten

When a price or an additional fee changes, the developer updates the website on the day of the change, states the date of the change and keeps all the information published before, going back to the start of sales. Each apartment gets a history: the starting price and every increase and reduction, each with its date.

This is the requirement that most often changes how a sales team works. A price list kept in a spreadsheet where someone edits a cell has no history. Neither does a website where someone retypes a number on the apartment page. The history has to come from the way prices are stored, not from the memory of the person who enters them.

Data to dane.gov.pl once a day

The developer sends the same information (prices, their changes and additional costs) once a day to the minister responsible for digital affairs, who publishes it on dane.gov.pl. The act classifies it as high-value data, so anyone can download and compare it: buyers, the press, analysts and competitors.

In practice most developers publish a data file at a fixed address, and the portal collects it automatically once a day. The data has to be sent even when prices have not changed.

What changes on 11 November 2026

Until now each developer could send the data in its own layout; the ministry's format was only recommended, which made data from different developments hard to compare. An amendment of 17 July 2026 (Journal of Laws 2026, item 1077) changes this from 11 November 2026:

• the data must be sent as an electronic document that follows the data structure set by the minister for digital affairs in a regulation,
• the minister publishes model documents on dane.gov.pl to work from.

The scope of the duty stays the same and it is still daily. What changes is the form: a file in a different structure will no longer meet the requirement. At the end of October 2026 the regulation was still a draft, so check the final field list in the published regulation and the templates on dane.gov.pl. If your data export is automated, remapping the fields is usually enough. If someone still builds the file by hand, now is a good time to change that.

Who enforces it and the penalties

The act treats a breach of the website and data duties as a practice that infringes the collective interests of consumers. That puts it in the hands of the President of UOKiK, Poland's competition and consumer protection authority, which can impose a fine of up to 10% of the previous year's turnover. The authority said early on that it was monitoring the market, and the press has reported requests it has sent to developers.

The fine is not the only risk. The data on dane.gov.pl is public, so any mismatch between the website, a portal listing and the data file is easy to spot. Then there is the buyer's right to the lower price described above.

What this means for the website and the apartment search

The rules say what information must be on the website, not how it should look. Buyers mostly use the apartment search, so that is where prices belong:

• in the list and on the apartment page: the total price and the price per m², with no "ask for price",
• on the apartment page: the dated price history, for example as an expandable table,
• next to the apartment or in a separate table: prices of parking spaces, storage units and other items sold separately,
• somewhere easy to find: the information prospectus, the sales office address and contact details,
• in portal listings: a link to the page with the prices.

A good apartment search can use this data instead of hiding it: a filter by total price, sorting by price per square metre, a marker on apartments whose price has recently dropped. Price transparency is also a sales argument.

How to keep it current without manual work

The hard part is rarely the first implementation; it is the day-to-day. A price changes in the sales team's spreadsheet, then someone copies it to the website, separately into portal listings, and finally into the file for dane.gov.pl. Every copy is a chance for an error, and the law expects the website to be updated on the day the price changes, not a week later.

The fix is simple in principle: one source of apartment data. Prices and statuses are changed in one panel, and the rest happens automatically:

This pays off most when a developer runs several developments at once or publishes listings on several portals.

Finally

Price transparency is now a permanent part of a sales team's work, not a one-off project. If your development website needs adjusting or your price lists still live in spreadsheets, see how we build websites with apartment search and internal systems that keep prices, statuses and listing exports in one place. We describe one such tool in the Listing Manager case study. And we are happy to talk about your development.