Context
An independent artist's website has two audiences. Visitors need room to experience the work without fighting the interface. The artist needs a practical way to publish, organize, sell, and keep the site current.
The platform was designed as a digital home for artwork, writing, events, and classes, backed by owner-managed administration. It is production-deployed and being prepared for public launch.
The operating problem
A basic portfolio would show finished work, but it would leave the rest of the practice fragmented. Artwork, event information, class registration, editorial writing, commerce, customer communication, and site settings would still require separate tools or repeated developer involvement.
The real product needed to answer two questions:
- How should the public experience feel?
- How can the owner run it after launch?
That made administration part of the product, not a hidden afterthought.
My responsibility
I worked as product designer, full-stack engineer, and technical partner. I shaped the information architecture and visual experience, built the public and administrative surfaces, connected the supporting services, and prepared the system for ongoing operation.
The collaboration required translating creative goals into concrete product behavior while keeping everyday administration approachable.
What I built
The platform brings several parts of the artist's work into one system:
- Artwork presentation and collection
- Events and classes
- Editorial writing
- Commerce and orders
- Owner-managed content and settings
- Customer communication
The production stack includes Next.js, PostgreSQL, managed identity, payments, transactional messaging, observability, and containerized delivery. Those capabilities matter because they support the experience, not because the site needs a long stack list.
The public surface stays editorial and image-led. The owner surface is organized around clear tasks and understandable state.
What I automated
Publishing, commerce, and communication are connected so routine work can move through one product. A content update should not require a code change. A customer action should create the right next step. Operational information should appear where the owner expects it.
Automation removes repetitive coordination while preserving clear points for review. The owner stays in control of what is published and how the work is presented.
How I hardened it
The project includes broad automated coverage across important behavior, production observability, and containerized delivery. Error paths and administration receive the same attention as the polished storefront because the owner experiences both.
The case study uses representative visuals and contains no customer, payment, private-communication, or security-sensitive implementation data.
Outcome
The production-deployed platform is designed to bring artwork, writing, events, classes, and owner administration into one coherent system. It gives the owner a practical path for continued use as the public launch is prepared.
The product is valuable because it supports the work after launch.
Architecture in plain language
The platform is organized around a few durable boundaries:
- A public publishing and commerce experience
- A protected owner workspace
- A shared application and data layer
- Purpose-built integrations for identity, payment, messaging, and observability
- A repeatable production delivery path
Each boundary has a clear responsibility. That makes the system easier to understand, test, and change.
Working principles
- Design the public experience around the work, not the platform.
- Treat owner administration as a first-class product.
- Connect routine workflows without removing editorial control.
- Make important state understandable.
- Build for the person who will operate the system tomorrow.
Related note: Build, automate, harden.