Pottery studio software that follows every piece from wet clay to pickup.

Pottery studio management software runs the piece journey in a ceramics studio. It takes a piece from the moment a member leaves wet clay on the shelf, through the bisque load and the glaze load, to the day the member picks up the finished work. It keeps the piece, the member, the firing stage, the firing fee, the shelf, and the pickup date in one record. It can also cover memberships, class rosters, wheel bookings, and the member tab, so the studio stops running on a clipboard, a wall chart, and whoever remembers.

Every piece gets its own file at intake, with the member, a photo, the clay, the size or weight, and the shelf it sits on. The record moves through the same stages for every piece: wet clay, dry and ready for bisque, in the bisque load, glazed, in the glaze load, fired and cooling, ready for pickup. When a piece is loaded, it is ticked into that load with the cone and the target unload date. Staff see the queue; members see their own pieces. A piece with no record is a piece nobody can find, so intake is the step that makes the rest of the system work.

Members check the queue themselves. Each load shows its type, its cone, its load date, and its expected unload date, and each piece in it is tied to its member. When the load is unloaded and the piece is on the ready shelf, the member gets a message that their work is cool and ready to collect. The front counter stops being the status desk. That only works if the queue is updated when the load moves, not at the end of the week, so loading and unloading are part of the job, not extra admin after it.

Firing fees follow one rule the whole studio can explain. Studios commonly charge by volume, by weight, or by size band, and the same rule applies to bisque and glaze loads. The fee is worked out from the piece record at intake, so the member sees the charge before the piece goes in the kiln, and the charge lands on the member tab instead of being worked out by hand at the counter. The rule itself is the studio's call: the software applies it the same way to every piece, and the studio can change it without rebuilding the system.

The queue is a list of loads, not a pile of notes. Each load has a type, bisque or glaze, a cone, a load date, and an expected unload date. Pieces are added to a load until it is full, and the load moves through loading, firing, cooling, and unloading. Members see the next firing date and where their pieces sit in the queue. A full kiln fires better and wastes less heat than a half-empty one, so the queue also shows how full the next load is, which is the honest reason a piece sometimes waits for the next firing.

Each shelf bay is numbered, assigned to one member, and given an end date that matches their membership. Nobody shares a bay by accident, and nobody holds a shelf after leaving. When a shelf goes past its date, it lands on a clearing list with the member's contact details already attached, instead of becoming an argument at the counter. Unclaimed finished work follows the same rule: a pickup deadline, a reminder, and a written studio policy for what happens after it. The software enforces the dates; the studio sets them.

Breakage is recorded against the piece, and the member sees it. The record shows which load the piece was in, what stage it reached, and what happened, so the conversation starts from the facts instead of from a search through the shelves. The software does not decide who pays or whether a piece gets remade: that is the studio's policy, written down before the first firing, and the record is what makes the policy enforceable. A piece that was never logged cannot be explained, which is why intake matters even for small work.

Buy a maintained studio product when it handles your piece flow with reasonable setup: class booking, memberships, piece tracking, kiln loads, firing fees, and pickup messages. Maintained products such as KilnSeat and Ceramik cover exactly that, and a studio with standard work should start there. Build custom when your workflow breaks the template: firing rules or fee structures the maintained products cannot express, shelf and kiln capacity your floor plan makes unusual, a member portal your members will actually use, or connections to systems the maintained products do not cover. If your piece flow is standard, buying is the better trade.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how deep the piece flow goes, how many members and staff it serves, what it needs to connect to, whether data needs moving over, whether phones or tablets are involved, and the condition of existing code. The agreed phase is priced in writing before it starts.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a system with several connections to other systems, data to move over, mobile apps, or formal compliance controls takes longer. The schedule is set once the first piece flow and what 'done' looks like are clear.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more: the most expensive version is the product that looks finished, clean screens and clicking buttons, while underneath nothing is tested and the security checks run in the browser, where anyone can tamper with them, instead of on the server where they hold.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the piece flow agreed at the start: a piece is logged, it moves through the loads, the member sees the status, the fee matches the rule, the pickup message goes out. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your studio.

We need one person who owns the piece flow, access to the relevant users and systems, timely answers on studio rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.

It can handle all of them, but the first release should not try to. Classes, memberships, wheel bookings, and the kiln queue share one member record, so a member's plan, their wheel time, their shelf, and their firing tab all stay in one place. The first release picks the path that costs the most today, usually the kiln queue and firing fees, and the rest joins once that path works. A studio that starts with everything at once gets a bigger system and a slower first win.

A drop-off piece gets the same record as a studio piece, with the owner, the clay and cone, the size or weight, the fee, and the pickup date. The difference is only at intake: the piece arrives finished and ready for the shelf instead of being made in the studio. After intake, it follows the same queue, the same loads, and the same pickup message. The studio decides whether it fires outside work at all, and the record is what makes that decision workable instead of a favour tracked on a sticky note.