Start with a month of real editing tasks.
Before selecting a publishing system, list the changes your studio expects to make. Adding one completed house twice a year is a different job from managing several architects, hundreds of projects and multiple languages. A system that is convenient for developers may be frustrating for the person responsible for uploading photos.
For each task, identify who will make the change, how often it occurs and whether it must go live immediately. Include ordinary work, not just the exciting launch content: correcting credits, replacing a render with a built photograph, changing project status or retiring a team member's profile.
| Change | Typical editor question | System requirement |
|---|---|---|
| Add a project | Can I publish it myself? | Reusable project template and reliable preview |
| Reorder images | Will the crop change on mobile? | Visual ordering and responsive image controls |
| Correct a credit | Where is this photographer named? | Easy editing and traceable publication |
| Update services | Can I edit a paragraph without changing layout? | Safe text fields and consistent design rules |
| Translate a project | Is the other language ready? | Per-language publication status and stable links |
Ask the person who will actually maintain the website to describe three changes they made to a project presentation last month. If the new workflow makes those tasks harder, a longer feature list will not save it.
Static pages, a conventional CMS or a headless CMS?
These are approaches, not product rankings. A static website can still use structured source data and a build script. A conventional CMS typically combines editing and page presentation. A headless CMS separates the editor's content from the website's front end. All three can work well when they match the team and maintenance plan.
| Approach | Usually suits | What to watch |
|---|---|---|
| Static or code-managed | A small, rarely changing portfolio with technical support | Who publishes updates when the developer is unavailable? |
| Conventional CMS | Editors who want to manage pages in one interface | Theme flexibility, upgrades, permissions and maintenance |
| Headless CMS | Structured projects reused across layouts or channels | Integration, preview, hosting and ongoing developer responsibility |
None is automatically faster, cheaper, more secure or better for search engines. Those outcomes depend on implementation, hosting, updates and the people maintaining the system. Do not choose a CMS solely because it promises a particular SEO result.
When no full CMS is necessary
If you publish a handful of projects every year and are happy to request occasional technical changes, a simple static system may be entirely reasonable. But make that dependency explicit in the handover. “Easy to update” means very little until you know who will perform the update.
When structured editing pays off
For a growing archive, one project form is safer than copying and pasting entire layouts. Editors can work with project facts and images while the front end applies the same typographic and responsive rules everywhere. The useful feature is consistency, not the existence of a dashboard.
Design the project record before the editor screen.
The content model is the foundation of a maintainable portfolio. It defines what every project needs, what remains optional and which facts must not be invented to fill an empty field. A project title is mandatory; an area or construction cost may be unknown or confidential.
The fictional project demonstrates fields, not Atmosferi's completed client work. An actual website should use the terminology and approval requirements of its practice.
Separate facts from marketing prose. A project status should come from a controlled list rather than variations such as “work in progress”, “ongoing” and “almost built”. If credits or photographer permissions are mandatory, the publishing workflow should flag missing information before a page goes public.
Do not put every project into one free-text field.
A single rich-text block can be convenient for an unusual story, but it makes it difficult to generate a consistent index, filter by building type, display project dates or reuse the same facts elsewhere. Structured fields and a flexible narrative section can coexist.
Images need a workflow, not only an upload button.
Architecture websites often depend on large, carefully composed images. The editor must know which file is the master, which image opens the project, how gallery order works and who approved publication. A photograph should not lose its important subject because a thumbnail crop is reused as a full-width hero.
- Keep masters separately: preserve high-resolution originals for future crops and exports.
- Record credits and rights: do not assume uploading a file grants publication permission.
- Provide captions and alt text: describe what matters in the image, rather than stuffing keywords.
- Preview different widths: confirm that portrait, landscape and detail images retain their intended composition.
- Generate appropriate sizes: serve responsive image variants without making a phone download a huge master.
The guide to preparing architectural project material covers the selection and preparation of photographs and drawings. The CMS decision comes afterwards: how the studio will publish and maintain that material reliably.
Multilingual editing is more than switching a language flag.
If a studio publishes in two or more languages, decide whether every project must be translated or whether some will remain in one language. Each published language version needs a complete page in that language, its own appropriate metadata and a stable URL. An editor should be able to see which translations are draft, approved or published.
Language alternates are for genuine counterparts of the same page. A German project detail should link to its real English equivalent, not the English homepage. A page without a translation does not need a fabricated alternate. Translated architectural terminology should be reviewed by someone familiar with the relevant market.
Changing a project's title should not silently change its public URL. Plan how slugs are approved and how redirects work when a page genuinely moves. The same principle applies to project merges, deleted pages and a future site redesign.
Build an approval path that protects the portfolio.
There may be only one editor today, but it is worth separating drafting from publication. For a practice where multiple people contribute material, decide who can upload images, edit factual project information and approve a page for the public site.
- Draft: the editor adds the project's text, facts, credits, photographs and optional drawings.
- Review: someone verifies status, roles, sensitive location details and image rights.
- Preview: the team checks the actual page on desktop and mobile before publication.
- Publish: the approved change reaches the live website with working links and metadata.
- Correct: an error can be fixed quickly, with a clear way to restore earlier content if necessary.
These steps need not be a complicated software workflow. For a solo architect, a written checklist may be sufficient. For a larger office, named roles, revision history and preview links can prevent accidental changes to published work.
Who updates the CMS itself, who backs up content, who checks the contact form, and who notices a failed deployment? Those responsibilities belong in the website agreement and handover. A publishing interface alone does not maintain the whole site.
Test the ordinary editing tasks before signing off.
Do not accept a content management system after seeing only its demonstration interface. Use it with one real, approved project and ask the actual future editor to complete the process. The result must look correct on a published page, not just in the editor.
- Add a new project with title, status, date, role, images and credits.
- Reorder a gallery and check its layout on desktop and mobile.
- Correct an existing project caption without editing code.
- Save a draft without making it public and share a safe preview.
- Check what happens if a required credit or image description is missing.
- Publish one language without falsely claiming an unpublished translation exists.
- Rename a project without unexpectedly breaking its URL.
- Document backups, updates, access permissions and who handles a failed form.
- Confirm who owns the content and how it can be exported if the studio changes provider.
If the editor can complete those tasks confidently, the CMS is doing its job. If every minor change still requires a developer, that may be a valid service arrangement, but it should be an explicit decision, not a surprise after launch.