A website for an architect has one job: to walk a prospective client from looking at your work to an email that names the plot, the floor area and the date. That is a different move than on a photographer’s site, where admiration and decision fit into the same afternoon. Here, weeks or months pass between the first visit and a signed contract, and the visitor comes back several times - once alone, once with a partner, once with the parent helping pay for the build.
So a practice portfolio has to do two things at once: survive repeated viewing without getting boring, and offer the same easy way to get in touch every single time. Below I lay out what belongs on that site, how to show renders and floor plans without choking a phone, and what it costs.
What the site actually has to do
Someone looking for a practice has three questions in their head, and none of them is “do you design nicely”. They assume you do, otherwise they would not have clicked. They are asking something else:
- Do you do exactly what I need done - a single-family house, an extension, an apartment interior, a warehouse, adapting a stock design
- Have you done it at my scale and in my conditions - similar size, similar plot, the same region, the same type of permit
- How does it work in practice - what I receive at each stage, who handles the paperwork with the authorities, how long it takes
A practice website that answers only the first question gets traffic and compliments. The enquiries go to the one that answers all three. The interesting part is that answers two and three cost nothing - you already have them in your head and in the files of every closed project, they just never make it onto the site.
Project cards instead of a wall of renders
The usual architect portfolio looks like this: a grid of fifty visualisations, a lightbox on click, nothing underneath. That layout assumes the image defends itself. It does, for someone who already knows what they want. A first-time client building a house cannot read from a render whether this project belongs to their world.
A project card works far better: one page per project, with a short write-up and a fixed set of facts. Here is a skeleton worth copying, because it fills in within minutes and stays comparable across projects:
| Field | Example | Why the reader cares |
|---|---|---|
| Type and brief | family house, four people, garage inside the massing | tells them whether this is their case |
| Size and plot | around 160 m2, narrow plot sloping south | shows scale and difficulty |
| General location | near Krakow | tells them whether you work in their area |
| Scope of work | concept, building design, detailed design, site supervision | shows what you take on |
| Stage | built / under construction / design only | separates a standing house from a render |
| Timeline | how long it took from concept to permit | the single fact nobody ever publishes |
Add two or three sentences about what was difficult and how you solved it. Those sentences do the real work - a client reads your way of thinking out of them, and search engines get the only text that lets them understand the image. A handful of renders per card is enough, plus one plan. The rest of the material will not be viewed anyway.
The order of cards on the home page should follow the work you want next, not the calendar. If the practice wants to move into larger buildings, those go at the top, even when the last three jobs were houses.
A fast portfolio on a phone - the technical side
An architect’s portfolio is heavy for a different reason than a photographer’s. There the problem is hundreds of frames. Here it is individual files running to several megabytes: renders saved as PNG straight out of the visualisation software, floor plans exported at print resolution, interior panoramas. A phone on a mobile connection drags a card like that in for long seconds, and the visitor spends them looking at empty rectangles.
Four things that solve most of it:
- Save renders as photographs, not as graphics. PNG makes sense for logos and drawings with transparency; a visualisation is a photographic image and belongs in a lossy format. Which format to pick and how to prepare versions for different screens, I wrote up in the piece on image optimisation
- One hero render loads immediately, everything else only once the reader scrolls to it. Not the other way round - the common mistake is lazy loading switched on across the board, which delays the first image people actually see
- Give plans and sections their own zoomable view rather than one huge image dropped into the text. A plan is read by zooming into parts of it, so a thumbnail in the body plus the full file on click works well. Vector drawings stay sharp at any zoom and weigh next to nothing
- Load panoramas and 3D walkthroughs on click. Embedded permanently in a card, they can take longer than the entire rest of the page
Checking the result takes a minute and needs no specialist: put a project card URL into PageSpeed Insights and look at the mobile score. If the practice site runs on an off-the-shelf theme with a built-in gallery and effects, the theme itself may weigh more than the images - then you start there, not with the files.
If you also shoot interiors or work with a photographer and keep a separate photo gallery, the file-preparation logic is identical; I covered it in the piece on a photography portfolio site that loads fast.
A form that qualifies the enquiry
A form with “name, email, message” produces enquiries along the lines of “how much does a house design cost?”. Answering that takes three emails before anyone even knows what is being discussed. A form with specific fields settles it up front:
- Type of investment - new house, extension, adapting a stock design, interior, commercial building
- Whether a plot exists and whether it has zoning in place
- Approximate floor area and how many people will live or work there
- Stage - just an idea, plot bought, an existing concept to finish
- Planned construction start
- Budget for the whole investment, even as a range
The budget field scares some people off, and that is its virtue. A practice with a full calendar does not need more enquiries, it needs fewer pointless ones.
Two things I always add: a note about response time (“I reply within 24 hours” beats a silent field) and the email and phone number written as plain text, because some clients will never use a form. Under every project card there should be one sentence with a button - not the whole form, just the way into it.
Copyright and consent, the part practices forget
Two things that are easy to postpone and painful later. First: publishing a project done for a client. Contracts differ on what may be shown and when - sometimes visualisations may only go public after handover, and the address never. Second: renders and photographs made by someone else (a visualiser, an interiors photographer) have their own authors and their own terms of use.
The simplest protection is a clause about portfolio publication written into the contract at the start, instead of chasing consent two years later. To be clear: this is an observation from delivery work, not legal advice - have the wording confirmed by your own lawyer.
While you are at it, tidy up the alt text on renders. It is a short description of the image for people using a screen reader, and at the same time the only information about the file’s content available to search engines, which cannot read the picture themselves.
Being found at all: architect plus city
Design enquiries are strongly local. People search for things like “architect Krakow” or “architecture practice Wroclaw”, and the search engine matches results to where they are asking from. Three things follow, all of them one-off jobs:
- The Google listing and the site say the same thing - identical name, identical address, identical phone number, character for character
- The area you cover stated outright on the contact page and in the footer, not inferred from your address
- Project cards carrying a general location - these are what surface on questions about a specific area
Whether that visibility work needs someone based in your own city, I took apart separately in the piece on whether your SEO partner has to be local.
What it costs and how long it takes
A new site for a practice I quote in writing after a conversation, billed in stages, and the figure depends on the number of pages, how many project cards have to be moved over from an old site, and whether a second language is involved. The quote has a fixed amount and a fixed scope - the risk of something taking longer than it looked sits on my side. How to read website quotes in general and where the differences between offers come from, I wrote up in the piece on how much a website costs.
Delivery with the material ready is usually two to four weeks from sign-off on the design. The long part is never the code, it is gathering renders and writing the project descriptions - which is why I ask for that material at the start, not at the end. How the process works from the organisational side is on the business websites page.
If someone has to watch over updates, backups and speed after launch, there is ongoing care - plans and prices are on the support page, and I match the plan to how much happens on the site.
Frequently asked questions
Does a practice need a site when it has a profile on an architecture platform? The profile brings traffic, but it is not your address - rules and reach change without warning, and contact runs through someone else’s form. A site gives you full project cards, a statement of scope and stages, and enquiries landing directly with you. In practice the two work together.
How many projects should an architect’s portfolio hold? Eight described projects beat fifty bare renders. A portfolio is judged by its weakest entry rather than its strongest, so cut the merely decent ones. Completeness of the description matters more than the count.
Should design fees go on the site? You do not have to publish rates, but it is worth saying what the price depends on: floor area, which stages are included, how difficult the plot is, whether you handle the paperwork. A site that says nothing at all about money generates the most enquiries from people who were never going to become clients.
My site looks good but brings no enquiries. Rebuild or fix? Diagnosis first, not a rebuild. In most cases I see, three things are missing: descriptions on the projects, a specific enquiry form, and speed on a phone. All three can be fixed on the existing site, and a rebuild only makes sense once those changes have been made and still nothing happens.
Need something like this on your side? I design and build websites for B2B companies - from scratch or as a rebuild of what already stands. Let’s talk about your project.