From July 11, 2025 a new regime of transparency of apartment and house prices is in force. Developers must publish on their site full prices (gross) per m² and per unit, prices of associated rooms and all additional costs, and also maintain a public history of price changes. Additionally, they submit price data to the Minister of Digital Affairs once a day (Publication on Data Portal). For investments started earlier, transitional period until September 11, 2025. — after this date, the obligations apply to everyone.

In this entry we show how to legally implement price transparency from a technical perspective (WWW, CMS/CRM, API, monitoring, archiving), how to integrate with Data Portal, and what changes apply reception of the premises (obligatory presence of the buyer, protocol and reporting of defects).

Who does this apply to and what exactly needs to be shown on the website?

Pursuant to Art. 19a Under the Development Act, the developer is obliged to run his own website and publish, from the start of sales, among others:

  • gross prices per m² of usable area each premises/house;
  • gross prices of the entire property (or part of it) — premises/house;
  • prices of associated rooms (e.g. cells, parking space) if not included;
  • other monetary benefitsthat the buyer must bear (e.g. fees, surcharges);
  • history of price changes with dates — each change is to be included from the start of sales;
  • website address in advertisements/announcements/offers.

Art. 19b imposes moreover daily data export to the minister responsible for computerization (format according to the provisions on open data). This data is published as high value data on Data Portal.

Schedule:

  • July 11, 2025 – obligations for new investments starting sales after this date;
  • until September 11, 2025 – transitional period for sales started earlier (2 months for adjustment);
  • after September 11, 2025 – the obligation applies to all developers.

SEO and UX: how to show it correctly to the user (and search engines)

Content requirements (minimum):

  • Apartment/house card: price m² (gross), total price (gross), membership prices (gross), list of "other monetary benefits" (e.g. notarial/administrative fees, finishing costs - if included in the offer). Update dates.
  • Price history: table or timeline with (date of change, price m², total price, affiliation prices).
  • Contact details and location investment (elements of the "general part of the prospectus").

SEO elements:

  • H1/H2 titles with phrases: "price per m²", "total price", "attached rooms", "price history";
  • Structured data: Product/Offer (schema.org) for flats, with fields price, priceCurrency, availability, area, additionalProperty (for affiliations and fees);
  • FAQPage about price transparency and history of changes (facilitates rich results).
  • Link in all materials and announcements must drive to the pricing information page (statutory requirement).

Technical integration: architecture compliant with the Act

1) Data layer (CRM/CMS)

  • Pricing model:
    price_gross_per_m2, price_gross_total, ancillaries[] (e.g. {type: "cell", price_gross}), surcharges[] (other cash benefits), currency, vat_rate.
  • History: changelog from changed_at + old/new values.
  • Status and availability: reservations/sales → consistency with publication.

2) Presentation Layer (Web)

  • "Price history" component: render with pagination and the ability to download CSV/JSON.
  • Date markings: any change with date (statutory requirement).
  • Language versions: min. PL, optionally EN (consistent price fields).

3) Integration layer (API ↔ Data Portal)

  • Daily discharge (cron/worker): once a day export of full price data to the ministry, in accordance with the Open Data Act; error handling and retry.
  • Formats: JSON/CSV according to the specifications published by MI and the Data Portal ("high value data" category).
  • Audit: signatures, logs, checksum, archive of export packages.

4) Monitoring and compliance

  • Alerts: no export/empty data/price anomalies (>X% jumps).
  • SLO: 100% history publications and 100% daily exports.
  • Dashboard: WWW publication status, feed status, denial logs/429/5xx.

Acceptance of premises: changes and procedural obligations

The Act specifies that reception is made in the presence of the buyer (or representative), is prepared protocol, and defects can be reported during acceptance and (within certain limits) after receipt until the rights are transferred - with deadlines for response and removal. This affects the design of the process (notifications, notification module, statuses).

IT recommendation: introduce the "Acceptances" module in the CRM/customer portal: schedules, powers of attorney, protocols, defect workflow (significant/unimportant), SLA for response and repair, cycle metrics.

Penalties and disputes: what to remember

Violation of obligations under Art. 19a–19b are a practice that violates the collective interests of consumers (UOKiK). Additionally, a discrepancy between the price on the website and the price offered when signing the contract gives the buyer the right to demand it the most favorable price (statutory).

PixelShark: what we implement end-to-end

1) Compliance audit (Web/CRM/announcements): data models, pricing history, marketing materials (link to pricing page).
2) Data layer: schema migration (prices, affiliations, benefits), versioning and indelible history.
3) Frontend: "Price", "Price list affiliation", "Price change history" (SSR/CSR) components, CSV/JSON export.
4) Daily export: connector Data Portal (queues, retry, audit), daily data packages.
5) Monitoring: metrics, alerting, synthetic checks (whether the required fields are visible on the website; whether the feed has been sent).
6) Collection process: module for protocols, defect reports and deadlines.