From Chaos to Control: How I Built an Order Workflow That Adapts to Each Product

Since she started the business, Ayala managed orders for her boutique bakery over WhatsApp. As the only person in the business, she handles the full process — from talking with customers, through baking and decorating, to delivery coordination and receipts. Each order usually starts with a general request like "I want a birthday cake," then grows into a chat that can stretch across hours or days. Along the way, details are collected and sometimes change: cake type, size, flavors, colors, fillings, text on the cake, date, and delivery.

By the end of the process, there was no clean order she could work from. The different versions stayed inside the chat, and WhatsApp became the real source of truth she used while preparing. Once she decided she finally wanted to change that, that was the moment I stepped in to help solve the challenge.

To see where the real friction was, I watched Ayala through her full workflow — from the first customer message to baking, payment, and handoff. I saw her go back to WhatsApp again and again to check an important detail about the cake she was making. I also saw how a small mid-chat change could reshape the whole order — whether a message after details were already agreed, or something the customer forgot to mention.

Watching Ayala work led to one clear insight: at no point does the chat become a clean business record she can keep working from. From that, I defined the product challenge: turn an unstructured conversation into a reliable workflow that follows the order through the full process.

How the order process worked in practice

Mapping Ayala's existing workflow for a new order showed five steps that repeat in almost every order:

1. Intake — a customer sends a WhatsApp message, often while Ayala is already working on other orders.
2. Clarifying order details — a back-and-forth where flavors, colors, fillings, text, date, and more are collected and changed.
3. Rebuilding the order during prep — Ayala goes back to the chat, scrolls through messages, and pulls out the latest spec.
4. Pickup or delivery coordination — delivery details and customer updates stay in the same thread.
5. Issuing a receipt — after payment, order and customer details are entered again into an external invoicing system. Here too, Ayala gathers the details by hand from the chat.

The same information moves across several steps, but each time Ayala has to find, interpret, or enter it again.

The mapping helped me spot the main problems below:

No single source of truth for the order

Order details are scattered across messages, photos, and changes made during the chat. A customer might first pick pink frosting, later switch to blue, change a filling, or add text the next day. To know what was actually ordered and which cake the customer wants, Ayala had to go back to the chat and cross-check versions. The more the order changed, the higher the chance of baking from a detail that was no longer current.

Mistakes become part of the process

Relying on memory and manually decoding the chat led to mistakes almost every week: wrong flavor, a missed color, a forgotten filling, outdated text, or a date change that never carried forward. Each mistake could mean remaking the cake, wasting ingredients, or hurting the customer experience.

Every order is handled on its own

Even when several orders share the same flavors, colors, or fillings, there is no way to see that overlap ahead of time. So four chocolate cakes, for example, become four separate rounds of prep and cleanup.

The same information is entered again in other systems

After payment, Ayala opens an external invoicing system and re-enters details already collected earlier: customer name, product, price, and date. The same information moves between systems by hand, which adds time and creates another failure point.

The same view serves different needs

During prep, Ayala needs the key prep details — flavor, color, filling, and text. Prices and payment details are not useful in that moment. So even when the information is right in front of her in the chat, it is shown in a way that does not fit the actual work stage.

Principles for the solution

From the observation and the problems I found, I also defined four principles that guided the system design in the next stages:

Flexibility under the user's control

Different products need different information. A simple cake might need one flavor and one text line, while a more complex product includes several flavors, colors, fillings, and add-ons. The system had to let Ayala change products and the information collected for them herself, without needing a code change every time the catalog changed.

Reuse existing definitions

Flavors, colors, fillings, and other options repeat across products and price levels. Instead of defining the same information again and again, the system should manage it once and allow reuse in every product where it is relevant.

Information keeps working after the order

Once orders are saved in a structured way, that data can also support work planning. For example, if several orders include chocolate or cream in the same color, the system should be able to group them and show Ayala what she can prep together — saving time.

The view follows the task

The customer and Ayala work with the same order, but need different information. The customer needs a clear summary of what was ordered. Ayala needs to quickly see the details that affect the work itself (colors, flavors, and more). So the same source of truth must serve both cases, and adapt the UI to who is using it.

We all know the market has many order-management systems with a wide range of features. But for Ayala and the nature of her business, she needed a system whose structure adapts to the product itself.

That need came mainly from the fact that every cake has different attributes. One product might include flavor and color; another might include three flavors, a filling, and text. A fixed order form would create unused fields, limits, and double maintenance whenever the catalog changed.

So the principle I set was simple: the product builds its own order form. Ayala defines what information each product needs, how many choices are allowed, and which options are available. The system uses those definitions to build the order flow dynamically. A cake with two flavors shows two flavor choices. A product that allows three shows three, and so on. If a product does not need color or filling, those fields do not appear at all.

Behind every product sits the same flexible mechanism, so Ayala can add products and change the catalog without rebuilding a form for each one.

Each product defines the information it needs

Instead of one form with fixed fields, each product is made of the fields and options that matter for it. For every product, Ayala can define a flavor, color, filling, or text field; choose whether the order form allows free text or a list selection; and set how many choices are required for each parameter.

So if a cake includes two flavors, the order form shows two choices the person filling it must complete. If another product allows three flavors, the same mechanism adapts without creating a separate form.

For Ayala, as owner of the business and the system, that means she can change product structure from inside the system — even when the catalog and parameters change.

Repeating options are managed in one place

As I noted earlier, a large share of product information repeats across products. The same flavors can appear on a bento cake and a birthday cake, and the same colors or fillings can be used across several product categories.

For form fields that use a list — flavors, for example — instead of maintaining that list on every product separately, I defined shared lists. Ayala manages flavors, colors, or fillings in one place, and any product that needs a list field can link to one of those lists.

