The project record
- Current drawing set
- RFIs and responses
- Programme dates
- Meeting minutes
- Variations
- Fee position
- Who is allocated
- Internal notes
What the builder sees
- Current drawing set
- RFIs and responses
- Programme dates
- Meeting minutes — not shared
- Variations — not shared
- Fee position — not shared
- Who is allocated — not shared
- Internal notes — not shared
The same record. A smaller opening.
Three audiences, three apertures — never one link with a password.
Portals
One record. Three depths into it
- Drawings
- Documents
- Meetings
- Site RFIs
- Site instructions
- Variations
- Defects
- Progress claims
- The practice's fee position
- Who is on it
- What the job is costing
ReachesIssued · Decisions
Behind the boundaryCoordination · Contract administration · Construction payment · The practice's own position
Progress and the decisions behind it. A client portal has no reason to reach the contract administration layer, so it does not.
No portal reaches the last layer. The practice’s own fee position, who is staffed on the job and what it is costing never leave the practice, at any depth — and because a portal reads the project record itself rather than an export of it, there is never a second version to keep in step. Depth is not the whole picture: each portal also carries that audience’s own scope and requests, which belong to them rather than sitting further in. The builder’s depth is the application’s own visibility set. No project, person, drawing, figure or link is real.
A portal is a view, not a copy.
Portals read from the Project Pod, so what an outsider opens is the project record itself. Nothing is exported, so nothing can go stale between the practice and the people waiting on it.
In short
AvailableAvailable now to practices on a qualifying plan.- What it is
- Three distinct project portals, one for clients, one for consultants, one for builders, each scoped by a private link to exactly the part of the project that audience should see.
- Who it is for
- Practices emailing drawing sets and answering the same three questions by phone every week.
- What is different
- Three portals rather than one, because the three audiences need different things. A builder portal in particular is unusual, it extends the practice's system past handover into construction.
- Availability
- Available on every plan, including the free Starter tier.
- How it connects
- Portals read from the Project Pod, so what an outsider sees is the project record itself rather than an export of it.
Part of Deliver.
Verified against the Mudo application on .
Three audiences, three portals
The instinct is to build one portal and give everyone a role. It is cheaper and it is wrong, because the three audiences do not want the same thing and must not see the same thing.
A client wants to know where the project is and what is waiting on them. A consultant wants their scope, their packages and their fee request. A builder wants the current issued set, the answers to their RFIs, and the site information.
No account, no barrier
Every portal is reached by a private, project-scoped link. Nobody outside the practice needs to create an account, remember a password, or be administered.
That matters more than it sounds. A portal an outsider will not log into is a portal that does not reduce your phone calls.
The builder portal is the unusual one
Most practice software stops at handover. Extending the same project record into construction, where the RFIs, the issued drawings and the site responses actually happen, means the practice keeps one record of the job rather than starting a second one on site.
What crosses now includes the mood board
The project's mood board — the products and materials selected for the job from the practice's own master library — can be presented through the client and builder portals. Same record as the practice edits, seen through the portal's smaller opening: the client responds to the selection, the builder sees what has been selected, and nobody is emailed a PDF that is out of date by the time it is opened.
Common questions
What is a client portal for an architecture practice?
A private view of a project for the client, covering progress, documents and decisions needed from them, reached through a link rather than an account. It exists so the practice is not the only route to the information, which is where most of the weekly phone calls come from.
Why separate portals for consultants and builders?
Because they need different things and should see different things. A consultant needs their scope, their fee request and the packages relevant to them. A builder needs the issued set, the RFIs and the site information. Giving both the client's view would be both unhelpful and wrong.
Do external parties need a Mudo account?
No. Access is by a private token link scoped to that project and that audience, so a consultant does not need to be a user of your practice system to answer a fee request.
Stop emailing the set and answering the same three questions.
Free for solo practices: one user, two projects, no card.