We built a system for a Moldovan flower shop that brings orders, stock and reports into one place

The business problem

The shop deals with stock that spoils fast and with orders coming from several channels: phone, walk-ins, scheduled deliveries. Without a shared system, whoever takes an order can't be sure what flowers are left, and the owner only learns at month's end how much was lost to wilted or damaged stock.

It mattered because a florist's margin leaks through small things: a bouquet sold below its real cost, a batch of roses thrown away, an order forgotten for tomorrow.

Find, together with the shop's team, a solution that keeps orders, stock and costs in one place, so sellers can work fast and the owner can see where the business earns and where it loses.

• Protected financial dataSellers work with stock but never see purchase prices, margins or profit; the rules are enforced in the database, not only in the interface
• Correct stock with many people at onceTwo sellers can sell the same flower in the same minute; stock can never go below zero, and a cancelled order returns its items exactly once
• UsersNon-technical sellers who work standing up, on their phones
• Real costThe same rose costs differently from one delivery to the next, so cost is recomputed on every delivery to keep reported profit real
• LanguagesThe interface works in Romanian and English

The solution

We did not start with screens. We started with the shop's working day and set, together with the client, who does what: the seller takes orders and serves walk-in customers; the admin receives supplier deliveries, sets prices and watches the numbers. We then traced a flower's path, from supplier delivery, through an order or a walk-in sale, to a delivered bouquet or a write-off, and wrote a design document for each stage before any code.

We built in stages, following that same day: in the morning the admin sees today's orders and low stock, sellers move orders from "Confirmed" to "In progress" and "Ready", new stock is received with the supplier recorded, damaged flowers are written off with a reason, and in the evening reports show revenue, profit and losses for the period. Every important action stays in a log of who did what and when.

Screens with demo data

What we found midway through

Creating an order touches several tables at once: the order, its items, reserved stock and the activity log. We moved creation into a single atomic database function, so an order is never left half-saved.

Online payments needed webhook confirmation, protection against double payment for the same order and a reconciliation screen against the provider’s records.

Along the way we added walk-in sales, a loss report by reason and a per-user activity log. A bottom navigation bar was added for sellers working from the shop floor on a phone.

What the client gained

The shop now works from one place: a phone order reserves the flowers right away, a walk-in sale lowers stock, and each delivery updates the cost. Every day the owner sees revenue, which products make a profit, what is running low and why stock gets lost, without adding up numbers from notebooks.

Sellers can no longer sell what isn't there, and every change has an author in the log.

What it looks like

Screens with demo data

From the blog