Your client rings about the kitchen layout. You have a revised drawing open. They have the attachment you sent before the meeting, and neither of you realises you're discussing a different version.
In this hypothetical architectural practice, a client portal gives you both a shared starting point: the drawing issued for review, the question it relates to and the response still needed. Your next conversation can then be about the design rather than finding the attachment.
Your client signs in and sees the current project stage, the documents you've issued and anything needing their response. You keep working files and internal comments out of that view.
Each issued document needs an identity, revision and purpose. The newest upload isn't automatically the right document for a contractor to use, and the most recent file may still be awaiting review.
We design around the distinction between a working file and an issued document. Getting that right gives your client a clear place to look and gives you confidence about what they have been asked to review.
Suppose you ask your client to review a layout. Your portal could record which revision they saw, the question you asked, their response and when it was submitted.
That's more useful than an isolated tick labelled approved. Your professional procedures still determine what the response means. A portal record doesn't replace a statutory approval or establish that a design is suitable for construction.
If you issue a revision that changes the question, the previous response should remain in the history without silently approving the new version. You can then tell your client exactly what needs another look.
Your client can ask about a particular drawing or decision. You reply with the context visible, and whoever handles the next call can see the exchange.
Notifications should bring people back to the relevant item. You don't need a new email for every minor edit, and you shouldn't expose private project details in a message preview.
This develops the idea behind useful client self-service: remove repeated explanations while keeping a straightforward route to help.
If you only need controlled document sharing, look at the tools you already own. Microsoft 365, for example, has configurable external-sharing controls. Check the actual settings and client experience rather than assuming a shared folder is either unsuitable or automatically safe.
We favour a custom-built portal when your issued documents, questions, responsibilities and project stages need to work together in a way your existing tools don't support. Adding several unrelated plugins to a public website can leave you maintaining the links between them yourself.
Custom development doesn't remove the security work. Your application must check which project and documents a person is allowed to access. OWASP's guidance on authorisation describes the underlying principle: permission checks belong on each request for protected information.
You could use AI to draft a plain-English summary of an issued update for you to check. It shouldn't interpret a drawing as a professional instruction or tell your client that an unconfirmed change is agreed.
The portal earns its place when your client can find the issued drawing, understand the question and respond in context. That gives you more useful conversations and a history you can return to when a decision is revisited. A well-designed project view does much of that work with ordinary software.
Our client portal development focuses on those connected journeys, from the document you issue to the response your office needs.
You can test the idea at your next drawing review: how much of the call goes on finding the right version? Get in touch if you'd like to improve that part of the project.
We're proud to have been recognised as Wales' Most Trusted Web Design & Development Company for 2025. This award reflects our commitment to delivering exceptional digital solutions and outstanding client service that sets the standard for excellence.
