Flower shop platform · v2
×2 · one codebase
A second shop on the same engine under a different brand. Proof that one product can power a line, not just a one-off.
Why it
was needed
V2 was a maturity test: if the first storefront was a successful launch, the second had to prove the product was not a one-off workaround.
V1 already had storefront, admin, roles, and Telegram operations. The hard part was changing the face of the shop without splitting the codebase into forks.
IRIS BLOOMS got a different tone and a more premium first screen while staying on the same catalog, order, and operations logic.
How the engine became
repeatable
I separated the brand layer from business logic: visuals, text, product selections, and communication change, while cart, orders, roles, and statuses stay shared.
- I One codebaseDifferent storefronts run on one product: less support, fewer divergences, faster next launch.
- II Brand settingsText, visual slots, product selections, and tone change without rewriting core code.
- III Repeatable adminThe team gets familiar tables, statuses, and roles. The second launch does not require retraining.
- IV Fast launchThe day goes into configuration, visuals, and scenario checks, not rebuilding the store.
- V Room to scaleFuture brands can be added as a product line, not a graveyard of forks.
Live IRIS BLOOMS storefront
Static export captured from the local Laravel storefront: homepage, catalog, product, cart, checkout, contacts, and services use the real templates and assets.
What we could
measure
×2 · one codebase. Here are verifiable outcomes and visual materials from the source projects.
The value of the second launch was not another page. It proved the first product had been built as a system.
Stack,
and why
Similar task? 30 minutes, no brief.
Describe what you need. I will say honestly whether I take it, how much it costs, and whether AI can speed it up.