Service

Architecture practice website development

For directors of architecture, landscape and planning practices who need a public portfolio and a client-facing project portal built around how a project moves through its stages, rather than a brochure site and an email trail.

The problem

What goes wrong today

Where it usually starts

An architecture practice runs projects through a sequence of stages, each ending in a set of documents the client must look at and agree to before the next begins.

  • In most practices that agreement lives in email.
  • A project architect issues a concept pack as an attachment, the client replies with comments from two family members and a builder, a revised pack goes out a fortnight later, and when the planning submission is prepared nobody can say with certainty which version the client approved.
  • Drawing issues are logged in a spreadsheet per project, if at all, so when a contractor builds from a superseded drawing the practice has to reconstruct who was sent what and when.

Where it gets harder

The public website shows twelve projects photographed years ago; the current work cannot be shown because the permission conversation with each client never happened in a recorded way.

  • Fee enquiries arrive with no site address, no idea of the planning context and no budget band, so the first meeting is spent gathering information.
  • Publications and talks by the directors are listed nowhere.
  • Job applications for a Part 2 position come in by email with portfolios too large to open.
  • The practice does careful work and administers it with tools built for something else.

Scope of the service

What the build covers

A custom architecture practice build has two halves. The public half is the portfolio: projects by sector and stage, with drawings and plans handled as images alongside photography, structured case studies with brief, approach and outcome written by the practice, and a permission record on each project stating what the client has agreed to show. Practice people with roles and registrations, process explainer pages describing the stages generically and what the client receives at each, publications and talks, and a careers section where applications with portfolio uploads come in through a form rather than an inbox. The fee proposal enquiry asks for the site address, property or site type, the planning context as far as the client knows it, the intended scope and a budget band; the fee proposal itself is prepared offline in your own documents.

The private half is the client portal. Each project is set up with its stages; each stage holds the documents issued to the client, and each issue is recorded in a drawing issue register with revision, date, recipients and purpose. Clients review documents in the portal, leave comments and record an approval of a stage, which is time-stamped and tied to the exact revisions approved. The practice sees which projects are waiting on client approval and which on the practice.

Deliberately out of scope

  • CAD and BIM authoring, model hosting, contract administration with contractors, and time recording and fee accounting, which stay in your existing tools with the portal exporting what they need

When the scope grows

Scoping scenario

A twenty-person practice with residential, education and heritage work wants sector-specific case study templates, a portal where consultants such as structural engineers can be added to a project with read access to the issue register, and a careers section with role-specific application forms. That is a different build from a two-director residential practice, and the scope document names which parts apply.

Deliverables

What you receive

  • Discovery notes from following one live project through its stages with the project architect
  • A written scope document naming the public and portal modules and what is left out
  • Designs of the project case study, the fee enquiry and the portal stage view on phone and desktop
  • The build, including the client portal and issue register where in scope, deployed to your hosting or ours
  • Import of existing projects, people and publications with a redirect map for current URLs
  • Training for directors, project architects and the office manager, with a short written guide for inviting clients
  • Handover material and full ownership of the source code, your project records and your documents

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the current website, the shared drive structure for a live project, the drawing issue spreadsheet and the fee enquiry emails from the last quarter.

    Project stage: Onboarding
  2. Planning

    Discovery with a director and a project architect; sectors, stage names, document types, approval rules and the enquiry questions go into the scope document.

    Project stage: Planning
  3. Design

    The case study template with drawings and photography, and the portal stage view, are designed around how your clients actually read a drawing on a tablet.

    Project stage: Design
  4. Development

    Built in layers: portfolio, people and publications, then enquiries and careers, then the portal with stages, issue register and approvals.

    Project stage: Development
  5. Client review

    One live project is run in the portal alongside your current method for one stage, and the team reports what does not match how you issue and approve.

    Project stage: Client review
  6. Revisions

    Changes from the review are made and re-checked against the scope document.

    Project stage: Revisions
  7. Ready for launch

    Projects imported with permission records, redirects tested, a test client invited and an approval recorded end to end, launch checklist signed off.

    Project stage: Ready for launch
  8. Delivered

    New projects open in the portal from the start; hosting and maintenance continue under their own agreement if taken.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Document storage and shared drives already used by the practice
  • E-signature services for stage approvals and appointment documents
  • Large-file transfer services for drawing sets and model exports
  • Email providers for issue notifications and approval requests
  • Practice management and time recording software for project references
  • Calendar links for design review meetings
  • Analytics and consent management platforms

How we would approach it

Worked example

Concept demo

A twenty-person practice with consultants in the portal

In this scoping scenario, a practice working across residential, education and heritage projects wants its client portal to include the consultant team. The scope we would propose: projects set up with the stage names the practice uses, a drawing issue register where each issue records revision, purpose and recipients, consultant accounts with read access to the register and upload rights for their own drawings, client approvals tied to the exact revisions on screen, sector-specific case study templates where a heritage project shows survey drawings alongside proposals, and careers forms that differ for Part 1, Part 2 and technologist roles.

The custom route is needed because consultants, clients and the practice each need a different view of the same issue register, which a standard client portal does not provide.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of sectors and whether each needs its own case study template
  • Number of live projects to run in the portal and the stage structure used
  • Drawing issue register and whether consultants need their own access
  • Approval rules and whether e-signature is connected
  • Existing projects, people and publications to import
  • Careers section and the number of application forms
  • Document volume and the storage or transfer services involved
  • Hosting choice: your own hosting or ours

FAQ

Frequently asked questions

When is the package enough and when is a custom build the right route?

A practice with a handful of sectors, one stage structure and a portal used by clients only is usually served by the architecture practice package through configuration. Consultant access to the issue register, sector-specific templates or several careers forms point to the custom route, and we say which during discovery.

Do you use the standard industry plan of work for the stages?

The stages are named by you. Most practices map them to the industry plan of work they already use, and the portal simply uses those names; nothing in the build is tied to a particular scheme.

How is a client approval recorded?

The client opens the stage in the portal, sees the exact revisions issued, leaves comments if needed and records the approval. The portal stores who approved, when, and which revisions were on screen. Where a signed document is wanted, an e-signature service is connected.

Can we show projects that are still on site?

Only where the permission record allows it. Each project records what the client has agreed can be shown and from when, and a case study cannot be published without that record, which protects the practice as much as the client.

Who owns the system afterwards?

You do. The source code, project records, issue registers and documents are handed over at delivery and can be exported at any time. Hosting and maintenance are optional and separately agreed.

Get a project quote for architecture practice software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote