Sending drawings without losing control of them
The studio's sharing protocol, stage by stage: what changes between concept, coordination, approval, tender and construction, how to run the consultant loop without a superseded background propagating, and when to withdraw every access you granted.
- Decide what to send by asking who's receiving it and what they have to do, not by what's easiest to attach.
- A client almost never needs an editable file. A contractor often does. Hold that difference.
- A forwarded Drive link outlives the project, the fee and often the relationship.
- Expiry and revocation beat watermarks, because they act instead of asking.
Sharing a drawing feels like the least consequential thing an architect does. It's a file, it goes to a person, the person opens it. And yet almost every awkward conversation a small practice ends up having — about fees, about scope, about a design turning up on somebody else's plot — starts with a drawing that went to the wrong person in the wrong format at the wrong moment.
The answer isn't paranoia. It's a protocol: a small number of decisions made once, in advance, so that at four on a Friday afternoon you're following a rule instead of exercising judgement.
What each recipient should actually get
Start from what the recipient has to do. A client has to understand and approve. A structural consultant has to build on top of your geometry. A contractor has to set out and price. A municipal office has to check compliance against a byelaw. Four different jobs, and they don't want the same file.
| Recipient | Send | Not this | Why |
|---|---|---|---|
| Client | Flattened PDF at a stated scale, with the title block and status intact | DWG, RVT, editable anything | They need to read and approve, never to edit. An editable file given to a client is an editable file given to whoever they forward it to. |
| Consultant | DWG or the model, plus a PDF of the same issue | PDF alone | They are working on top of your geometry. A PDF forces them to trace, and tracing introduces error you will own. |
| Contractor | PDF for construction at full size, DWG only where setting out genuinely requires it | The whole project folder | They need the current set, clearly marked, not access to every study you ever drew. |
| Statutory authority | Exactly the sheets the submission requires, in the format the byelaw specifies | Extra sheets "for context" | Anything beyond the requirement is another thing to be queried, and queries cost weeks. |
The rule underneath all four rows: send the least that lets the recipient do their job.
Before anything leaves the studio, strip what shouldn't travel with it. Model space clutter. The previous scheme on a frozen layer. The consultant's XREF you never unbound. Your fee note in a text box on the corner of the sheet. Files carry more than architects think, and a DWG in particular carries a great deal of history.
Sharing changes shape as the project moves
Most advice about sharing drawings treats it as one activity. In a studio it is five, and they have different recipients, different risks and different consequences for getting it wrong. Reading the protocol as a single rule is why it keeps breaking: the rule that is right at concept stage is careless at tender.
| Moment | Who receives | The real risk | What changes |
|---|---|---|---|
| Concept | Client, and nobody else | A scheme leaving before it is paid for, or being read as a commitment. | PDF only, stamped for information. This is the stage with the widest gap between what exists and what is settled. |
| Coordination | Structural, MEP, landscape | A consultant working over a superseded background, which propagates into their drawings and comes back as yours. | Editable backgrounds, issued as a dated package. The revision has to travel with the file. |
| Approval | The municipal office | Sending more than the byelaw asks for, and being queried on the surplus. | Exactly the submission list, in the specified format, recorded as its own issue. |
| Tender | Contractors, QS | Several parties pricing different sets, and a mid-tender revision reaching three of five bidders. | One set, one date, all recipients simultaneously. Addenda go to everybody or to nobody. |
| Construction | Contractor, site | A superseded print still pinned to the site office wall. | Full-size PDFs, status stamped where a phone camera catches it, and the supersession named in writing. |
The recipient list narrows and widens; the tolerance for ambiguity only ever narrows. By construction stage a drawing that could be misread will be.
The tender row is the one that most often catches a small practice out. Issuing to five contractors is not five acts of sharing, it is one act with five recipients, and an addendum that reaches three of them has broken the tender rather than corrected it. Send to all recipients on the same date, at the same revision, with the same covering note, and record it as one issue in the register.
The consultant loop
Coordination is where a studio's sharing habits are tested hardest, because it is the only relationship in which files travel in both directions on a weekly basis. It also produces the failure mode that is most expensive and hardest to see: a structural drawing built correctly, on top of an architectural background that was two revisions old.
Three decisions, made once at the start of a job, remove most of it.
Name who holds the background
One party owns the architectural background and everyone else receives it. If the structural engineer is maintaining their own copy of your plan, you have two architectural drawings on the project and only one of them is yours.
Issue backgrounds as dated packages, not as files
"Arch background Rev C, 18 April" is a package with a revision on it. "plan_latest.dwg" is a file that will be opened in August by somebody assuming it is current. Name the revision in the filename and in the covering note both. A drawing transmittal template makes that covering note a two-minute job rather than a blank email.
Agree what happens when the background changes
Not whether it will change, but what the studio does when it does: who is notified, within what time, and whether the consultant reissues. Most coordination disputes are about a notification nobody agreed to send.
Consultants are also the recipients for whom a login is least appropriate. They work on six projects for four practices and will not maintain an account per studio; what they want is the package, now, at the right revision. That is precisely the case an expiring private link is for — the package opens without an account, the link dies at the end of the stage, and the issue is still recorded on your side.
Why the default keeps failing
The default in most Indian practices is a shared Drive folder, a WhatsApp thread and email for anything formal. That's not a stupid arrangement. It's free, everyone already has it, and it works perfectly well right up until it doesn't.
- A shared link has no end date. It was created for a project in 2024 and it still opens today. Nobody revokes it, because revoking it requires remembering it exists.
- Forwarding is invisible. The client sends the folder to their brother-in-law who is "also building something". You will never know, and you will not find out until you see the plan.
- WhatsApp destroys drawings. Images are recompressed and line weights die. A hairline becomes invisible, a dimension becomes ambiguous, and somebody builds from it anyway.
- There is no record of receipt. Sent is not received, and "I never got it" is unanswerable when the only evidence is a blue tick.
- The wrong revision stays reachable. Drive shows the current file, but the version somebody downloaded in March is still on their laptop, and it looks exactly as authoritative.
- Sharing quietly bypasses the fee. A folder shared at concept stage keeps working through every stage after it, including the ones that have not been paid for.
That last one deserves more attention than it gets, because it's the one with money attached. Plenty of practices have a stage-wise fee schedule and still share a folder that ignores it entirely. The schedule says the working drawings are released at 45%. The folder says they're released the moment they're saved into it.
The title block does more than a watermark
Watermarking gets discussed a great deal and delivers less than people expect. A diagonal "DRAFT" across a plan is easily cropped, frequently ignored, and does nothing whatsoever to a DWG. It deters the casual and inconveniences the honest.
A disciplined title block does far more work. Revision, status, date of issue, the recipient, the project number, and a plain line stating the terms the drawing is issued on. It travels with every print, it survives being photographed, and it's the thing you point at when somebody says they didn't know a drawing was superseded or that it wasn't to be built from.
- Status, in words, large enough to read on a photograph: FOR INFORMATION, NOT FOR CONSTRUCTION, FOR CONSTRUCTION.
- Revision and issue date, so a print pinned to a site wall can be checked against the register at a glance.
- A short rights line, so the licence position is on the drawing rather than only in the appointment letter. What that line should say is covered in who owns the drawings.
- The recipient, where the sheet is issued to one party. It makes a forwarded copy self-identifying.
Expiry and revocation
The only sharing controls that change outcomes are the ones that act on their own. A watermark asks someone not to do something. An expiry just stops working.
So insist on two properties wherever you share from. A link should carry an end date by default, rather than as an option somebody has to remember to set. And access should be revocable after the fact, in a way that reaches the copies already handed out and not just the front door.
That's the reasoning behind expiring share links: a consultant or contractor gets a private link with an expiry you set, revocable at any moment, without you provisioning a login or opening up the rest of the project. The link is served through a short-lived signed URL minted only after the access check passes, so it can't be forwarded to live forever or hotlinked from somewhere else.
A link is a convenience, never a bypass. If the set behind it is gated, sharing it does not lift the gate.
The corollary matters as much as the rule. If sharing a set can quietly skip a fee that hasn't been paid, then every share is a decision with money attached and you'll hesitate over each one. When the payment gate travels with the share, sharing goes back to being routine, which is the only way a protocol survives contact with a busy week.
Access has a beginning and an end
Studios are good at granting access and almost uniformly bad at withdrawing it. The result is a practice carrying live shares to every project it has ever run, most of them to people who no longer work on anything for anybody involved. Nobody audits it, because auditing it means finding out.
Treat access the way you would treat a key. It is issued to a named person, for a stated reason, and it comes back.
| Recipient | Granted when | Withdrawn when |
|---|---|---|
| Client | On appointment. Their workspace is theirs for the project. | Converted to read-only at handover; closed if the engagement ends early. |
| Consultant | At the start of the coordination package they are engaged for. | At the end of that package. Reissue for the next one rather than extending. |
| Contractor | On award, for the construction set only. | At practical completion, once the as-built set has been issued. |
| Anyone who has left your studio | n/a | The day they leave, not the month. This is the one with real exposure. |
Put a close-out line in your project checklist: revoke every share, confirm the client's copy of the handover set, and close the workspace. Ten minutes at the end of a job.
A protocol you can actually keep
Decide the format from the recipient, not the request
Client gets PDF. Consultant gets the model. Contractor gets the construction set. Authority gets exactly the submission list. Deviating requires a reason you could say out loud.
Clean the file before it leaves
Purge, unbind, delete the frozen layers, check what's sitting outside the sheet border. Thirty seconds, every time.
Stamp the status where a photograph will catch it
The drawing will be photographed on site. Assume that, and put the status where a phone camera will pick it up.
Share with an end date
Every link expires. If the recipient still needs it afterwards they'll ask, and then at least you know they still have it.
Write the row in the register
Drawing, revision, status, date, recipient, medium. This is the step everybody skips and the one that matters two years later. See the drawing issue register.
Revoke at close-out
When a project completes, pull the access. Not because you distrust the client, but because a link that lives forever is a link nobody is thinking about.
Two of the six steps depend on something the studio has to have decided beforehand. Revoking at close-out is only possible if access was granted as access rather than as a copy, which is what a workspace per client means in practice; and a client login is only worth having if it cannot be shared around the family, which is what one-device login is for. Both are unglamorous, and both are the difference between a protocol and an intention.
None of this requires distrusting your clients, and you should say so to them plainly. Practices that explain the protocol at the outset find that clients read it as competence rather than suspicion. The studio that knows which revision is on site, and can prove it, is the studio people recommend.
It does need somewhere to run from, though. If the drawings live in a folder that was shared in March and has been drifting ever since, none of the six steps above is available to you. That's a question about what the practice runs on, and it's easier to answer before the next project starts than during it.
Share past the client, safely
AtelierLab gives consultants and contractors a private link with an expiry you set and can revoke at any moment, without a login and without opening the workspace. If the set is payment-gated, the gate travels with the link.
Questions, answered
The questions architects ask most about this, in plain language.
Ask us anythingA PDF, in almost every case. A client's job is to understand and approve, not to edit, and an editable file handed to a client is an editable file handed to everyone they forward it to. Send a flattened PDF at a stated scale with the title block and status intact. Consultants are the genuine exception, because they are building on top of your geometry and forcing them to trace from a PDF introduces error that will end up being yours.
It is convenient and it is quietly destructive. Images are recompressed, so line weights thin out and hairlines can vanish entirely, and a dimension that becomes ambiguous will still get built from. There is also no usable record of what was sent or received, and no way to withdraw it. It is fine for a photograph of a site condition or a quick question. It is not a medium for issuing drawings.
You cannot prevent forwarding outright, so aim at the thing you can control: how long a forwarded copy stays useful. Share through links that carry an expiry by default and can be revoked after the fact, rather than through a folder that stays open indefinitely. Serve files through short-lived signed URLs so a copied link cannot be hotlinked or passed around, and pull access at project close-out as a matter of routine.
Only if the watermark carries an instruction. NOT FOR CONSTRUCTION on an unapproved set does real work, because it changes what a recipient is entitled to assume. A decorative studio-name watermark does very little: it is easily cropped, it does nothing to a DWG, and it deters only the people who were not going to misuse the drawing anyway. A disciplined title block with status, revision and issue date is worth more than any overlay.
Issue it as a dated package rather than as a file: "architectural background Rev C, 18 April", with the revision in the filename and repeated in the covering note. Bind and purge the DWG first, and open it from a different folder to check what actually travelled with it — an unbound XREF is the commonest way a studio shares something it never meant to. Agree at the start of the job who holds the background, and what the studio does when it changes: who is notified, how quickly, and whether the consultant reissues. Most coordination disputes come down to a notification nobody had agreed to send.
Usually not. A consultant works on six projects for four practices and will not maintain an account per studio; a contractor needs the construction set and nothing else. What both actually want is the package, now, at the right revision. A private link with an expiry does that without provisioning anyone — they open it with no account, it stops working at the end of the stage, and the issue is still recorded on your side. Reserve logins for the client, whose relationship with the project lasts the whole job.
Consultants at the end of the coordination package they were engaged for, reissuing for the next one rather than extending the old link. Contractors at practical completion, once the as-built set has gone out. The client's workspace at handover, converted to read-only rather than closed. And anyone who leaves your studio on the day they leave, not the month. Put the whole list in your project close-out checklist; it takes ten minutes and it is the step every practice intends to do and almost none actually does.
Exactly the sheets the submission requires, in the format the local byelaw specifies, and nothing beyond it. Extra drawings sent for context are extra surfaces to be queried, and each query costs weeks. Keep the submission set as a distinct issue in your register with its own status, so it is clear later precisely what was filed and when.