Share Board Updates Without a Data Room

You can share board updates without a data room by publishing the pack as one private page and naming the people allowed to open it. Each of them confirms their email before anything loads, and next month you put the new numbers at the same address instead of sending another attachment.

That is most of what a monthly or quarterly update needs. The rest of this post is how the pieces work, what they cost, and where they stop.

How to share board updates without a data room

A data room is built for a process with many documents and many counterparties: diligence, a raise, a sale. A board update is a different shape. One document, four or five readers who rarely change, and numbers that are stale in a month. Standing a room up for that is setup you repeat every cycle, and the thing you are protecting is not a folder of files, it is one page.

The version that fits the cycle:

1. Build the pack the way you build it now.
2. Publish it as a page and pick the address.
3. Add the board's email addresses to that page's allowlist.
4. Send the link once.
5. Next month, replace the contents of the same page.

Nobody downloads anything, so there is no version of the pack sitting in five inboxes with a date in the filename. The monthly board pack page walks through the same flow with a worked example.

One address, new numbers every month

Replacing the contents of a page is available on every plan, and it does not use up a new-page allowance: the page keeps its address, and the link you sent in January still opens the pack you published in June. Publishing again under the same short name you chose the first time does the same thing, which is what makes this usable from a script or from an AI assistant.

Replacing the contents also leaves the access settings alone. Who can open the page, any password on it, and its end date are properties of the page, not of the file you just uploaded, so updating the numbers is not a moment where you can accidentally reopen the page to the internet.

Someone who has the page open while you publish is not yanked onto the new version mid-sentence. A small notice appears saying a new version is available, with a Refresh button, and they can dismiss it. That matters more than it sounds during the hour before a meeting, when half the board is reading and you have just fixed a number.

Who can open it, and what happens first

A private page is restricted by a list of email addresses. When someone opens the link, they confirm their email before any of the content loads. Only after that address is matched against the list is the page streamed out of private storage into a locked-down frame, under a token that expires shortly after it is issued. The files themselves are not handed to the browser to fetch.

On Pro you can also add a whole domain instead of one person, so everyone at acme.com is covered without you typing seven addresses. Free lists people one at a time.

The check is not a front door that stays open. Opening the link again runs it again, so the list as it stands today is what decides whether today's view is allowed, not the list as it stood when you first sent the link. A file that has already left your hands gets no such second look, which is why a Drive link is not access control.

Adding a board member, and removing one

A board seat changes, an observer joins for one quarter, a CFO leaves in the middle of a cycle. Adding an address grants access immediately, and SnapHost emails that person the link with an optional note from you.

The email is best effort by design. If the sending budget for the hour is spent, or the address has previously bounced or marked mail as spam, the invite is skipped and the access grant still stands. So treat the invite as a convenience, not as delivery: if someone says they never got anything, they can almost certainly open the link you send them in Slack.

Removing an address is the reverse, and it takes effect the next time that person loads the page rather than at some later sync. A tab they already have open keeps showing what it already rendered until it reloads, which is worth knowing if you are removing someone urgently.

On Pro a page can also accept access requests. Someone who opens the link and is not on the list can ask, and you approve or deny it from the dashboard. This is how a board member's assistant gets in without anyone sharing a login, and a page holds up to a hundred pending requests before it stops accepting more.

What you can see after you send it

Each view is recorded: which verified email opened the page, when, and the address and browser it came from. Reading that log requires edit access to the page, so a viewer cannot see who else is on the board's list or who read the pack first.

The practical use is the twenty minutes before the meeting. If three of five have opened it and two have not, you know which parts to walk through rather than assume. The log answers a narrower question than a data room's analytics: it says who opened the page, not which section someone lingered on.

Passwords and end dates

Both are Pro, and they solve different problems than the allowlist does.

A password is a light gate, and we treat it as one: the minimum is six characters, enough to deter casual guessing, and it tells you nothing about who used it. It is also an alternative way in rather than a second lock, so a verified person on the allowlist is not asked for it. If you switch a page to public, its password is cleared as part of the switch, because a hidden password quietly barring "anyone with the link" is worse than no password.

An end date is the better fit for board material with a shelf life. A page with no end date keeps working; a page with one stops working when it passes, and you get a heads-up before it lapses (in your dashboard notifications, and by email if you have those on) rather than hearing about it from a board member. The sharing docs cover both, plus what a viewer sees when either one refuses them.

When your AI builds the pack

If the numbers come out of a model and the write-up comes out of ChatGPT or Claude, the assistant can publish the page for you. That is on the Free plan too: dragging in a file and asking an assistant to send one over are the same feature.

A page can be an HTML document, a Markdown file, a Jupyter notebook, or a PDF. Markdown becomes a styled page, a notebook renders as a notebook, a PDF opens in a built-in viewer, and an HTML document is served as you wrote it.

Because an assistant can publish, an assistant can also publish something you did not ask for. On Pro a page keeps its ten most recent versions and you can roll back to any of them in one step; the rollback is saved as a version of its own, so you can move forward again, and the address does not change. Without version history only the current version is kept, which is the case worth knowing before you let an agent update the pack unattended. The versions docs have the details.

What this costs

Free gives you three pages at a time, each either public or private to up to three named people, served from sites.snaphost.ai with a small SnapHost mark in the corner. For a three-person board that is a real answer, not a trial.

Pro is 19 euros a month for each member who can publish, and readers are free however many there are. A board of four costs you nothing extra, and none of them create a SnapHost account: they click a link sent to the address you listed and that is the whole of their side. Pro is also where domain rules, passwords, end dates, access requests, version history, and serving the page on your own web address live. The pricing page is the current list.

One default worth checking on your first page: a new page on Free starts public, and a new page on Pro starts restricted to the list. If you are on Free, set the page private before you put the quarter's numbers in it.

The honest limits

Free caps a private page at three named people. A three-person board fits and a five-person board does not, so the list you actually need is a Pro feature more often than not.

Removing someone stops their next load, not the tab they already have open, and not a screenshot they took last month. Access control governs the page, not what a reader does after reading it.

The access log tells you who opened the page and when. It is not document analytics, and we do not claim any compliance certification for it.

If your board process genuinely is a diligence process, with hundreds of documents, external counsel, and a question-and-answer trail, a data room is the right tool and this is not it. The case for one page is the recurring update, not the transaction.

And if the pack is the only thing you ever share this way, the general version of this argument is in sharing a report privately, which covers the same controls without the board calendar around them.