What it is
An artist portfolio has an awkward requirement that most small business sites do not. The content is the product, it changes constantly, and the person who needs to change it did not go to school for HTML. A painting sells. A new series finishes. An essay gets written on a Sunday afternoon. None of that should require a developer, and none of it should wait a week.
So this site is split down the middle. The pages a visitor sees are plain, fast, hand-written HTML and CSS with no framework in the browser. The paintings and writing that fill those pages live in a content management system Tamara logs into herself, and the front end pulls them in when the page loads. She publishes. The site updates. Nobody is in the way.
The design gets out of the way too. Gallery white, one red accent, and a lot of empty space, because a portfolio that competes with the art on it is a portfolio doing its job badly. The only real flourish is the grid of geometric shapes on the home page, which stands in for images without pretending to be one.
Three doors in
The site is small on purpose. Four pages, each one answering a different reason someone showed up.
Original Art
The catalog of available and past work, each piece with its own images, description, and medium tags. Everything is an original, so the gallery is a record of a practice rather than a product grid.
About Tamara
Biography and artist statement, both editable from the CMS rather than baked into the markup, which matters for the page most likely to need rewording as a career keeps moving.
Tamara Writes
Essays on process, inspiration, and the creative life behind the canvas. A working blog with its own post pages, which gives the site something to publish between finished paintings.
How it's built
This is the one project in the set that runs a real content management system, and it is worth being specific about why.
Content is organized as typed collections: projects, blog posts, and the about page, each with a defined schema so the editing screens match what the page actually needs. Rich text fields handle the biography and essays. Image fields handle the artwork. Adding a new kind of content means adding a schema, not rebuilding a page.
The front end stays deliberately dumb. It fetches published content, sorts it newest first, renders it into the grid, and falls back to a readable message if the API is unreachable. No build step runs on the public site, so a visitor is never waiting on anything but a fetch.
- Hosting Cloudflare Pages for the site, Workers for the CMS
- Front End Semantic HTML5, hand-coded CSS, vanilla JavaScript
- CMS SonicJS, an open source headless CMS built for Cloudflare's edge
- Database Cloudflare D1, with schema managed through migrations
- Media Cloudflare R2 object storage for artwork and post images
- Collections TypeScript schema definitions for projects, posts, and the about page