StudioTrack: A Concept for Helping Artists Manage Custom Orders

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

StudioTrack is a proposed order workspace for artists who sell custom work through Instagram. The idea came from my friend Suhani, a college student who makes and sells paintings. Taking an order is only the beginning of her work: she also has to remember the customer’s requirements, track the painting, balance deadlines with classes, and keep the customer updated.

I imagine StudioTrack as a quiet assistant behind that process. Suhani could paste a customer conversation or share an order form. The system would turn the request into a draft order card showing the subject, size, medium, references, requested deadline, and anything still unclear. It would show where each detail came from, so she could correct a misread message before accepting the commission.

Once an order is accepted, Suhani would move it through stages such as sketching, painting, finishing, and delivery. When she records progress, the AI would prepare a short customer update in her preferred tone. She would edit or approve it before sending. A private tracking page could show customers the progress she has chosen to share.

The control panel would also give her a brief view of what needs attention: orders approaching a date she set, drafts awaiting approval, and work she has marked as waiting for a customer. During an exam week, she could record reduced availability and see possible clashes without having AI change a promise she made.

This is aimed at solo artists and other makers who take custom orders through messages. The business hypothesis is that fewer lost details and less repetitive admin work would make a modest subscription worthwhile. I have not tested what Suhani—or anyone else—would pay.

Status: Concept only. StudioTrack was not built or tested during the Week 2 challenge window.

Demo

There is no working demo yet. The first demo I would want to build is one complete journey: an incoming commission request becomes a reviewable order card; Suhani corrects it, sets the price and date, records a painting milestone, approves an update, and sees exactly what the customer can view.

That journey matters more to me than a chatbot answering questions about the studio. It would show whether the tool actually reduces work while keeping Suhani in control.

Code

There is no project repository yet. StudioTrack is a product specification and proposed workflow, not an implemented application.

How I Built It

I have not implemented the system or tested a model. My proposed stack is a small Django application for the order board, customer pages, login, and stored order history, with an open-weight model running through a local inference service.

The model’s first job would be to read messy requests and return structured suggestions. Each suggested detail would carry the relevant words from the original request. Its second job would be to draft short updates using only order details and progress Suhani has confirmed. Application code—not the model—would control order stages, access to private information, approval records, prices, and promised dates.

I would start with pasted text because it matches how orders arrive without requiring access to Instagram’s messaging API. Reading screenshots, connecting DMs, and sending messages automatically would come later if the basic workflow proves useful and those integrations are permitted and reliable.

Why Does Open Innovation Matter?

A small art business cannot assume steady order volume or a large software budget. An open-weight model could make it possible to process requests locally and draft updates without paying an AI provider for every message. Keeping inference under the maker’s control could also give her more choice over where customer conversations and reference images go.

Openness would let the project test and replace models as well. Suhani’s messages may include shorthand, mixed languages, and details scattered across several replies. The right model is the one that handles her work accurately enough—not simply the one with the most impressive general benchmark.

Those benefits are still hypotheses. A real build would need to measure extraction errors, drafting edits, response time, running costs, and where data actually travels. I would report the mistakes alongside the successes.

I missed this challenge’s build window, but the concept remains worth pursuing. The next meaningful milestone is a working version Suhani can use on a real order—and her honest answer about whether it helped.