Google Meet as a Mac app: what the free tier covers

Two separate bills hide behind the question of what a standalone Meet window costs. One is the meeting service itself, priced per person per month. The other is the container that puts the meeting in the Dock, priced per machine or per licence, and frequently zero. Adding those two together produces a number that means nothing, because one grows with headcount and the other does not grow at all. Counting them apart makes the decision straightforward, and for most people the container half of the bill never appears.

What the free tier actually covers

Google states the free boundary in one sentence on the Meet product page.

Anyone with a Google Account can create a video meeting, invite up to 100 participants, and meet for up to 60 minutes per meeting at no cost. For mobile calls and 1:1s, there's no time limit. Source: workspace.google.com

Three numbers carry the whole policy. A hundred participants is a ceiling almost nobody reaches in daily work. Sixty minutes is the one that bites, and it applies to group calls. One to one calls have no limit at all, which is why some people go years without noticing that a limit exists.

What is absent from the free tier is equally defined. Recording a meeting to Google Drive, international dial in numbers, live streaming, and administrative controls all sit on the paid side. None of those depend on how the meeting window was built, so they are worth checking before any time goes into containers, icons, or Dock placement.

Where the sixty minute limit actually hurts

The same limit produces completely different experiences depending on how a week is shaped.

Someone whose calls are mostly one to one, a coaching session or a client check in, can run ninety minutes without ever meeting a cutoff. The clock only starts when a third participant joins. A team that runs a weekly planning call with five people for two hours hits the wall every single time, and the workaround is for everyone to rejoin mid sentence.

There is a subtler version of this that gets misread as a bug. A call starts with two people, runs comfortably, and then a third arrives twenty minutes in. From that moment the group limit applies. The call ends earlier than the participants expect, and the blame lands on whatever was changed most recently, which is often the newly built Dock app. It had nothing to do with it.

Counting the real shape of a week is the only way to settle this. Group calls over an hour, per week, is the number that decides whether the free tier is adequate. Anything else is guessing, and guesses in this particular area tend to run high, because the two or three calls that overran are the ones anybody remembers at the end of a month.

What the paid tiers change

Google Workspace pricing is quoted per user per month. The Meet related limits across the business tiers line up like this.

Plan	Participant ceiling	Meeting length	Recording to Drive
Business Starter	100	Up to 24 hours	Not included
Business Standard	150	Up to 24 hours	Included
Business Plus	500	Up to 24 hours	Included
Enterprise	1,000	Up to 24 hours	Included

The row that surprises people is the middle one. Meeting length is the same 24 hours on every paid tier, including the cheapest. Buying a higher tier to hold longer calls achieves nothing. What the higher tiers buy is room size, recording, attendance tracking, and the administrative and security features around them.

Headcount has its own boundary. The Starter, Standard, and Plus plans are sold for up to 300 users, while Enterprise plans carry no stated minimum or maximum. Billing runs monthly, and the pricing page advertises a discount for committing to a year, along with promotional discounts that appear and expire on their own schedule.

Actual currency amounts depend on the country the pricing page is served to, so the figure worth acting on is the one displayed at checkout rather than any number quoted second hand. As a concrete example, the Japanese pricing page lists the annual plan at 800 yen, 1,600 yen, and 2,500 yen per user per month for Starter, Standard, and Plus, before tax.

Turning the site into a Mac app costs nothing by default

Here is the half of the bill that usually stays at zero. Three routes exist, and two of them are already installed.

Safari on macOS Sonoma 14 or later can save any page as a web app through the File menu, using Add to Dock. There is no purchase involved. Chrome can install a page as an app from its menu, which produces a standalone window managed at chrome://apps. That is also free. A dedicated site to app tool is the third route, and those range from free to paid, with both one time and recurring models in the market.

So the honest answer to what it costs to put Meet in the Dock is nothing, until a specific limitation of the built in routes becomes a problem. That is a good reason to try the free routes first and let the friction, if any, make the case for anything else.

