A pattern I keep seeing with architecture studios. The studio commissions $20,000 worth of professional photography of a finished project — wide shots, detail shots, hero spreads, the kind of imagery that runs in Habitus or ArchitectureAU. Then the studio puts the work on a website where the images load slowly, crop awkwardly on phones, sit inside a grid that doesn't suit them, and ultimately look like a lesser version of the printed page.

This is not the photographer's fault. It's almost never a question of source image quality. It's the technical and editorial choices being made by whoever built the website — and those choices are usually made by people who don't think about images the way architecture studios do.

The opinion: most Australian architecture studio websites are doing photography that's already paid for a disservice, and the fix is a combination of build-time decisions (image pipeline, format, sizing) and editorial decisions (which image leads, how the project is presented, what context the work needs). Neither half works without the other.

This post is both halves.

The case for sticking with what you have

Before the takedown, the case for the typical setup.

Most architecture studios use Squarespace, Cargo, or a Webflow template designed for portfolios. These platforms are visual-first, easy for the studio to update, and avoid the cost of a custom build. The trade-off — performance, image handling sophistication, layout flexibility — has historically been considered acceptable because the work itself does the heavy lifting.

There's also a real argument for the constraint. A studio that doesn't have a developer on retainer needs a platform it can update independently. A custom-coded site that requires a developer for every project addition is a long-term maintenance liability that template platforms avoid.

Both arguments have merit. They are also both more defensible at the small studio scale (1–3 architects, occasional updates) than at the mid-to-larger scale (5–25 architects, regular project releases, awards submissions).

For any studio doing AIA awards submissions, magazine features, or competing for $500K+ briefs, the website is part of the pitch — and the typical setup is leaving real money on the table.

The technical half: why images look worse than they should

Six specific technical issues, in roughly the order they cause damage.

1. Source images get downsampled by the platform

Most template platforms re-encode and compress images at upload. Squarespace downsamples to a maximum width (usually around 2,500px). Webflow does similar. The compression algorithm is usually quality-good-enough, but the loss is visible to anyone looking carefully — which is exactly the audience for an architecture portfolio.

A photographer's TIFF or 16-bit JPEG at 6,000px wide arrives on the website as an 8-bit JPEG at 2,500px wide with default compression. The fine detail in a finely-shadowed timber ceiling, the tonal subtlety in a north-facing render, the highlight detail in a concrete wall — all degraded.

The fix on a custom-coded site is a deliberate image pipeline. Source images stay full-resolution. Build-time processing generates WebP or AVIF variants at multiple sizes with controlled quality settings. The browser picks the right variant for the viewport. Quality is preserved where it matters and bandwidth is saved where it doesn't.

2. Modern image formats are not being used

WebP and AVIF deliver equivalent visual quality at 30–50% smaller file sizes than JPEG. Browser support has been universal since 2023 (WebP) and 2024 (AVIF for all major browsers).

Most template platforms still serve JPEG by default, which means each project image is 2–3x larger than it needs to be on the wire. Page load time suffers, mobile data costs are real, and the platform's image cap (the 2,500px downsample above) is partly compensating for an inefficient format choice.

A custom build using Next.js's <Image> component, or a hand-rolled <picture> element, can serve AVIF to browsers that support it, fall back to WebP, and fall back to JPEG only for ancient clients. The result is visually identical, perceptually faster, and meaningfully cheaper to serve.

3. Responsive sizing is not happening properly

A hero image at 4,000px wide is appropriate on a 27-inch monitor. It's grotesque overkill on a phone, where the device is 400px wide and the screen density is 2x, meaning 800px wide is the most that's ever needed.

Without proper responsive image sizing, phone users are downloading the desktop image and the browser is scaling it down. Page weight on a mobile project page is often 8–15MB when it should be 1–3MB. Load time is twice as long as it needs to be.

The <picture> element with proper srcset and sizes attributes is a 30-year-old web standard that template platforms still do badly. A custom build does this correctly by default.

4. Largest Contentful Paint is too slow

Google's Core Web Vitals include Largest Contentful Paint (LCP) as a ranking factor. The threshold for "good" is under 2.5 seconds. Architecture portfolio pages with a heavy hero image typically hit 4–6 seconds on a mid-range mobile device on 4G.

The fix involves preloading the hero image, inlining critical CSS, deferring everything below the fold, and serving the LCP image at exactly the right size from a CDN-edge cache. None of this is exotic engineering. It's just not what template platforms do.

The business impact: pages over 5 seconds have bounce rates above 38%, versus 9% for pages under 2 seconds, according to widely-cited Google research. For a studio whose website is a major part of the pitch, that's a substantial fraction of qualified prospects bouncing before they see the work.

5. The image gallery interaction is wrong for architecture

Most template galleries are designed for general portfolio use — lightboxes that pop up, swipe interactions, modal overlays. For architecture work specifically, these patterns are usually wrong.

What works better for architecture portfolios is project pages where:

The hero image occupies most of the first viewport with strong aspect ratio control
Subsequent images flow inline with context (project description, materials notes, plans) interleaved
Plans and sections appear at large enough size to actually read
Detail shots have proper aspect ratio and resolution
Captions sit beside or under images, not on hover

