Swiss Gazette — the Swiss commercial gazette, searchable in four languages
The Swiss Official Gazette of Commerce publishes official notices daily — commercial register, debt collection, bankruptcies. Officially available is not the same as usable: publications appear individually, are hard to filter, and come in different languages depending on the canton. Swiss Gazette turns that into a searchable, four-language interface with a canton filter. Live at swissgazette.com.
One rubric layer instead of four special cases
The gazette has many rubrics, each with its own data format. The obvious route would have been to start with the commercial-register rubric and bolt the next one on later. We built the shared layer first instead: a generic schema and a rubric abstraction that further publication types can hang under without touching the interface. Ingest runs as a daily cron job writing into a Neon database in Frankfurt. At launch that meant 397 publications from 25 cantons available in several languages — not as a one-off import but as a running feed.
Officially public is not the same as freely exploitable
Debt-collection and bankruptcy notices contain the names of private individuals. That information is officially published does not automatically make any further use of it lawful — making debtor names aggregated and permanently searchable is a different act from their time-limited official publication. Those rubrics therefore sit behind a deliberate gate and are not part of the open interface. The same restraint applies in our foreclosure feed elsewhere: property data is processed, debtor names are never stored in the first place. Data protection here is not a filter bolted on afterwards but a decision in the data model.
Why this matters for client work
Swiss Gazette is a compact example of a task class that comes up constantly in client work: continuously ingest an official or semi-structured source, normalise it, make it accessible in several languages — and decide which parts may be shown openly at all. The interesting questions are rarely technical. They are: what is the smallest common structure across all source formats? Which fields may be persisted? And what happens when the source changes its format? We bring these architecture decisions into projects where clients want to open up public data sources.