If a new flavor is added to the list, for example, she only needs to add it once, and it updates across all products that use that list field.

Price levels built on top of each other

For Ayala, the same product can be sold at several price levels, and each level changes both what the customer gets and what information the order form needs to collect. A basic level might include two flavors, while a higher level keeps those choices, allows one more flavor, and adds a color choice.

So there was no sense in redefining the whole product at every price level. Each level is built on the previous one and only defines what changes. That way Ayala can update a shared definition once while still keeping the differences between price levels.

Personalized information that appears only when it matters

Some order details depend on another customer choice. An address is needed, for example, only if the customer chooses delivery instead of pickup. Some questions are relevant only for a specific add-on or option inside the product.

So the system shows extra fields based on choices made during the order. If the customer chooses delivery, an address field appears. If they choose pickup, there is no reason to show it. The form stays focused, and the person filling it only sees what is relevant to their choice at each step.

Shared definitions across products

During the design work I also saw that whole groups of form fields can repeat across products — for example allergens, packaging upgrades, or general add-ons.

Here too, the goal was to avoid double maintenance. Ayala can define such a group once in the system, including its options and prices, and assign it to the right products. Any product that includes that category then gets those fixed fields, which makes management easier across all product levels.

Not just an order form: extra capabilities the system gained

The solution structure above lets Ayala grow and change the catalog without turning every business change into a development task. Once the information is stored consistently, it can also be used beyond the order form itself. At this stage I focused on three places where Ayala still did manual work: prep planning, kitchen work, and issuing the receipt after the order.

Saving time and costs

While observing Ayala's workflow, I saw that every order was handled as a separate unit — even when several orders needed the exact same components. If there are four chocolate cakes in the coming days, there is no reason to prep the same base four times. The same is true for creams, colors, and fillings.

That led to the shared-prep idea: the dashboard includes a tab that gathers upcoming orders and groups shared attributes. Ayala can pick a date range and see, for example, that she needs four chocolate bases, three pink creams, and two dulce de leche fillings.

Instead of opening every order and trying to spot the overlap herself, she gets one clear view that helps her decide what is worth prepping together.

A view tailored to the viewer

Once the information lived in one place, I noticed another problem: a full order summary still does not fit the moment of baking. In the kitchen, Ayala needs to spot in a few seconds the details that affect prep: flavors, colors, fillings, text, and special instructions. Price, payment method, and admin details only add noise at that moment.
So I chose a full split between the customer-facing order view and Ayala's work view.

For Ayala I chose a "kitchen note" style that shows only prep details, with clear hierarchy and a layout made for a quick look while working. The customer still gets an order summary with all the details that matter to them, in a view that fits them.

Enter information only once

Another place where Ayala had to re-enter order information was after payment. She had to open the invoicing system, enter customer, product, and amount again, issue the receipt, and send it to the customer.
To cut that double data entry, I connected the system to the digital invoicing provider's API, so data already on the order continues straight into that step.

With that solution, when Ayala marks an order as paid, the system uses the customer and transaction details to issue the receipt. After it is issued, the receipt is available to the customer from the order details area they open via a direct link.

The system I designed and built for Ayala has been in regular use for nearly a year. In that time, there has been a clear change in how she manages orders and the work around them.

Fewer order mistakes

Before the move to the system, mistakes like a wrong color, a missed flavor, or outdated text happened almost every week. Since orders follow a structured flow and are saved as one clean record, those mistakes have not been reported. Instead of going back to the chat to figure out the customer's latest request for color or flavor, Ayala works from the information they approved and saved on the order.

Less duplicate work

The shared-prep tool also changed how the workday is planned. Instead of starting each cake on its own, Ayala can see ahead which components repeat across orders and batch part of the work. In a typical week of 10–15 orders, this approach is estimated to save about 10 hours that used to be spent on repeating processes — including separate prep rounds, separate tool cleanup, and more.

Seeing what upcoming orders need also helps plan prep and purchasing better. According to Ayala, there is now less leftover product, less waste, and fewer cases where work stops because an ingredient is missing and a last-minute purchase is needed.

Less admin work

Issuing receipts used to be a manual process of a few minutes per order: open another system, enter the data, and send the document to the customer. Today the information moves directly from the order into receipt creation. At a volume of about 40–60 orders a month, the process saves several hours a month and also reduces data-entry mistakes on receipts.

More control over the process

The most meaningful change Ayala mentions is the sense of control and order. In her words:

A process that used to feel exhausting and stressful became ordered and calming. Instead of worrying I will forget an order or an important detail inside the chats, I know the information is in one place, what the current version of each order is, and which orders are coming later in the week. I can simply open the system, see the upcoming orders, and know everything is documented and organized.

What I learned from the process

I led the project end to end: from the first observation and workflow mapping, through defining the problem, requirements, and product principles, to UX/UI design, information structure, and finally full end-to-end development.

One of the bigger challenges was designing a system that supports highly dynamic products — with field types, price levels, options, and categories that change from product to product. I learned how important flexibility is here, and also that this complexity must stay behind the interface. For Ayala, the actions need to stay simple: define a product, choose what information is required, and manage orders without thinking about the structure that makes it possible behind the scenes.

The project also showed me that a small business and a system with only one user can still need deep product and systems thinking. Product flexibility, permissions, data integrity, edge cases, and the ability to keep evolving the system over time all need upfront planning — even when the product itself should feel very simple to the user.

In the end, a process that relied on WhatsApp messages, memory, and manual handoffs of information now runs from a single source of truth that follows the order from collecting details through prep, payment, and the receipt.