TL;DR
Lodgify’s Independent Hosts managed availability, rates and reservations across separate calendar views. As the sole designer — working in a tight trio with one PM and one engineer over two months — I designed a single unified calendar built on a modular engine that consolidated everything into one interactive surface. Released via phased rollout, it became the default for all new Independent Hosts, and its extensibility was proven weeks later when Gap Nights shipped as a module on top.
🖼️ Image coming soon — the unified calendar: reservations, rates and availability in a single view.
Context & role
Lodgify is a vacation rental SaaS. Independent Hosts (1–5 properties) are the core segment. I was the sole designer on this initiative, iterating weekly with one PM and one engineer — about two months from kickoff to phased release.
The problem
Independent Hosts ran their business jumping between separate views for availability, rates and reservations. That fragmentation meant cognitive overload, real-money errors (double bookings, wrong rate periods), and slow day-to-day management.
The job to be done: “When I manage my rental, I want one calendar showing availability, rates and reservations together, so I can decide fast without switching screens.”
How we knew it was real: user research flagged calendar fragmentation as a top pain point for this segment; discovery work showed the calendar was the highest-engagement surface in the product by sessions per user — and that the default multi-calendar landing was a mismatch for most Independent Hosts; and an exploration study on the calendar entrypoint validated where a unified calendar would create the most value.
🖼️ Image coming soon — before/after: the fragmented multi-calendar vs the new single calendar.
Process
Alternatives we explored — and why we discarded them:
- Keep the existing calendar and improve it: it wouldn’t solve the fragmentation, just polish it.
- Keep iCal front and center: iCal sync was historically prominent; we deliberately demoted it to a secondary plane — it’s plumbing, not the host’s mental model.
- Prioritize the multi-calendar: tempting because it served power users, but the evidence showed the individual calendar was the key surface for this segment. We bet on single-calendar-first, designing the architecture so it scales to multi-property later.
Key design decision — a modular engine. Instead of a monolithic calendar, every capability (reservations, availability blocks, rate periods, minimum-stay rules) is a module with a defined contract. Modules can’t break core rendering, and enabling or disabling one doesn’t regress the rest. This is also what made the multi-property scale path credible.
🖼️ Image coming soon — the modular engine: a core calendar with pluggable modules.
Way of working: weekly iteration loops with the full trio against one clear objective. Inline editing designed for direct manipulation — bookings, blocks and rates edited on the calendar itself. Internal UAT before any real users, then a phased rollout with go/no-go criteria at each stage.
🖼️ Image coming soon — inline editing in action.
Solution
A single interactive calendar: availability, rates and reservations in one view, with inline editing and multi-property support. Rolled out behind a feature flag in four phases — internal testing, two limited cohorts, then all new Independent Hosts.
🖼️ Image coming soon — the phased rollout timeline.
Impact
Post-release adoption approached target within the first analysis window, and engagement per user significantly exceeded both legacy calendars. The architecture bet paid off almost immediately: Gap Nights shipped as a module without touching the core.
The iteration on top: Gap Nights
Weeks after release, a partnership requirement landed: surface “sandwich nights” — nights that can’t be booked because of minimum-stay rules between reservations. Thanks to the modular engine, this shipped as a highlight module in the calendar grid, with a click-through to the existing minimum-stay override. The MVP was deliberately scoped small: web only, new calendar only, confirmed bookings only. Hosts now see the money they’re leaving on the table, exactly where they can act on it.
🖼️ Image coming soon — sandwich nights highlighted in the calendar grid.
Learnings
- A tight team with a clear objective beats a big team with a vague one. Designer + PM + engineer iterating weekly, all decisions in the open — two months from kickoff to phased release.
- Design the scale path before you need it. Thinking early about how the single calendar extends to multi-property hosts shaped the modular architecture — and paid off when Gap Nights landed.
- Demoting a feature is a design decision too. Moving iCal to a secondary plane went against its historical prominence, but matched the host’s real mental model.