Insights

Why your clients want a portal, not a PDF

Every Friday, a design manager somewhere attaches a fourteen-page PDF to an email and presses send. By Monday morning it is out of date. By Wednesday the client is emailing: can you just send me the latest drawing list? Can you confirm the joinery package went out? The PDF answered yesterday's questions. The client has today's.

The report is a snapshot. The job is a film.

There is nothing wrong with the weekly report. A disciplined, quantified narrative is the single best tool for keeping stakeholders aligned, and it deserves to be written well. The problem is asking a static document to do a second job it cannot do: being the client's window into a moving project. Information delivery does not pause between Fridays. Drawings move from WIP to Shared, RFIs close, revisions step forward. A snapshot cannot show that, however well written.

What "can you just send me" really costs

Each of those emails seems small: five minutes to find the file, check it is the right revision, attach, reply. But they arrive mid-task, they interrupt design reviews, and they carry risk, because the version you attach at speed is the version you get held to. Worse, every one of them quietly teaches the client that your information is something they have to chase. That is the opposite of what your delivery should be telling them.

A read-only window changes the relationship

A client portal does one thing: it shows the published surface of the job, live, at an address the client owns. The current report. The published drawing list with revisions and statuses. The programme. Not your WIP, not your workload, not the internal back-and-forth: the polished record, always current. The chasing emails stop because there is nothing to chase. And something subtler happens: the client starts to see your delivery as an institution rather than an inbox. The project looks run, because it is, and now they can see it.

The catch was always the setup

None of this is a new idea. The reason small teams have not done it is that standing up a client-facing portal used to mean a web project: DNS, hosting, branding, permissions, another system to feed. No design manager has spare evenings for that, and no three-person consultancy has an IT department. The economics only work if the portal provisions itself the moment you add the client, feeds itself from the same register you already keep, and costs nothing extra to run.

That is how dpow.app builds it: add a client and they get a branded, read-only portal at their own address, yourclient.dpow.co.uk, showing published documents, the report and the programme. No DNS tickets, no extra licence, nothing new to maintain. The Friday report still goes out, and it is still the best thing you send. It just stops being the only window the client has.