Founder story · 2015–2016 · Belarus · iOS + Android · Exited. A marketplace that built both sides properly and still ran out of demand.
Bloom was a two-sided mobile marketplace connecting people buying bouquets with local flower shops. It ran 2015–2016 on iOS and Android and was sold. The buyer and the amount are covered by NDA.
200 flower shops in 5 cities, signed through cold sales. No aggregator shortcuts, no integration partners — shops were called, pitched, and onboarded one at a time. In marketplace terms, we built the supply side by hand.
And not just a listing. The shop side had its own product: a catalogue builder with a structured flower taxonomy — a bouquet was defined by what it comprised (Rose ×22, Tulip ×14, Daisy ×7) and by colour, not by a photo and a price. Per-day working hours with a day-off switch. Multiple phone numbers. A shipping flag. Request-only pricing for bouquets that could not be priced up front. Order queues split into *waiting for the store's response*, *accepted*, and *completed*, with a customer rating on every finished order.
We even shipped an in-app PhotoGuide — a five-screen tutorial teaching florists how to shoot their own bouquets: find natural light, edit rather than filter, vary the angle, vary the focus, never use zoom. Marketplace content quality was a known problem and it got a product answer.
The demand side got mechanics too. The app asked for calendar access to remind you about your friends' birthdays. The feed opened on coming holidays — the people you knew, with their dates. A delivered bouquet carried a send again action tied to the person you had sent it to before. Occasion trigger, repeat loop, and a ratings feedback cycle were all designed and built.
Both sides were built out. The shop side was a product in its own right, not a listing form.
Shops got a map-located profile, per-day working hours with a day-off state, multiple phone numbers, and their own order queue split into new, current, and completed — with a customer rating on every finished order.
A bouquet was structured data, not a photo with a price: composition by flower and count, colour palette, delivery terms, and payment methods. Pricing could be a number or *request only* where a bouquet could not be priced up front.
The app asked for calendar access to surface friends' birthdays, opened the feed on coming holidays, and let a delivered bouquet be sent again to the same person. All of it worked. All of it only reached people already inside the app.
Total activity was about 4,000 monthly actives across both sides, and 50–70 orders a day at peak.
Put those two numbers together and the problem is arithmetic. Seventy orders a day spread across 200 shops is roughly one order per shop every three days. Across 5 cities, that is 10–14 orders per city per day against about 40 shops in each.
At that density, no shop has a reason to care about the channel. Supply that has been signed but not fed is not an asset — it is a liability that decays. Every one of those 200 relationships was bought with a cold sales call and then left to go cold again.
This is the part worth sitting with. It is not that the demand side was ignored — birthday reminders, an occasions feed, and a repeat-send action were all built. Product mechanics for demand are not the same thing as demand. A reminder only works on people already using the app, and there were about 4,000 of those across both sides. Every loop we built needed an audience to loop through, and buying that audience was a funding question, not a design question.
Then the team came apart. What was left could not carry both sides of a marketplace, and the company was sold rather than scaled.
| Claim | Evidence |
|---|---|
| Supply could be built by hand | 200 shops across 5 cities, onboarded through cold sales |
| Supply tooling was real, not a listing form | Structured bouquet taxonomy, working hours, request-only pricing, shop-side order queue, ratings, in-app photography guide |
| Supply was not the constraint | ~1 order per shop every 3 days at peak volume |
| Demand was the constraint | 50–70 orders/day maximum against 200 signed shops |
| Demand mechanics were built, and were not enough | Calendar-based birthday reminders, an occasions feed, and a repeat-send action all shipped |
| Closing the gap was a funding question | Growth required sustained paid acquisition the team could not fund |
| Team durability decided the ending | The sale followed the team breaking up, not a market verdict |
Test the demand side before building the supply side.
Two hundred shops felt like progress because it was measurable, effortful, and visibly done. It was activity. The number that mattered — orders per shop per week — was never a target, and by the time it was visible it was also unfixable without capital.
A marketplace that can sign supply has proven it can sign supply. Nothing more.
It was sold, which is a better ending than most, but the sale followed the team breaking up rather than the model being proven. The buyer and the amount are under NDA.
Demand. At peak the platform did 50–70 orders a day against 200 signed shops — roughly one order per shop every three days. Supply had been built; the orders to fill it had not.
Cold sales, one shop at a time, across 5 cities. No aggregators or integration partners.
Yes — birthday reminders from your calendar, an occasions feed, and a one-tap repeat send. They worked as designed and did not solve the problem, because every one of them only reaches people already inside the app. Retention mechanics multiply an audience; they do not create one.
That demand exists at a density each supplier can feel. Signed suppliers are not traction — orders per supplier per week is the number that decides whether supply stays.
If you would rather talk it through before sending a brief, book a short routing call and we will point you to the right next step.