This is a layout problem more than an image problem, but template platforms generally don't give you the flexibility to design project page layouts properly. You get the gallery the template provides.

6. CDN distribution is suboptimal

A studio in Melbourne with prospects in Brisbane, Sydney, Auckland, and the occasional Singapore enquiry needs images served from edges close to those locations. Template platforms have CDNs, but they're often slower than purpose-built image CDNs (Cloudflare Images, imgix, or Vercel's image optimisation on a custom site).

The latency difference is small (50–150ms) but visible on first impression, especially for image-heavy pages where multiple images load in parallel.

The editorial half: why projects look undersold even when images load well

The technical fixes are necessary but not sufficient. Even with a perfectly-built image pipeline, most architecture studio websites present projects in ways that undersell them. Three patterns.

1. The hero image is wrong

The instinct on most project pages is to lead with the most photogenic image — usually a wide exterior shot at golden hour. That image is often the wrong choice as the hero.

The hero is the image that has to do three jobs at once: communicate what the project is, draw the visitor in, and set the tone for the rest of the page. A wide exterior shot communicates "building exists." It often doesn't communicate what's interesting about the building.

For a heritage adaptive reuse, the hero might be a detail shot showing the junction between old and new. For a residential project, the hero might be the room that defines the project, not the street elevation. For a commercial fit-out, the hero might be the people-eye-level view of the space in use, not the architectural overview.

Choosing the wrong hero is editorial timidity dressed up as professionalism. The brave choice usually converts harder.

2. The project description is too short or too long

Most studios go to one of two extremes. Either they publish 50 words of "designed in collaboration with X, completed in Y, located in Z" and nothing else, or they publish 800 words of design rationale that nobody reads.

The right length for a project page description is usually 200–400 words, and it should answer specific questions: what was the brief, what was the constraint, what did you decide and why, what does the client say about it now. Plain language, no jargon, no excerpts from the architectural statement.

A prospect — or an awards juror, or a journalist — reading the project page wants enough context to understand what's distinctive about the work. The architectural statement that ran in the AIA Awards submission usually isn't the right text. It's the text that comes after, written for someone who's interested but doesn't know the brief.

3. There's no context about how the project came to be

A project page that's just images plus the architectural description is missing the most useful content for a prospect: how the project actually happened.

Did the client come through a referral or a website enquiry? What were they originally asking for? What was the budget, the brief, the timeline? Were there major decision points where the project could have gone differently?

This is the content that helps a future prospect imagine themselves in the same conversation. "This was a couple in Hawthorn who'd lived in their 1920s weatherboard for fifteen years and wanted to add a kitchen / living wing without losing the period character. The brief said modest. We pushed back on a couple of elements at design development and the result is more ambitious than the original brief suggested." That's worth pages of architectural-statement-speak.

What a properly built architecture studio website looks like

Five characteristics.

Images are served at appropriate quality and size for every viewport. Hero images preload. AVIF and WebP variants are generated at build time. Source images stay full resolution and the build pipeline does the rest. LCP under 2.5 seconds even on mid-range mobile.

Project pages have a flexible layout that suits each project. Some projects want a full-bleed hero. Some want a paired hero with plans. Some want the description first. The template platform constraint of "all projects use the same layout" gets relaxed for projects that benefit from it.

The hero image is editorially chosen, not photographically chosen. The brave choice, not the safe one.

Project descriptions are written for the prospect, not for the awards jury. Short, specific, honest about how the project happened.

The site has performance and SEO foundations that actually rank. Architecture studios usually rank for project names and the studio name only. A properly built site can rank for typology + location queries ("heritage renovation architects Melbourne," "warehouse conversion architect inner west") which is where genuine new-client search demand sits.

The cost reality

For an Australian architecture studio with 10–30 completed projects to publish, a custom-built portfolio site sits in roughly the $15,000–$40,000 AUD range depending on the level of design work, the complexity of the project page layouts, and how much editorial content writing is needed.

That's compared to $4,000–$12,000 for a template platform setup with photography support.

The cost differential — somewhere in the order of $10,000–$30,000 — is real. The payoff is conditional on how much the website is doing for the studio's pitch. For a small studio doing one or two residential projects a year from referrals, the template setup is genuinely fine. For a mid-sized studio competing for institutional, commercial, or high-end residential work where the website is part of the qualifying process for $200K+ briefs, the custom build pays for itself on the first or second brief that wouldn't have closed otherwise.

The honest bottom line

Your projects look worse on the website than they do in real life because the platform you've built on was not designed to do justice to photography you've already paid for. The technical half of the fix is a deliberate image pipeline, modern formats, proper responsive sizing, and performance-conscious build choices. The editorial half is bravery in hero selection, brevity in description, and honesty about how the project came to be.

A studio whose website is meaningfully better than its peers on both halves competes harder for the briefs where the website is part of the qualifying process. That's most briefs above $200K in the residential, commercial, and institutional sectors.

If you want to see how your current project pages stack up — including LCP measurements, image format analysis, and a read on the editorial choices — run the site through our audit. We'll tell you what's costing the most and what would lift the work fastest.

Why Architecture Sites Make Your Work Look Worse (2026 Fix)