Case Study: Art Gallery + App
A WooCommerce art gallery with augmented reality painting previews, a Flutter app that shows the work in your space before you buy, and a custom plugin suite I built specifically for how a working artist studio actually sells.
Overview
Danielle runs a working art studio. She paints originals, prints limited editions, and sells through the website. Standard WooCommerce wasn't built for original artwork. There's no concept of a one of a kind piece that's gone when it sells, no way to mark something as SOLD with context rather than just deleting it, and no way to show the buyer what the painting looks like at life size on their wall before they commit.
So I built what was missing. A custom plugin suite that handles the art gallery's specific needs: SOLD badge display with history tracking, a commission inquiry form, an artwork dimenions field, category filtering for the gallery view, and a Related Works shortcode. On top of that I built a Flutter progressive web app with augmented reality, where the buyer can point their phone camera at their wall and see the painting at real scale.
The AR feature is the part I spend the most time explaining, but it sells the hardest when people actually try it. Danielle uploads a photo of the painting and a short video. The AR target gets compiled in the browser. The Flutter app opens a camera overlay and shows the work in the room.
"Selling original art online has one central problem: people can't tell how big it is or whether it will work on their wall. The AR preview solves that directly."
Signature Feature
Danielle does the entire setup from the WordPress admin. No technical knowledge required after the initial build I did. The whole pipeline runs from her laptop.
Danielle uploads a straight photo of the painting and a short video of it hanging in the studio. Both go into the rds-ar-manager plugin.
The plugin compiles the AR target in the browser. No processing on my server, no external AR service subscription. The target image descriptor is stored with the product.
The Flutter PWA at flutter.rds.ink reads the product data via REST API. The buyer taps "View in your space" and the app opens a camera overlay showing the painting at real scale on their wall.
The AR feature works well on mid range Android and current iOS. Older phones with limited camera APIs see a standard overlay without full spatial tracking. It's a real improvement for most buyers, not a universal replacement for visiting the studio. I document this clearly in the app.
Custom Development
Standard WooCommerce treats every product the same. I wrote these plugins because original artwork isn't the same as a T shirt. Each one fills a specific gap in how the gallery actually works.
Commerce Layer
Running Duck Studio sells two things: original paintings at original prices, and print reproductions via Gelato. Gelato handles fulfilment. They print and ship from the production facility closest to the buyer, and the WooCommerce integration I set up connects the two.
Each original is a single WooCommerce product with a custom SOLD state I built. When it sells, the product switches to SOLD, shows the sold price and date, and remains visible as portfolio history rather than disappearing from the site.
Limited edition prints are fulfilled by Gelato. The buyer places a WooCommerce order; Gelato picks it up automatically and handles printing, packaging, and shipping. No inventory, no fulfilment work on Danielle's end, and nothing manual for me either.
The commission form (part of rds-core) captures buyer requirements, preferred size, colour palette, and budget. It feeds into a structured email workflow rather than a generic contact form. Danielle gets everything she needs in one message.
Gelato's WooCommerce API has specific requirements around product variant mapping that I had to document carefully. When Gelato updates their product catalogue, variant IDs can change and previously mapped products need relinking, so it is important keep the variant mapping current. It's not a set and forget integration. I handle those updates as part of the ongoing management relationship.
Mobile Experience
The Flutter progressive web app I wrote at flutter.rds.ink is an 8.4 MB build that runs in the browser on any device. No app store download required. The buyer opens it from their phone browser or via a QR code on the gallery page.
The app reads product data from the WordPress REST API on launch. Featured collections, theme colours, and the gallery structure all come from the rds-flutter-config plugin, so the app stays in sync with the website without being redeployed every time Danielle adds a new collection.
Core screens: gallery browse by category, individual artwork detail with AR trigger, Danielle's story, commission inquiry form, and a direct link to the WooCommerce cart. I run the cart in a WebView pointed at the WordPress site so I don't duplicate the payment integration.
Works on Android and iOS via the browser. Users can add it to their home screen and it behaves like an installed app. The service worker caches the gallery for offline browsing.
The app reads the product catalogue via REST API. New artwork appears in the app automatically when published in WordPress. I don't need to redeploy anything for content updates.
Purchases complete through the WooCommerce site inside a WebView. No duplicated payment integration, no Stripe keys managed in two places.
Technical Details
The platform runs on shared infrastructure on the same Brisbane server as the rest of my portfolio. Total hosting cost for rds.ink and the Flutter subdomain is included in the Tailored Website Management plan at $200/month. Gelato charges per print fulfilled; there's no monthly fee for their integration.
Standard WooCommerce is a solid foundation. The question is whether it fits what you actually sell. If it doesn't, I build the parts that are missing.