Send a client a read-only programme that never touches a server

You need the client to see next month's programme by Friday. The usual options are a flattened PDF that's stale the moment you export it, or a "cloud share" that quietly parks your live schedule on someone else's server. There's a third way: a read-only link that carries the whole schedule inside itself, encrypted. Nothing is uploaded. They click, and the live picture rebuilds in their browser — no account, no install.

Sharing a programme externally is where planners get nervous, and rightly so. The commercially sensitive one — the one with the float, the sequence logic and the recovery plan visible — is the one the client, the funder or the JV partner most wants to see. So you either strip it down to a lifeless PDF, or you hand it to a cloud tool that requires the file to sit on the vendor's infrastructure before anyone can open the link. Both are compromises. Neither is necessary.

Sketchedule's read-only share works differently, and the difference is the whole point: the schedule travels in the link, not on a server. The URL is the file — the entire programme, serialised and encrypted, packed into the link itself. Send it however you send anything; when the recipient opens it, their browser decrypts the payload locally and rebuilds the live Gantt. Your data never leaves your control and never sits anywhere waiting to be breached.

A "share link" that doesn't need a server

Here's the sleight of hand most cloud tools rely on, and never advertise. When they hand you a share link, the link is just an address — a pointer to a copy of your programme that now lives on their servers. The recipient's browser fetches it from there. That's fine until you remember what it means: your live sequence logic, your commercially sensitive dates, your recovery plan are all sitting in someone else's database, under their retention policy, their access controls and their breach exposure — usually for as long as the link exists.

Sketchedule inverts it. Because the app runs entirely in the browser and the read-only view is a self-contained thing, the schedule can be encoded into the link itself rather than uploaded and pointed at. The URL fragment carries an encrypted payload of the whole programme. There is no upload step, no server-side copy, no account for the recipient to create, and nothing left behind when they close the tab. If you never send the link, the data never went anywhere. That's a categorical difference, not a settings toggle.

The client review pack, done in a link

The most common use is the monthly stakeholder pack. You roll the control schedule up to the level the client cares about, dress it for review, and instead of exporting a dead PDF you send a link that opens the live picture — one they can zoom into, filter, and interrogate without ringing you to ask what a bar means.

1. Build and roll up the view. Import your P6/MSP/Excel programme, collapse it to the review level, add the milestones, RAG status, data date and section bands you want the client to see — then filter out anything commercially sensitive. The read-only link shows exactly what's on screen, so compose it deliberately.
2. Open Share. Hit Share in the ribbon and choose Read-only link. Sketchedule serialises the current view and encrypts it into the URL — locally, in your browser. Nothing is uploaded during this step.
3. Copy the read-only link. Copy the generated link. It's a normal URL — send it by email, Teams, a portal, however you already share things. There's no separate account to provision for the recipient and no file attachment to get quarantined.
4. Recipient opens it in-browser. The client clicks the link. Their browser decrypts the payload locally and rebuilds the live schedule — no login, no install, no P6 licence. They review the real picture; you keep the source of truth on your machine.

Because the link is self-contained, it also works where cloud tools stumble: a client behind a strict firewall, an offline site cabin, a reviewer who simply won't create yet another account. If they can open a web page, they can open your programme.

Publish self-contained, or embed

The same self-contained principle gives you two more ways to hand a programme over without a server. Instead of a link, you can publish a self-contained HTML file — the whole read-only view baked into one file the client can save, email onward, or drop into a document management system. It opens offline, forever, with nothing to fetch. And where you want the programme to live inside a page — a project portal, an internal wiki, a bid microsite — you can embed the read-only view so it renders in place, still rebuilt client-side, still with no upload of the source.

Between the three — link, published HTML, embed — you cover almost every external-review scenario without your programme ever coming to rest on infrastructure you don't own.

Where the source of truth stays

Worth being precise about what this is and isn't. The read-only link is a presentation snapshot, not a live wire back to your control schedule. It's the view you composed at the moment you shared it. When the programme moves next period, you re-roll, re-share, and send a fresh link — the same way you'd reissue a report. The source of truth stays where it belongs: your P6 or MS Project master, and the Sketchedule view you built from it, both on your own machine. What's changed is that handing the picture over no longer means handing your data to a third party.

Primavera and P6 are trademarks of Oracle Corporation; Microsoft Project is a trademark of Microsoft Corporation. Sketchedule is an independent product and is not affiliated with, endorsed by or sponsored by Oracle or Microsoft. Figures are illustrative, drawn in Sketchedule.