ArtisFlow did not begin as a SaaS idea. It began with a much smaller question:
Could we consolidate all these orders and calculate the totals in a spreadsheet?
The business was a French artisan bakery serving hotels, restaurants, retailers and other professional buyers. Orders arrived through phone calls, WhatsApp and email—often to different people. Someone then had to retrieve, interpret and forward that information before production began.
Orders could be missed. Changes were hard to track. Production frequently began before anyone had a reliable picture of confirmed demand. The apparent problem was calculation. The real problem was creating one reliable source of truth between customers, production and delivery.
- 60–70 B2B customers
- 1,000+ orders per month
- Live since October 2025
- Built end to end by one product builder
A business where everyone works on a different clock
This was not a conventional B2B ordering problem. Bakery production starts around midnight. The first delivery runs leave from about 5 a.m. Hotels and the market need an early batch; restaurants are generally supplied later, before lunch service. Yet restaurants may only send the next day’s order after evening service, around 10 or 11 p.m. Hotels may only finalise breakfast needs after they understand next-day occupancy.
The question for production is therefore not simply, “How many baguettes were ordered?” It is:
How many units of each product must be ready for each delivery window—and which quantities belong to which customer?
With roughly a hundred product references and 60–70 professional customers, manually reconstructing that picture from messages was not sustainable.
Why Excel was not enough
A spreadsheet can calculate quantities. It cannot make an unstructured, multi-person workflow reliable. It does not establish who owns the original order, whether a message has already been entered, whether it is new or a modification, which version is current, or how weekly orders, holidays and exceptions should be handled.
Improving internal re-entry would still leave someone re-entering customer information. The first product decision was therefore simple:
Do not improve order re-entry. Remove it.
Customers should own their original structured order. The same structured data can then support every downstream operation.
Start small: one PWA, one workflow
I began building in July 2025. The first version was deliberately small: a PWA where B2B customers could place their own orders. Products, quantities and delivery dates entered the system once.
The pilot went live in October 2025 and has operated continuously while the product has kept evolving. Today, the workflow handles more than 1,000 B2B orders per month.
The first release did not attempt to solve every operational problem. It established a dependable foundation: one order, owned at source, available throughout the workflow.
Production use designed the next product
The most important product work began after launch.
Repeated orders should not require repeated work
Many B2B customers order similar products repeatedly. Frequent products reduce unnecessary searching. For predictable demand, I added recurring orders that can be configured independently by day of the week.
An automatic order is created at 08:00 on the day before delivery. Until midnight, the customer can modify or cancel it. The goal is not to remove control, but to remove repetitive work while preserving it.
A forgotten order needs a safety net, not a prediction model
Real operation revealed another failure mode: some customers do not want a standing daily order, but occasionally forget to order at all. For a restaurant, discovering the next morning that no bread is coming is a real operational failure.
I reused the same deterministic infrastructure to add a backup order. It is not an AI prediction. It is created only at midnight, and only when no order already exists for the required delivery date.
Not every automation problem needs AI. The simplest reliable mechanism is often the right product decision.
Production use turned a small ordering PWA into a broader operational workflow.
One order, multiple operational realities
Once the original order is structured, each role needs to see it differently. The customer thinks in terms of a basket. Production needs aggregated demand by product and delivery window. Packing needs customer- and route-specific handoff information. Delivery needs an ordered route, operational status and documents.
ArtisFlow transforms the same source data into distinct role-specific representations:
- Preparation turns confirmed orders into production totals, split by delivery run or window.
- Packing turns those totals back into customer- and route-specific handoff work.
- Delivery provides the operational route, status and relevant documents.
No one should have to reconstruct an order simply because it has moved from customer intake to production or logistics.
Preparation consolidates customer orders into production requirements split by delivery window.
Packing reshapes the same orders for the physical handoff to each customer and route. Customer information has been anonymised.
A clear cutoff—with a controlled escape route
Until midnight, customers can create, update or delete their own orders. At midnight, the order enters the preparation workflow and customer editing stops.
That boundary protects production planning, but it does not deny reality. If a customer calls with an exception after cutoff, authorised staff can still make a controlled manual adjustment.
Automate the normal path, but preserve a controlled escape route for the real world.
The bakery still prepares a safety margin. The difference is that the margin sits on top of known, consolidated demand instead of replacing missing information scattered across messages.
A feature that did not prove its value: reviews
I shipped a reviews feature, but adoption has been weak. The reason is not yet proven. It may be a discoverability problem, or reviews may simply not be a strong need in this B2B relationship. A future experiment could test a post-delivery notification at a more relevant moment.
The lesson is straightforward: shipped does not mean adopted. Product work continues after release: observe behaviour, avoid inventing explanations and test the next hypothesis.
AI is an experiment, not the foundation
ArtisFlow includes a conversational ordering and operations-assistant capability as a controlled pilot. For core ordering, the structured interface is currently more effective for the established workflow.
The assistant can help turn a request into a structured draft, but a human confirmation is required before an action is performed. It is not presented as autonomous order execution.
Adding AI does not automatically improve a workflow that already works. The right question is whether an AI interaction is genuinely better for a specific job—and that still has to be demonstrated.
Evolving a live system into a multi-tenant product
ArtisFlow is now moving from a proven single-business workflow towards a multi-tenant SaaS architecture. This is not a big-bang rewrite. Migration is staged by endpoint and capability, with shadow comparison, explicit cutover decisions and a fallback path. The live operating workflow remains the reference while each new capability proves itself.
The target is a platform that can serve multiple businesses without treating the original tenant as the default. The migration is ongoing; ArtisFlow is not presented as a fully launched multi-tenant platform today.
A staged, reversible migration from a proven operating workflow to a multi-tenant platform.
My role
I built ArtisFlow as the sole product builder. My scope has included discovery, workflow analysis, product strategy, UX decisions, architecture, implementation, deployment, production support and continuous iteration.
I use AI-assisted development and research throughout the work, but product decisions remain grounded in observed operational reality.
Six lessons from live operations
- Start with the operational problem, not the technology. The original request sounded like a spreadsheet problem. It was really an ownership, timing and workflow problem.
- Use the simplest reliable mechanism. A deterministic backup order was more appropriate than an AI prediction model.
- Treat real use as discovery. Frequent products, recurring orders, exceptions, notifications and backup orders were shaped by production use.
- Design for the exception, not just the happy path. A precise cutoff matters; so does a controlled way for authorised staff to handle reality after it.
- Do not mistake a deployed feature for a validated one. Reviews and AI both need evidence of genuine value.
- Migrate live systems in reversible stages. Operational continuity is a product requirement, not just an engineering concern.
Explore ArtisFlow and the bakery whose operations shaped the first workflow, L’Ami du Pain.