Vaza sells bouquets, plants and curated gifts the way people actually buy them — by the occasion, not the SKU — with live order status in the app and a back office where the client's own team runs catalogue, stock and orders without calling a developer.
Orders, revenue and adoption are the client's numbers to share, and they are not on this page. What is on this page is what was built, and why it was built that way.
Vaza is a flowers-and-gifts store — bouquets, plants and curated gifts, browsed by occasion and bought in-app. Behind it sits an admin panel where the team runs catalogue, stock, orders and fulfilment without calling a developer.
Two things make this harder than a general e-commerce build. The goods are perishable, so a catalogue is only trustworthy if the stock behind it is — a listing that outlives the flowers costs an order and a customer at the same time. And gifts are bought against a date on the calendar, which means the storefront has to be merchandised around occasions rather than product categories. The app ships bilingually for its market.
Flower and gift delivery is one of the most crowded app categories in the market Vaza was entering. Floward is funded and operating across six countries. Joi Gifts, Naseem, Bleems, FNP, Little Flora and Maison des Fleurs are all established with an app presence. Below them sits a long tail of florist apps with zero or near-zero ratings — businesses that shipped something and then watched it sit there.
So the question shaping this build was not how to list flowers. It was what a new entrant needs in order not to become one of those zero-rating apps: a storefront that matches how people actually shop for a gift, a catalogue that stays honest about what is available, and a back office good enough that the people running it choose to use it.
That last one decides the other two. A gift catalogue changes constantly — stock turns over in days, and every holiday is a different shopfront. If the client has to file a ticket to change a price or pull a sold-out bouquet, the storefront drifts out of date faster than anyone can fix it, and the app joins the long tail.
The decisions below all serve the same thing: a gifting app is judged on whether it matches the reason someone opened it, and on whether what it says is in stock actually is.
Nobody shops for a bouquet; they shop for a birthday, a graduation, an apology. Browsing is organised around the occasion that prompted the order, which is also what lets the same catalogue be re-cut as the calendar moves.
Perishable goods make inventory part of the storefront's credibility rather than a back-office detail. Catalogue and stock live in the same panel as the orders drawing them down, so what is listed and what is available are the same answer.
Status changes are pushed over Socket.io while the app is open, with push notifications and transactional email carrying the same events when it isn't — so a customer never has to reopen the app to find out where an order stands.
Catalogue, inventory, orders, fulfilment, media and role-based access, designed with its own screens and its own acceptance criteria. If a routine content change needs a developer, the product was built wrong.
iOS and Android ship from a single Flutter codebase, so a new occasion, a pricing change or a content update reaches both platforms in the same release rather than in two schedules.
Browsing is organised by occasion, which is how gifts are actually chosen — and lets the same catalogue be re-merchandised for a new holiday without a release.
Catalogue, stock and orders sit in one back office, so what is listed and what is actually available are never two different answers.
Order status is pushed rather than polled, and the same events reach push and email — so a customer is never left guessing.
The client's team runs catalogue, pricing, stock and content themselves; routine change does not queue behind a developer.
The admin panel was designed as a product with its own acceptance criteria, which is what makes it something the operations team uses rather than tolerates.
One Flutter codebase means a pricing rule, a new occasion or a content change reaches iOS and Android in the same release.
Both languages come out of one layout system rather than two designs, so a second market costs a mirror instead of a rebuild.
Running a store your team can't update without a developer?
One is what the customer judges the brand by; the other is what decides whether the catalogue tells the truth. They run on the same backend.
Every tool below is in the build — no résumé-ware.
Mobile apps start from $6k and multi-role platforms from $7k, quoted fixed-price against a written scope after a free scoping call. E-commerce scope varies more than most: a catalogue and checkout is one project, and adding fulfilment tooling, multi-branch stock and a full back-office is another. We scope in phases so you can launch and then extend.
That's the point of the admin panel. Vaza's team manages catalogue, stock, orders and operations themselves — the same principle behind the Piano build, where the client runs a full CMS unaided. If a routine content change needs a developer, the product was built wrong. We treat the admin panel as a real product with its own design and acceptance criteria, not as a spreadsheet with a login.
Inventory stops being a back-office detail and becomes part of the storefront's credibility. A listing that outlives the product costs you the order and the customer at once, so stock, catalogue and orders have to live in the same place and move together. Seasonality pushes the same way: if every holiday is a different shopfront, re-merchandising has to be something the client does in an afternoon, not something that waits for a release.
Regularly — we've shipped products into the US, the Gulf, North Africa and Latin America. Selling into another market is more than translation: layout direction, local payment methods, address conventions and the calendar of occasions people actually buy for all change, and each one is a place a product can quietly feel foreign. We build the second market into the layout system from the start rather than retrofitting it, so both ship at the same quality.
Yes, including the parts that cause most rejections: account deletion in-app, privacy and data-safety declarations, and correctly configured store listings in every language the app ships in. We treat store submission as a build task with its own acceptance criteria, not as paperwork at the end.
We've already built the catalogue, the stock control and the back office behind one.
See exactly how we'd scope yours.
