The problem

Artists need somewhere to show their work online, and none of the usual options work well for them:

• Squarespace / Wix: the templates all look the same, and updating anything still means learning their editor.
• WordPress: plugins, updates, security patches, hosting bills. Something breaks every six months.
• Off-the-shelf Webflow templates: cheaper up front, but Webflow is a design tool. You have to learn it to change anything meaningful.
• A custom site from a developer: fixes the design problem, but starts around €2,000 and the artist still can’t update it.

There’s a second problem underneath that one. An artist’s site is never finished. It has to grow with the work: new pieces, new series, new categories. With every option above, adding a new painting means emailing a developer or losing a Sunday to Webflow.

Why me

I’ve spent nearly 10 years designing and building websites, six of them at eBay. I’ve also sat on the other side of this, trying to put a portfolio together with tools that felt built for someone else’s job. Saora is the product I’d want if I were an artist today.

Who Saora is for

A narrow audience, on purpose:

• Working artists with a body of work who need somewhere to show it.
• Students starting to build a public presence.
• Long-time practitioners and enthusiasts who want a proper home for their work without hiring an agency.

What they have in common: they want to make art, not websites, and they have no interest in learning web design.

Decision 1: No web design, not easier web design

The usual response to “artists find websites hard” is to make the tools easier. I think that misses the point. Artists don’t want an easier web design tool. They don’t want one at all.

So Saora works the other way round from most template products. I make almost every design decision myself: layout, typography, spacing, motion, image treatment. The artist gets a small set of controls that change how their work sits in the room. Background colour. Fonts. Text colour. A choice of layout. Everything else is locked.

The cost is flexibility. In exchange, the site can’t be broken or over-designed, and nothing the artist does can make it look worse than the work it’s showing.

To make that choice concrete, every preview ships with a small live editor. The artist tries a handful of curated font pairings and colour palettes, named and safe, directly on their own work. No font pickers, no hex codes, no way to make it look worse. They settle on a look, share a link to it, and that link is the exact setting I deploy.

Decision 2: A spreadsheet and a folder as the whole interface

Instead of building a CMS, Saora uses tools artists already know. A Google Sheet holds the pieces (title, description, dimensions, series). A folder holds the images. When they add a new painting, they add a row and a file, and I redeploy the site. There’s no login and nothing to learn.

This is the decision I’m most proud of:

• For the artist, there’s nothing new to remember. Everyone knows spreadsheets and folders.
• For Saora, there’s no CMS to build, no accounts, no database, and no hosting spend eating into the price. The system stays small, which lets me stay small.

I’ll automate the redeploy step once there are enough clients to justify it. Even the manual version is faster and less error-prone than any CMS I’ve handed to a client.

Decision 3: Templates that stay behind the work

Three templates so far, each matching a different way artists think about their catalogue:

• Editorial: long-form and story-first. Works read like a magazine feature.
• Gallery: grid-first, minimal chrome. The work speaks for itself.
• Collection: categorised bodies of work with their own series pages. This one came out of my first client’s request.

The design brief for all three is the same: the template is the frame, not the painting. Typography sits beside the work instead of competing with it. Motion only appears where it’s useful, like a piece morphing from the grid into its detail page. And images get particular care in how they’re sized, compressed and presented, because on most page builders they’re treated as generic content, and it shows.

Decision 4: A boring, static stack on purpose

Saora’s pitch is that the sites are fast, secure, cheap to run and never break. The tech has to actually hold that up, so both the marketing site and the templates are deliberately boring:

• saora.co: a single static HTML file with inline CSS and vanilla JavaScript. Netlify hosts it and Netlify Forms handles enquiries. No backend at all.
• The templates: built with Astro, a static site generator. Everything compiles to plain HTML, CSS and JS at build time. Astro’s image pipeline turns a 2.5 MB JPG into a ~150 KB WebP with responsive variants. The lightbox is a native <dialog>. Fonts are self-hosted variable fonts. GSAP handles scroll reveals, Lenis smooths the scroll, and Astro View Transitions handle the morph from grid to detail.

Every one of these choices is also a business decision. No CMS means no infrastructure to pay for. No database means nothing to hack. No plugins means no security updates. Static files on a CDN cost almost nothing to serve. That’s what makes the €120 a year price work.

The first client

My first client was an artist paying too much for a Webflow site she couldn’t update herself. Every change meant hiring a developer. She wanted to reorganise her work into distinct bodies with their own categories, and every step of that was going to cost her.

I built the Collection template around that need: categories, per-series pages, and the spreadsheet workflow so she can add new work herself. Her site is now live, and her request shaped the third template in the catalogue.

That’s how I want Saora to grow. Real needs shape the templates, and each template is then ready for the next artist. The first site is live, and I’m talking with the next artists now.

What’s next

More templates, added slowly as client needs surface them. Over time I want to expand beyond 2D work into sculpture, ceramics and other physical practices, each of which presents differently. There’s no roadmap timeline. The pace is set by demand.

I’m not trying to build a big platform. I’m trying to build the right one for a small, specific group of people, one client at a time.