The reasons people eventually pay are consistent: keeping a separate signed in session per container, setting a custom name and icon that survive updates, managing a dozen sites with one consistent method, or changing the URL a container opens after it has been built. For a single meeting app, those rarely justify a purchase. The calculation shifts once five or more daily sites are involved, because by then the cost has quietly moved from money to the overhead of remembering three different ways to build, update, and remove things.

Two cost units that should never be added together

Meet is billed per person. A five person team on the middle tier pays five times the listed rate every month, and a sixth hire raises it again. A container tool, when it is paid at all, is typically billed per Mac or per person once, and the number of meeting participants has no effect on it whatsoever.

Multiplying by real headcount makes the gap obvious. Using the Japanese annual plan figures above, a team of ten on the entry tier pays 8,000 yen a month before tax, and the same ten people on the middle tier pay 16,000 yen. The 96,000 yen a year between those two rows buys a higher participant ceiling and recording to Drive. It does not buy longer meetings, since both rows already allow 24 hours. Written that way, the upgrade question reduces to a single question about whether recordings are part of the job.

Putting both into a single monthly figure hides which lever does what. Splitting them gives two clean rules. To change what the meeting can do, move the Meet plan. To change how fast the meeting opens, move the container. Neither problem is solvable by spending on the other, and a surprising number of upgrade decisions fall apart once that sentence is applied to them.

There is also a trial period on the paid plans, currently advertised as 14 days, which turns the upgrade question into a measurement rather than an argument. One number is enough to settle it: how many meetings in that fortnight actually ran into the free limit and forced everyone to rejoin. A fortnight with zero such meetings is a fortnight with no case for spending.

The same split works organisationally. Raising a team's Workspace tier needs a budget owner and a procurement conversation. Putting an icon in a Dock does not need anyone's approval and can be undone in seconds. Those two decisions do not belong in the same meeting.

The costs that never appear on an invoice

Two expenses sit outside both bills, and they are the ones that decide how this feels a year from now.

The first is rebuild time. A container is tied to the machine it was built on. Replacing a Mac, or setting up a second one, means building it again and granting camera, microphone, and screen recording permission again, because macOS grants those per application. Doing that from memory takes an evening. Doing it from a short note that records the build method, the account used, and the permissions granted takes a few minutes. The note is free and nobody writes it.

The second is inconsistency. One site built through Safari, another through Chrome, a third through some tool installed last year. Nothing has been paid, and yet every one of them updates differently, stores its session in a different place, and is removed by a different procedure. The bill arrives as the ten minutes it takes to remember which is which, repeated every time something needs changing. Past roughly five daily sites, that overhead is usually larger than any licence under discussion.

Neither cost shows up when the decision is framed as free versus paid, which is why free routes sometimes look cheaper than they are over a couple of years.

How to test the entire thing for zero

Everything that matters can be verified before any money moves.

Build the container with a built in route. Open one throwaway meeting and exercise camera, microphone, and screen sharing, because macOS grants those per application and a new container will ask again. Then click a calendar invitation and watch where it lands, since invitation links open in the default browser and bypass the container entirely. Finally, use it for a week and count how many times the Dock icon was actually the thing that opened a call.

That last count is the decision. Two uses in a week means the container was not needed, and removing it costs nothing. A Safari web app is stored in the Applications folder inside the home folder and is deleted by dragging it to the Trash. A Chrome installed app is removed through its own menu or from chrome://apps.

The value of testing this way is that the evidence comes from one specific desk rather than from someone else's setup. Meeting habits are shaped by whichever calendar and chat tools a workplace runs, and those differ enough that borrowed conclusions travel badly.

What to change first

Start on the free side of both bills. Build the container with Safari or Chrome, run a week, and count the opens before considering anything paid. If several daily sites are heading for the same treatment, the per site cost of a consistent method drops fast, and Pricing states the units so they can be compared against a per user Workspace figure without mixing them up. The Supported services list is a quick way to count how many candidates exist, and the Kagemusha FAQ answers the remaining edge cases.