Jenday

I attended PRINTING United Expo in Las Vegas in September 2026 to understand the decorated-products industry beyond software screens.

Decorated products are goods that businesses print, embroider, or press logos and artwork onto, such as team hoodies. Walking the floor, I saw production equipment, decoration technologies, and the surrounding vendor ecosystem, and I came away with a clearer sense of how many separate systems and physical processes contribute to a single customer order. These were field observations at a trade show. They were not interviews with facility operators, user tests, or customer validation.

The visit reinforced a direction for Jenday: the opportunity was not simply to design another order-management application. It was to connect the decisions, information, and responsibilities that carry an order from customer request through production and delivery.

Two points in my notes shaped the model directly. An order is not the same thing as a job: one order produces many jobs, shipments, and sometimes rework. And no single fixed sequence of steps fits every facility. Both informed how Jenday represents an order and its work.

Decorated apparel looks simple from the outside.

A customer wants 250 hoodies with a logo. Inside the facility, that sentence becomes artwork that has to fit a machine, garments that have to arrive, jobs that have to run in order, and shipments that split across locations.

I studied how existing shop-management and production software handles that work, reading public documentation and product material for a dozen or more systems. I treated each as evidence, never as a template, and labeled every finding by how I knew it: documented, observed, reported, or my own inference.

From that reading I formed three hypotheses about where the work breaks down. I treat them as starting points to test, not conclusions.

• Hypothesis 1: The same fact gets typed more than once.

  In the documentation I reviewed, addresses, purchase order numbers, and part details moved between tools by hand.

• Hypothesis 2: One status carries too many meanings.

  A single field appeared to decide what an order is, who is notified, and whether something has gone wrong.

• Hypothesis 3: Splits and shortages live outside the order.

  When a shipment is divided or a delivery comes up short, the documentation I found did not show the order knowing about it.

These come from documentation and trade-show observation. These questions became a focus of my conversations with facility owners and operators.

The central design decision was to stop treating an order as a record and start treating it as a promise.

By operating model I mean how a business's work, decisions, and information fit together. In Jenday, an order is a manufacturing commitment: one authoritative statement of what the facility has agreed to make, for whom, by when, and at what cost. Every department works from that same commitment. Each fact has one owning record, and other screens refer to it rather than keeping a separate version, though an order does keep a snapshot of its committed configuration so a later product change cannot rewrite a promise already made.

A commitment needs more than one kind of permission, and I kept them apart. A customer approving the artwork is not the facility releasing the order to production. Spending money with a supplier is a third decision. Each has its own holder and its own record.

Status gets the same treatment. Instead of one status that means everything, a commitment shows where it is in its life, whether it is ready, how far along it is, what risk it carries, and whether an exception is open, as separate things.

A promise only holds if every department can see what it depends on.

I designed one chain, from the first request through design, materials, production, and fulfillment, and at every handoff I asked what the next person needs to know and where it comes from. The production job in the prototype shows the result. Its artwork, its materials, its order, and the machine it runs on are one click away, and all point to the same record.

The chain continues past production. Fulfillment does not receive a quantity. It receives traceable units. When 232 of the 250 hoodies are packed for three locations and 18 are waiting on a final batch, both facts are on the screen, and the commitment stays coherent across the departments that touch it.

The test of a connected system is what happens when something goes wrong. A hold on an order has to reach every department that would otherwise keep working, and it has to say who may release it. Section 6 describes a case where my first build did not do that.

Design in a factory is a promise about what can actually be made.

In the scenario, the customer's updated sponsor artwork is 11.88 inches wide. The most the facility can produce on that placement is 11.5. The risk I wanted to remove is finding that out when the machine is already running. In Jenday it surfaces during design, as a constraint with the measurement, the rule it comes from, and two ways forward: fit the artwork to the maximum, or send it back.

Two decisions shaped this. First, production limits come from what the facility has recorded about its own equipment, not from a generic template. Second, when Jenday does not know something, it says so. The pre-production check, labeled “Preflight” on screen, lists what it checked. A check it could not run, such as the clearance between two placements, reads “Not measured” instead of passing.

The customer then sees the result as a plain change: the full back was resized from 11.88 to 11.5 inches wide, proportionally. Approval and release stay separate.

The artwork editor behind the “Fit it” action is a representative stand-in built for the prototype, not a live connection to any design software.

I wanted the system to feel intelligent without pretending to decide.

I designed Jenday to prepare work and stop at the point of judgment. In the prototype it detects a problem, calculates options and their consequences, drafts the next step, and flags what it did. By design it does not approve a design, release an order, commit a promise, or contact a customer. Those decisions belong to named people.

The authority map shows who. In the prototype's fictional facility, 22 decision rights each have a named holder. A role suggests an authority, but access never grants it. Two decisions, design approval and commercial acceptance, belong to the customer.

These are designed and demonstrated boundaries in a prototype, not a guarantee about every path through it. My own testing found places where the prototype fell short of them, and I corrected them. Section 6 describes one.

The intelligence is simulated: rules and a scripted scenario, built to show how a person and a system could share the work. No AI model is connected, no agent is running, and nothing learns. What is real is the design.

Turning the operating model into a working prototype required more than designing individual screens. I needed to understand how decisions in one part of the business would affect everything downstream.

I worked through realistic manufacturing scenarios, testing how orders, artwork, production, and fulfillment behaved as connected processes. That exposed inconsistencies that weren't obvious when looking at each workflow independently.

For example, an early version allowed fulfillment activity to continue even though an order was on hold. I identified the conflict and directed changes so the hold was respected throughout the process.

I continued reviewing and refining the experience until the workflows behaved consistently across the scenarios I had defined.

The result is a comprehensive prototype that demonstrates how Jenday could support the day-to-day operations of a custom manufacturing business.

With the prototype complete, my focus has shifted toward working directly with manufacturing facilities.

Interviews with facility owners and operators are well underway. These conversations are helping me better understand their day-to-day challenges, compare the proposed workflows against real operations, and identify where Jenday could deliver the most value.

This next phase is about turning a thoroughly explored product vision into something shaped by the people who would actually use it.