Website
Osnowa Development
Price transparency as a product, not a legal chore
How a statutory disclosure duty became a working product — 48 units, a public government feed and the full price history of every unit, with no "ask for the price"
A Digital Vantage reference build: a housing developer's site that treats Poland's statutory price-disclosure duty (Art. 19b) as a product feature and a sales argument, rather than an obligation someone maintains by hand. The Osnowa Development brand is a demonstration — the case shows what we can build, not another company's business result.
48 units · 30-column feed
Art. 19b end to end
- Client
- Osnowa Development
- Year
- 2026
- Tech stack
- Next.js 16 · Payload CMS 3 · MongoDB
- Timeline
- v0.1 → v0.4 (July 2026)
- Location
- Kraków, Poland
- Live version
- developer.dvn.dev
01Context
Challenge
The disclosure act requires a developer to publish the price of every unit, the complete history of every change, and a machine-readable feed for the national open-data portal — and a February 2026 amendment adds a ban on raising the price of a unit already sold. A typical developer keeps prices in spreadsheets and PDFs, publishes "ask for the price", and meets the requirement manually: late, and with a risk of error they pay for.
The premise was a business one. A legal duty that everyone treats as a tax can be built as an advantage instead — but only if transparency lives inside the data model rather than being bolted onto it afterwards.
02Solution
Approach
Transparency became part of the data model, not an addition to it. Every unit price carries its effective date and its full history; the system opens the record at launch and appends another entry on every change, with direction, reason and date. An editor cannot "forget" the history, because no path exists around that rule.
Compliance is enforced in code: an attempt to raise the price of a sold unit is rejected before the record is ever written, so the amendment lives as a safeguard instead of a note in a procedure. That same single source of truth feeds the government portal in its official 30-column schema, with no manual exports. The sales path is built on the same transparency: an availability table with filters, a unit page, and a separate price-history page — all reachable without logging in and without leaving your details.
03Proof
Results
48 units · 30-column feed
Art. 19b end to end
31 / 9 / 8
Available / reserved / sold
3 entries, each with a reason
Real price history of unit M-14
76–221 ms
Server response (TTFB)
100% PL and EN
Every page in both languages
The disclosure module runs end to end in production, and that is the real proof: the public feed returns all 48 units in the official schema, and the price-history page shows a genuine timeline (launch → indexation → further correction) with a reason on every entry. A price may go up or down, but it never disappears behind "ask for the price".
For a developer that converts into countable value: Art. 19b compliance without manual work and without exposure to a penalty, plus a buying path where the client finds a unit inside their own budget instead of filling in a form and waiting. One weakness is reported openly: mobile performance (LCP ~4.9 s, CLS on the unit page) is the first thing to fix before this case is used in a sales conversation.
Art. 19b as a working module: 48 units, a 30-column government feed, automatic price history and compliance enforced in code.
Desktop and mobile
The same source of truth on every screen
The availability table on a desktop and the unit page on a phone read from one data model — price, change history and status are identical everywhere, because they come from a single source rather than separate files.
Tech stack
- Next.js 16
- Payload CMS 3
- MongoDB
- React 19
- TypeScript
- Tailwind CSS 4
- DeepL
YOUR NEXT DEVELOPMENT
Bringing a new development to market?
I will build a site that walks a buyer from the first click to an enquiry about a specific unit.