The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
One scent stays a single product record and each bottle size is a separate sellable unit, priced and stocked on its own, so a new size is not a new product. Fragrance family and notes run alongside the category tree, for shoppers who arrive without a brand name in mind.
Visit the site →Kokudankokuya sells perfume, and a perfume catalogue does not fit the standard ecommerce product shape. One scent sells in several bottle sizes. A shopper decides without smelling anything, and a good share of the basket is bought as a gift rather than for the buyer.
That set the problem: split the sizes into separate products and the catalogue fills with repeats; merge them into one and per-size stock and pricing disappear. We drew the variant line at bottle size, the one place that keeps per-size stock and pricing without filling the catalogue with repeats.
We go through how the work runs today and what you expect from the software; the scope comes out of that.
We decide what the system is made of and where its information is kept.
We draw the screens and the flow before any code, and start building once you have approved them.
We write and hand over the software so another team could carry it on.
One scent is a single product record; each bottle size is a separate sellable unit carrying its own price and its own stock.
Family and notes sit next to the category tree, so a shopper can start from how a scent behaves rather than from who made it.
A perfume attaches to more than one note, so the same product surfaces from different search intents instead of sitting in a single branch.
The catalogue's scale did not call for a separate search or cache layer, so the store runs on Laravel and MySQL alone.
| Challenge | Result |
|---|---|
| The same scent sells in several bottle sizes, and listing each size as its own product fills the catalogue with repeats | The scent stays one record, and adding a bottle size does not mean opening a new product |
| Folding the sizes into one product loses stock and price tracking per size | Price and stock are tracked per size, so it is clear how many of which bottle are left |
| Shoppers often arrive with no brand name in mind; what they are after is the character of a scent | A shopper can browse by fragrance family instead of by brand |
| Nobody can smell anything before buying, so the words describing a scent have to carry the choice | One perfume linked to several notes turns up in different searches |
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Tell us how the work runs today and we will look at which step could move into software.
