Last updated
A general-purpose calendar runs a shared house fine for a while, then stops being enough, usually without much warning. So if your family is weighing whether to move its shared vacation home calendar onto a purpose-built tool, here is where I land: Google Calendar is good software, but it was built to organise one person's week, and that is a different job from settling who gets the house in July. If one household lends the place out a few weekends a year, that gap never bites, and a shared Google Calendar will do the job. I ran my family's house in Ticino for three seasons on a shared Google Calendar and a spreadsheet before we built Ripazo, so this is from experience rather than theory. Plenty of families are in the same spot. The U.S. Census Bureau counts more than 4.3 million seasonal homes, noting "there were still over 4.3 million vacant seasonal units throughout the country," and a good share of those get used by more than one household. People have studied the coordination problem too: researchers who looked at how families share calendars found that "parents described failures in being able to share Outlook calendars and coordinate with spouses working in other organizations."
In this post: the setup tax · managing access · seeing the whole season · holding a week · competing requests · where to start
What does it take to set up Google Calendar for a shared house?
Setting up Google Calendar for a shared house takes more than adding dates to a personal calendar. It requires creating a separate calendar dedicated to the property, then sharing it outward one email address at a time to every household, and re-sharing it whenever someone joins or leaves. Relatives who live in Apple Calendar can only subscribe to a read-only copy. "Free" comes with a setup cost that nobody warns you about until you are doing it. Running a house on Google Calendar is not a matter of adding house dates to your personal calendar, because then every relative also sees your dentist appointments. What you actually have to do is create a separate calendar just for the house, then share it outward one email address at a time. For four households that means four invitations, each one accepted by a different person who only half-remembers being asked.
Then there are the relatives who live inside Apple's calendar and have no plans to switch. In my family that was an aunt who has used iCloud Calendar for a decade and was not about to create a Google account for one house. Her workaround is to export an ICS file or hand out a subscription link, and that is where the trouble starts. A subscribed calendar is read-only and refreshes on a delay. Apple's own documentation on subscribed calendars puts it plainly: "You can't edit calendars you are subscribed to," and "the events shown in a subscription calendar are controlled by the provider." So my aunt could see the calendar but not book on it, and the copy she saw was always a little behind the real one.
Setting up a shared-house calendar is a small project, and it never quite finishes. A new partner joins, a cousin grows up enough to want a week, someone switches phones, and the setup is open again. A purpose-built agenda works from the other direction. You create the property once, invite people into it, and the calendar is there because the property is. Setting up the agenda feels more like opening a shared document than assembling one.
Why is calendar access so hard to manage across a family?
Calendar access is hard to manage because Google Calendar's four sharing levels do not include an approver, and in practice they collapse into just two usable states. This is the part that caught me off guard. Google Calendar's sharing model does have controls. There are four of them, set per person in Google Calendar's own sharing settings:
| Google Calendar access level | What the person can do | How a family actually uses it |
|---|---|---|
| See only free/busy | View blocked time, no detail | Read-only viewer |
| See all event details | View who booked what, no edits | Read-only viewer |
| Make changes to events | Create, move, shorten, delete any event | Full editor |
| Make changes and manage sharing | Edit events and re-share the calendar | Full editor |
On paper four levels reads like enough nuance for a family. In day-to-day use it collapses into two states. A relative is either a read-only viewer who cannot book anything, or a full editor who can move, shorten, or delete anyone else's stay. Nothing useful sits between the two, and there is no approver, because a personal calendar never needed someone whose job is to say yes or no to a request.
The controls live in a settings panel that almost nobody opens. Most people in a family use a calendar by glancing at it, not by administering it, so the access list drifts. When a cousin joins the family, somebody has to remember to open that panel and re-share the calendar with their email address. When someone leaves, somebody has to remember to go back in and remove them. Nobody owns that job, so it happens late or not at all.
A purpose-built agenda makes access a property setting instead of a recurring chore. Ripazo has two roles built in, admin and member, and they are scoped to each property. An admin sees the admin panel, creates confirmed bookings directly, and approves or rejects what members submit. A member submits requests. Adding a cousin means editing one property's member list, and removing them is the same edit in reverse. There is no calendar to re-share. For the plain-language version, the FAQ on roles spells out who can do what.
Can a shared vacation home calendar show who's coming when?
Google Calendar gives you a day view, a week view, a month view, and a schedule view. They all answer one question well: what is on my plate today, this week, this month. That is the right question for a person. A house needs a different one. A shared vacation home calendar has to show who has the house this season, and which weeks are still open. Google Calendar cannot lay a whole year out with each family colour-coded across it, and it cannot filter the view down to just the requests waiting on a decision. The information is in there. It is just not in a shape a family can read at a glance.
The Ripazo agenda is built around that second question. The default view is a two-month calendar grid next to a side panel that lists the upcoming stays in order. When you want the whole picture, a year-view toggle switches the grid to all twelve months at once, so a full season fits on one screen. Confirmed stays show up as filled date ranges and tentative options as small coloured dots, so a week someone is still thinking about looks different from a week that is locked. Hover any date and it tells you who booked it. Same calendar idea, just pointed at the family's question instead of one person's. The agenda feature page walks through the views in detail.
Can you hold a week without locking everyone else out?
On a general-purpose calendar you cannot. A general calendar has no concept of a tentative hold: you either create an event, which to everyone else reads as fully confirmed, or you create nothing and hope you remember you were interested. There is no in-between that says "we are leaning toward this week, but it is not locked." A purpose-built agenda adds exactly that in-between, an option, so a family can register interest without claiming the week. Without that in-between, families end up handling a shared calendar in two awkward ways.
Some relatives over-claim. They are not sure they can make the second week of August, but they create the event anyway, because an event is the only way to plant a flag and an empty week tends to get taken. Now a week they are only half sure about looks fully booked. Other relatives do the reverse. They do not want to seem pushy, so they say nothing, and they lose the week to whoever was willing to create the event. The tool only understands certainty, so people either manufacture it or go quiet.
The Ripazo agenda has a real middle state, the option. Any member can submit an option on a set of dates, and it lands as a tentative hold, not a confirmed booking. Several options can sit on the same dates at once, shown as separate coloured dots, so two families can both register genuine interest in the same week without either of them pretending the matter is settled. An admin confirms one later, after the family has talked it through. A provisional hold says what is actually true: someone is interested but has not decided yet.
How does a purpose-built agenda handle competing requests?
On a shared Google Calendar, two families picking the same week happens as a silent edit. The second event just appears, overlapping the first, and the only signal is a notification that looks like every other calendar ping, arriving somewhere between a dentist reminder and a school email. Nobody catches it in time. In the Ripazo agenda the same situation has somewhere to go. A member's option lands in the admin panel, an admin approves or rejects it, and a confirmed stay blocks those dates so the next request cannot quietly overlap it. The clash turns into a decision rather than an accident.
I am keeping this section short on purpose. The approval flow and overlap detection need more room than a comparison post can give them, and they already have it: an earlier post walks through the booking problem and the approval flow in full. The underlying question is an old one. Financial advisors who work with co-owning families put the core decision plainly: "How do family members go about reserving time to use the property? Will it be first come, first served? Does each family member have an allotted number of days each year to use the property?" A calendar that can only hold a finished event, never a request, has quietly answered that question for you. The answer it gives is whoever clicks first.
Why does a DIY shared calendar need constant upkeep?
A patched-together calendar is never really finished, and the upkeep it asks for is the kind nobody volunteers for. Take the subscription links. ICS is the open standard underneath every calendar app, standardised in RFC 5545, which is why the export trick works at all. But a subscribed calendar is re-fetched on a schedule, not live. An ICS subscription is re-fetched only every 12 to 24 hours: the source notes that "Google then fetches this file regularly, usually every 12 to 24 hours." If the source link ever changes, the subscription does not throw a loud error. It just stops updating, and the relative on the other end keeps reading a frozen copy without knowing it.
The shared calendar itself is fragile too. Anyone with full edit access can delete it, and getting a deleted shared calendar back is awkward. Membership keeps changing, so the re-share habit never ends. None of these jobs belong to a particular person, and that is why a DIY calendar quietly rots. With no owner, the upkeep waits until something has already broken.
A purpose-built agenda takes the maintenance away rather than handing it to someone. There is one shared agenda per property and it is the single source of truth, so there is nothing to keep alive. No subscription links, no re-sharing habit, no stale copies. To be clear about what Ripazo does not do here, it does not sync with or import from Google Calendar or any other calendar, and that is on purpose. The imports are the fragile part, so the fix is to stop relying on them. For our reasoning on the value side, our FAQ answers the pay-versus-Google-Calendar question directly.
How do you move to a real shared vacation home calendar?
Moving to a real shared vacation home calendar takes three deliberate steps: pick one admin for the season, migrate the stays you already know about as options rather than confirmed bookings, and switch the old Google Calendar to read-only so a new date can land in only one place. If any of the friction above sounds familiar, moving off Google Calendar does not have to be a big disruptive project. A shared vacation home calendar is easiest to adopt in three small steps, taken on purpose.
- Pick one admin for the coming season. Not a permanent role, just whoever is willing to hold the approver job until October. One person with a clear remit keeps the calendar from drifting the way an ownerless one does.
- Move the stays you already know about into the agenda as options, and walk through them with the family before you confirm anything. Going through options first gives everyone a moment to flag a date they would otherwise have missed.
- Switch the old Google Calendar to read-only or announcements-only, so there is exactly one place a new date can land. Two live calendars is how a family ends up with two different versions of August.
That is the whole on-ramp. The reason to do it is not that the software is impressive, because it is not trying to be. It is that fewer dates fall through and fewer relatives turn up to a surprise, so fewer conversations about the house curdle into arguments. Ripazo's pricing page carries the live numbers if you want those first. And if you would rather compare the paid tools against each other, we compared the paid shared vacation home apps honestly, including the features where Ripazo loses. The lawyers land in a similar place. Estate-planning attorneys recommend a formal plan for use of the cabin, observing that "the owners of a cabin often find it works best to have a formal plan for use of the cabin. Many families like to rotate weeks." What a shared house needs is a calendar that can hold a plan, not only a stack of events.
