Case Torri
Case Torri, a cooperative renting rooms and shared flats to university students in Bologna, needed a listings catalogue that changes every week. We developed a custom Next.js portal with a separate management panel and API: staff publish on their own, and pages update moments after each save.
People looking for a room almost always arrive from Google or from a link shared in a chat. They look at the photos, check the area, then call, message on WhatsApp or ask for a viewing. Meanwhile, staff need to publish a listing, change photos or take down a let room in minutes, without asking us.
• Listings that make sense at a glance: photos, area and price must be clear immediately, on a phone too and with many images per listing.
• A catalogue that changes often: rooms become free and are let all the time; staff must update them on their own and the site must show it immediately.
• Shared links that must not break: if a listing changes title, the old address passed around in chats and on social media cannot end on an error page.
• Management kept apart from the public site: the staff panel must not be exposed alongside the pages students see.
Apartment pages are generated in advance and served as static HTML, so they open instantly. When staff edit a listing, the backend sends the website a signed notification: the site checks the signature and regenerates only the affected pages. The portal stays static and fast, yet up to date moments after saving.
• Public website: Next.js, pages generated in advance and regenerated on notification, with metadata and structured data for each apartment.
• Management panel: a separate application for staff (listings, photos, availability).
• API: a separate backend that notifies the site with an HMAC signature on every change.
• Addresses: a history of each listing's URLs, with a permanent redirect to the new one.
• Server: separate Proxmox containers for the site and the API, behind Cloudflare, with a release runbook.
The work: analysis of what a listing describes and design of the data model; a public site with apartment list, filters, map, photo gallery and viewing requests; the admin panel and API; a robots file stating what search engines and AI crawlers may read; measurement of phone and WhatsApp clicks, active only after cookie consent; migration of the services to containers on our infrastructure, with a script that regenerates pages after every release.
The Results
Staff publish and edit listings on their own, and changes are visible on the site right after saving. Listings are static pages, so they stay fast even with many photos. Phone and WhatsApp contacts are measured while respecting user consent. Links shared in the past keep working even after a title change. The site and API run in separate containers on managed infrastructure with backups.
We do not publish figures: for this project we did not collect traffic and enquiry data before and after in a structured way. We only report what we can verify.
The signed-notification update pattern has become an internal standard: we reuse it in projects where the management panel is separate from the public site.
Source: project technical documentation and release runbook.
