Print-on-demand operations for Indian custom-print shops.

A custom-print shop in Royapettah runs at around 60 orders a day across T-shirts, mugs, photo frames, posters, and corporate gifting. The founder's morning starts with a stack of artwork files in a Google Drive folder, a WhatsApp group with the previous day's customer approvals, an Excel sheet that tracks production status, and a spiral notebook that lists what is going out for delivery. By the end of a busy day, at least three orders have been started against the wrong artwork file because the file naming was inconsistent, and one customer has called twice asking where their order is.

This is the standard operational state of a print shop somewhere between manual and modern. The orders are coming in, the production floor is working hard, the dispatches are mostly going out. The infrastructure holding it all together is held together by the founder's attention, which is the constraint that prevents the shop from doubling its volume.

Where print operations break

The first breakpoint is order capture. Indian custom-print is artwork-heavy. A T-shirt order is not a SKU. It is a size, a colour, a quantity, an artwork file, sometimes with a customer note ("make the logo a bit smaller, the way you did last time"). The capture has to hold all of this without anything getting lost.

The phone, WhatsApp, email, and walk-in channels each capture orders differently. WhatsApp captures the artwork as an image with the specifications in the chat. Email captures it as an attachment with specifications scattered across the body. The walk-in captures it on a paper slip the founder transcribes later. By the time these three channels reach the production floor, the spec is fragmented and the artwork file is in at least three places.

The print-on-demand storefront we built for Creative Ideas addressed this by moving the capture into a structured online process. The customer authors their own specification. The artwork uploads as part of the order. The production floor sees the complete record without further clarification. This is the foundational move. Without it, every other operational improvement is built on sand.

The approval cycle that eats time

Print-on-demand has an approval step that other ecommerce categories do not. The customer needs to see a preview of their artwork on the product before production starts. The shop sends the proof. The customer asks for changes. The shop revises. The customer approves. Production begins.

In the WhatsApp-based workflow, this loop runs as messages back and forth, with the latest approved version becoming whichever image was attached to whichever message the production team interprets as the final word. The risk of producing against an older revision is constant. Every shop has at least one story of a 200-piece run printed against the version before final corrections.

The fix is a structured proof flow. The shop generates a preview. The customer receives a link. The customer approves or comments. The production system records the approved version as the canonical one, with a timestamp and a customer identifier. Production is blocked on the system until the canonical approval is recorded.

This is a small structural change that removes a category of error that recurs forever in the WhatsApp workflow. The shape of it mirrors the essay on WhatsApp as order pipeline, where the channel is the right place to start the conversation but the wrong place to keep the operational record.

Production scheduling against capacity

A 60-orders-a-day shop has finite capacity across each production line. The DTG printer can handle so many shirts an hour. The mug press can handle so many mugs. The vinyl cutter has its own throughput. A good operational system models capacity per line and schedules orders against it.

Without scheduling, the production floor optimises locally. The operator picks up whichever order is most visible, which is often the one that was shouted about most recently, not the one that is closest to its dispatch deadline. The result is a shop that hits some deadlines brilliantly and misses others entirely.

With scheduling, the system surfaces the right next job. Orders due for dispatch tomorrow that have not started printing yet are visible. Orders that are still waiting for customer approval are visible. The production floor works against a clear queue. The founder stops firefighting.

Dispatch and the last-mile question

The dispatch end of the workflow has its own structural needs. A print shop dispatches through a mix of channels. Local same-day delivery via a hired bike. Inter-city via Bluedart or Delhivery. Walk-in customer collection. Each channel needs its own documentation and tracking.

The system needs to generate the dispatch document, capture the AWB or booking reference for shipped orders, and update the customer through WhatsApp or email when the order moves to dispatch. The customer who is left wondering whether their order has shipped is the customer who calls the shop, which consumes the founder's time.

This is the same operational pattern we built into the AKSD distributor system, where WhatsApp notifications at every status change reduced the inbound "where is my order" call volume materially. The change is small. The cumulative effect on the founder's day is large.

What the shape of the right build looks like

A working operational backbone for an Indian print-on-demand shop at the 20 to 100 orders-per-day scale needs four modules.

Order capture across channels (web storefront, WhatsApp-to-form, walk-in entry) that produces a single structured record.

Artwork management with version control and customer approval workflow.

Production scheduling against per-line capacity, with the queue surfaced to the operators on the floor.

Dispatch with documentation generation and customer notification.

This is a four-to-eight-week build for a shop of this profile. The hosting needs are modest. The technology choices should default to the stack we run for similar businesses. The cost is well below what a year of stitched-together SaaS subscriptions would run, and the system fits the shop's actual workflow rather than asking the shop to fit a generic vendor abstraction.

The internal systems practice is built for this engagement profile. The build sits inside the broader frame of decision infrastructure: the system captures what actually happens in the shop and presents the founder with reliable data they can act on. Production capacity by line, approval cycle time by customer segment, dispatch reliability by channel become questions with answers, instead of folklore.

If your shop is running on artwork in Drive folders and production in spiral notebooks, the cost of the current workflow is bigger than the visible labour. It is the founder's bandwidth. Start a Conversation.