Branditify for architecture practices
The building is photographed. The project is never explained.
A prospective client finds a practice through one image, and the site that shaped it, the programme it answers and what the practice actually did are nowhere on the page. So the enquiry that arrives says “need architect” and the practice spends a week finding out whether it was ever their project.
Practices lose good projects to unreadable portfolios far more often than to competitors.
Illustrative interface · sample data
What Branditify actually builds
The systems a practice runs on, and the work that fills them.
Two different purchases. One decides whether a serious project ever enquires; the other decides what happens to the enquiry when it does.
Systems
Where a project enquiry goes after somebody sends it.
Chosen for a job an architecture practice genuinely has, and stated with what each one does not do.
CRM
Enquiries arrive from a publication, an old client and Instagram in the same week, and by the time anyone compares them nobody remembers which had a site worth looking at.
Every enquiry carries the same attributes whatever it arrived on — project type, site, stage, source, owner and next action — so a practice can tell in a minute whether a project is theirs.
The practice stops triaging its own inbox from memory.
Usually the first system after the website.It owns the enquiry and the relationship around it. It is not project execution, and it is not a drawing register or a document-control system.
CRMClient Portal
Drawing revisions and decisions live in an email chain, and a client asks in month five which option was approved in month two.
A controlled client-facing place for what a practice chooses to publish — selected documents, updates, requests and the decisions that were actually made.
An approval has a date against it, and the client can look instead of asking.
Optional, and genuinely useful on longer projects.It is a window onto what a practice decides to share. It is not a common data environment, not document control and not BIM — Branditify does not claim to sell any of those.
Client PortalBooking Platform
The consultation is agreed in principle and then takes five messages to actually place in a week.
Real consultation availability, the booking, and the confirmation that follows.
The moment somebody is convinced is the moment they can act.
Optional. Practices that prefer to speak first often never need it.It owns the time and the confirmation. It does not hold the enquiry that never booked.
Booking PlatformMost practices need the website and the CRM. The portal earns itself on longer projects, and booking only where consultations are actually scheduled rather than arranged.
Services
The work that makes a portfolio legible.
Systems organise what arrives. This decides whether anything arrives, and whether it arrives with a site attached.
Premium Websites
Twelve projects, four hundred photographs, and no way for a prospective client to tell which of them began with a plot anything like theirs.
Projects built as project files rather than galleries — the site and what it demanded, the programme, what the practice handled, the design thinking, the drawings worth showing, and a way to share a project from the project itself.
A visitor can work out whether this practice has done their project before.
Branding & Identity
A lowercase wordmark, a grey palette and a grid — and a practice with a genuine position reads as interchangeable with forty others.
An identity with its own logic, applied consistently from the site to the portfolio PDF to the drawing sheet and the presentation.
The practice is recognisable before the work is even looked at.
Content
The practice explains its thinking brilliantly in a first meeting, and nowhere before one.
Project narratives that carry the site and the programme, the practice’s position, how a project actually runs, and the questions every prospective client asks before they will send anything.
The first meeting starts further along.
Social Media
Site photographs, models and details get real attention, and everything they earn lands in a direct message.
Work in progress, models, drawings and finished buildings turned into a consistent stream that points at a project page which can actually answer.
The channel that creates the interest stops being the one that has to handle it.
SEO & AEO
The practice is findable by name and by nothing else, so every enquiry comes from somebody who already knew it existed.
Project types, building types and the places the practice works given real pages, and the questions asked before choosing a practice answered where they are searched.
Enquiries start arriving from people who were not already following.
The first problem, and it is not the photography
A photograph shows the building. It cannot show the site.
The images are usually the best thing a practice owns, and they are also the least useful thing on the page for somebody deciding whether to enquire. A façade at golden hour says nothing about the plot it sits on, what the client needed, or which part of it the practice was responsible for.
Everything above is illustrative. Real project pages carry only what a practice can evidence — no area, cost, programme duration, award or certification is invented to make a project look larger.
How should architects present projects online?
As project files rather than galleries. A prospective client is not judging composition — they are trying to work out whether their own situation resembles anything the practice has done. That means the site and what it demanded, the programme the building had to answer, what the practice actually handled, and the thinking behind the response. A drawing often does more of that work than a photograph, which is why practices that publish a plan or a section alongside the images tend to get better enquiries from them.
The second problem
“Need architect. House. Call me.”
Every practice can quote the enquiry it dreads, because it arrives most weeks. It is rarely a bad client — it is a client who was never asked anything. The practice then discovers the site, the stage and the scope one message at a time, before anyone can say whether the project was ever theirs.
The same interest, asked four things while they were still reading the project that convinced them.
How can an architecture practice qualify project enquiries without deterring people?
By asking for the few things that change the answer, at the moment somebody is convinced. Project type, where the site is, what stage it is at, and roughly what the building has to do. Four questions take under a minute and turn an unanswerable message into something a principal can respond to properly. What deters people is a long form that reads like an application — a mandatory budget field, a dropdown of services they have not heard of, and a question about how they found you.
The third problem
A practice is understood through its projects, or not at all.
Prospective clients rarely read an about page and conclude anything. They form a view of how a practice thinks by reading two or three projects — which means the positioning has to live inside the project pages, not beside them.
Should an architecture practice explain its process online?
Yes, in its own words, because practices genuinely differ and the differences matter commercially. Where the practice engages and where it stops, whether it takes projects through construction or hands over after approvals, how many site visits are in scope, what happens before a fee proposal. A client who cannot find this asks for it in the first call, which turns a design conversation into an administrative one.
One possible setup
From a published photograph to a project the practice owns.
One arrangement that works, not a package. Every step already happens in a practice; the only change is that it becomes visible and stops depending on who checked which inbox.
The portal, booking and dashboards are optional layers. A practice taking four projects a year may never need any of them.
What should an architecture practice digitise first?
The project pages, because everything downstream depends on them — a CRM full of “need architect” is a tidier version of the same problem. Once projects carry their site, programme and the practice’s role, the enquiries they produce are worth organising, and that is the moment a CRM earns itself. A client portal and booking come after that, and only if project length or consultation volume actually calls for them.
The questions practices actually ask
Five decisions worth getting right before anybody quotes you.
Each of these gets sold badly in this category, and almost always upwards.
Does an architecture practice need a CRM, or is an enquiry form enough?
A form is genuinely enough while one person reads every enquiry and remembers every conversation. It stops being enough at a recognisable point: when enquiries arrive from more than two places, when more than one person replies, or when the practice has started discovering missed follow-ups after the fact. Before that a CRM is admin; after it, it is the difference between a pipeline and an inbox — and in a business where one project can be a year of fee income, a lost follow-up is expensive.
Relevant work, described exactly
Urban Cube 71.
A construction brand in the built environment, and the closest documented work to this sector. It is shown for the identity it received and for nothing else — the sector is adjacent, the discipline is not architecture, and both of those are stated rather than blurred.
Urban Cube 71
A brand identity for a construction company working in modern building and urban development — logo, identity system and design elements built around structure and permanence.
Shown for identity work in the built environment.
View Urban Cube 71Questions practices actually ask
The rest of it, answered directly.
What should an architecture firm website include?
Projects built as project files — the site and what it demanded, the programme, what the practice handled and the thinking behind the response — alongside the building types it takes on, where it works, where it engages and stops, and a way to share project context from the project itself rather than from a contact page.
Portfolio or case study for an architecture practice?
Both. The portfolio earns attention; the project file converts it by answering the questions a prospective client is already asking silently — what kind of site was this, what did the building have to do, and what was this practice responsible for. A grid of photographs answers none of them.
How can architecture firms get better-qualified enquiries?
By asking four things at the moment somebody is convinced: project type, where the site is, what stage it is at, and roughly what the building has to do. The enquiry then arrives answerable instead of arriving as a research task.
What should an architecture project enquiry form ask?
Project type, site location, project stage and an outline of the accommodation. That is usually enough for a principal to tell whether the project is theirs. Everything else belongs in the consultation, and a long form at this point costs more enquiries than it filters.
Does an architecture practice need a CRM?
Once enquiries come from more than two places or more than one person replies, yes. A CRM gives every enquiry the same attributes — type, site, stage, source, owner, next action — so a reply stops depending on who happened to be reading which inbox. In a business where one project can represent a year of fee income, a missed follow-up is expensive.
CRM or project-management software for an architecture practice?
They do different jobs. A CRM holds the prospective project — the enquiry, the relationship and the follow-up before there is an appointment. Project management runs the work after it is won. Branditify builds the first and connects to whatever a practice already uses for the second.
Client portal or project management for architects?
A client portal is a controlled client-facing window onto selected documents, updates and decisions. Project management is the internal execution of the work. They can connect, but a portal is not a common data environment, document control or BIM, and Branditify does not claim to supply those.
Should architecture firms explain their process online?
Yes, in their own words. Practices genuinely differ on where they engage and where they stop — concept only, through approvals, or through construction — and a client who cannot find this asks in the first call, which turns a design conversation into an administrative one.
Website or Instagram for an architecture practice?
Both, doing different jobs. Social and publications carry the work to people who were not looking, and that is where much of the attention in this profession originates. The website holds what has to stay findable and structured — projects with sites and programmes, what the practice takes on, where it works — and a post from March is not findable in September.
How can SEO help an architecture firm?
By making project types, building types and the places the practice works into real pages, so enquiries can come from people who were not already aware of the practice. Discovery here is partly local and partly project-type driven, and both need somewhere to land. No ranking or traffic figure is promised.
Local SEO or broader visibility for architects?
Usually both, weighted by the work. Site-based projects have geography, so the places a practice takes projects deserve real pages. Practices known for a building type also attract enquiries from well outside their city, and those arrive through the project-type pages instead.
Should an architecture practice show project types and locations?
Yes. They are the two things a prospective client uses to decide whether to bother enquiring, and leaving them out does not widen the funnel — it just moves the question into an email the practice then has to answer.
Does an architecture practice need a mobile app?
Almost never as a marketing decision. A responsive website handles finding the practice, reading a project and sending context. An app needs repeated logged-in behaviour that a browser makes worse, and a client who builds once does not have any.
Can existing portfolio and project content move to a new website?
Usually, where the practice holds the rights. Photography, drawings it owns, written descriptions and existing pages can be migrated. What rarely moves cleanly is project detail that only exists in a photographer’s drive or an old email thread.
Can an architecture website connect to a CRM or consultation booking?
It depends what the tool exposes. Some connect directly, some through an integration layer, and some are honestly a manual step — worth establishing before a contract rather than after. Project context captured on the site can be delivered into whatever the practice already runs on.
Who owns the website and content after a custom build?
The practice does — code, content, images, drawings, data and accounts in its own name, on infrastructure it controls, with no dependency on Branditify to keep running.
What determines the scope of an architecture website project?
How many projects deserve a full project file, how many building types the practice wants to be found for, whether more than one location matters, and whether anything needs migrating. Not a page count.
If this is the practice you run
Start with three projects and the enquiry they should produce.
The first conversation is usually about which projects deserve a full file, which building types the practice wants to be known for, and where the enquiries currently land. That is normally enough to see what to build first and what can wait.