Case study8 min readUpdated 6 Aug 2026

A print shop goes digital, part 1: from scattered info to a first website

A print shop needs end-to-end digital operations, but begins with the public information, file-enquiry and ownership foundation that every later phase will depend on.

This series follows one print shop through several phases of going digital. The journey is built from real implementation experience in this industry — the stages and challenges should feel familiar if you run this kind of business. Each part covers what was built, what was deliberately not built, and what evidence justified moving to the next phase.

Where the shop started

The shop prints business cards, boxes, stickers and banners for local businesses. Work was steady, but every enquiry followed the same exhausting script:

  • Prices were quoted one chat at a time, because the price list lived in the owner’s head and in hundreds of old LINE conversations.
  • Photos of past work sat in a phone gallery; showing a customer relevant examples meant scrolling and forwarding.
  • Artwork requirements (“What file format? What resolution? Where’s the bleed?”) were re-explained for nearly every order — and when the explanation was skipped, files arrived unusable and the job stalled.
  • New customers who heard about the shop had nowhere to look it up. Its Google presence was a map pin with three photos.

The first visible bottleneck was an information problem: the answers existed, but they lived in scattered, unsearchable places. The wider production and delivery needs were also real; they simply could not be encoded safely while the public information and incoming data were still undefined.

One thing worth being honest about from the start: the owner already knew the long-term picture. A shop like this genuinely needs order records, production statuses and delivery tracking — that need existed on day one, not at some future stage. The question the whole series answers is not “when does the need appear?” but “given the full need already exists, why build in this order?”

What phase one actually was

The first website had exactly four jobs:

  1. The company page — who the shop is, where it is, how long it has operated, photos of the workshop and machines. This is what a first-time visitor checks to decide the shop is real.
  2. The services pages — one page per product family (cards, boxes, stickers, banners) with photos of real past work, available materials and sizes, and honest guidance about typical order quantities and lead times.
  3. An enquiry form with file upload — name, contact, product type, quantity, deadline, artwork attachment and a free-text field. Submeto applies the configured required fields and file limits, then delivers the submission to the shop’s email. Staff still quote and reply through LINE or phone, exactly as before.
  4. A file-preparation page — the artwork requirements, written once, properly: formats, resolution, bleed, color mode, with downloadable templates for the common sizes. This single page replaced the most-repeated conversation in the shop’s history.

Every page ends the same way: a LINE button and a phone number. The website’s job is to prepare the conversation, not to replace it.

What phase one deliberately was not

This is the part most first projects get wrong, so it deserves its own list. Phase one had:

  • No online ordering. The file upload collected a quotation input; it did not promise an accepted order. File quality, color expectations, quantity breaks and price still required human confirmation.
  • No online payment. Payment kept working the way customers already trusted: bank transfer after a human confirmed the quote.
  • No customer accounts, no order tracking, no admin backend — yet. Not because the need wasn’t real, but because nobody could yet say what such a system should manage: which statuses matter, who owns each step, which exceptions break the flow. Building it before that shared understanding exists means encoding guesses.
  • No price calculator. Print pricing depends on material, size, quantity and finishing in ways that change with supplier costs. A wrong automatic price is worse than no price.

“Not yet” is not a downgraded goal, and it is not a claim that these needs don’t exist. It is what kept the project small enough to finish, gave staff a change they could absorb, and left the next decisions to be made with real data instead of guesses.

What moving to phase two would require

The shop already had a longer roadmap. Before authorizing the next build, it agreed to watch both operating evidence and staff readiness:

  • Manual copying producing meaningful delay or errors, regardless of whether the raw enquiry count looked high;
  • Repeated cases of uploaded files and job details becoming mismatched after delivery to the existing channels;
  • The same status question (“is my job done yet?”) arriving often enough to be worth a system.
  • More than one employee needing the same record, and agreement on who would keep that record accurate.

Part 2 looks at why the shop still did not build the full order system next — and what it reused while preparing the next operating slice.


The boundary matters: the Submeto enquiry form and file delivery above can be part of the agreed website scope. Customer accounts, order state, payment, production and logistics in later parts are separate system projects with their own scope — they are not included merely because the process starts on the website.