It Was an Idea on a Call. Now It Has 150,000 Users.
Qamar Abbas had no app, no prototype and no users, just an idea described on a call. We had already rebuilt the systems running his cash & carry business, so he brought us this one too. We built the product, wired in eight cities of outlets and warehouses, and grew it from zero.
- Client
- Qamar Abbas, hardware equipment manufacturer
- Tech Stack
- Flutter (Android and iOS), custom backend and APIs, multi-city outlet and warehouse network, catalogue and admin system, referral and loyalty engine
- Services Delivered
- App Development, Growth & Marketing
Results at a glance
The numbers first. The build underneath.
The challenge
His product reached the people who used it through a chain he could not see. A customer needs work done and asks around for a plumber. The plumber needs parts and drives to whichever retailer probably has them.
- The deeper issue was who actually decides.
- None of this existed as a product yet.
Read the detail
That informality cost him twice. He knew what left his warehouses and almost nothing after that: which retailer moved it, which plumber installed it, what was asked for and not in stock. And eight cities of outlets and warehouses were each run as their own island, so demand in one place could not be answered with stock sitting in another.
The deeper issue was who actually decides. In this trade the plumber specifies the product. The customer rarely has a preference and buys what the plumber puts in front of them, which makes the plumber the real decision-maker in the chain and the one person a manufacturer has no direct relationship with. There was no way to reach them, no reason for them to stay loyal, and nothing to stop a competitor getting there first.
None of this existed as a product yet. There was no app to improve, no user base to migrate, no usage data to build on. So the risk was not only building the thing. It was building the wrong thing and then launching it to nobody.
The outcome
An idea on a call turned into a live product on Android and iOS
- 150,000 users, grown from zero
- Customers, plumbers and retailers connected in one order flow
Read the detail
Outlets and warehouses across eight cities served from a single system
A direct relationship with the plumbers who decide what gets bought
Acquisition built into the product through referral and rewards rather than bought
Launched city by city, each one opened only after the previous one held
The second system we have built for the same client, after his cash & carry ERP
150K
users, grown from zero
8
cities of outlets and warehouses
Our solution
A Flutter app on Android and iOS, one codebase serving three different users, with his outlet and warehouse network wired in behind it. We ran it end to end: specification, design, build, launch and growth.
- One app, three sides.
- Flutter, for a reason.
- The network, connected.
- The plumber, made central.
- Operations behind the app.
- A growth engine, not a launch.
Read the detail
One app, three sides. Customers find verified plumbers and request work. Plumbers receive those requests, order the parts the job needs, and are rewarded for what they install. Retailers order stock from the network. Each side gets its own experience, and all three sit on the same order flow, so a job requested at one end pulls product through the chain at the other.
Flutter, for a reason. Two platforms from one codebase, one team, one release cycle. For a product that had to reach real users quickly and then change just as quickly on what they did with it, shipping Android and iOS together mattered far more than native performance this app was never going to need.
The network, connected. Outlets and warehouses across eight cities were wired into ordering and fulfilment, so an order is served from the stock closest to it rather than from wherever the request happened to land.
The plumber, made central. Verified profiles, job requests, and rewards for what they specify and install. The person who decides what gets bought now has a reason to keep choosing the same manufacturer, and the manufacturer can finally see who they are.
Operations behind the app. Catalogue, pricing, users, verification and order status in one admin layer with per-city visibility, so his team runs the marketplace instead of chasing it over the phone.
A growth engine, not a launch. Nobody downloads an app because it exists. Acquisition was built into the product: plumbers invited plumbers, retailers brought the customers they already served, rewards paid out for activity that actually mattered, and each city opened only once the one before it held.
Before
- An idea described on a call, with nothing built behind it
- Customers, plumbers and retailers matched by phone calls and word of mouth
- Eight cities of outlets and warehouses run as separate islands
- No direct line to the plumbers who specify the product
After
- One Flutter app live on Android and iOS
- Customers, plumbers and retailers in a single order flow
- Orders served from the nearest stock in the network
- 150,000 users, and a direct relationship with the trade
Reach
150,000 users on a product that did not exist.
Distribution
Eight cities of stock answering demand as one network.
Influence
A direct line to the plumbers who decide what gets bought.
How we delivered it
The journey, architecture, and product surfaces behind the results.
Turning the idea into a specification
The first job was not code. We took the idea apart: who the three users are, what each of them actually wants, and which of them has to move first for the other two to have any reason to be there. The answer shaped the entire product. Without plumbers, the app is a catalogue.
Designing for three users at once
Three audiences with different phones, different comfort with apps and different reasons to open one. Each side got its own flows, kept short enough to be used on a job site or a shop floor rather than at a desk.
Building on Flutter
One codebase for Android and iOS, with the backend, catalogue, ordering and admin built alongside it, so the app and the operation behind it went live together instead of one waiting on the other.
Connecting the network
Outlets and warehouses across eight cities wired into ordering and fulfilment, so stock, orders and cities stopped being separate problems and became one flow his team could see.
Growth hacking to 150,000
Referral loops where users recruited each other, rewards tied to real activity rather than sign-ups, and a city-by-city rollout that only moved on once the previous city held. Zero to 150,000 users, without buying its way there.
Before you book the call
Questions about this one
Do I need an existing prototype or user base to start something like this?
No - this one started as an idea described on a single call. No app, no prototype, and no users existed beforehand.
150,000 users is a big number - how much of that was paid acquisition?
None of it was bought. Growth came from referral loops between the three user types and a rewards system tied to real activity, rolled out city by city.
Why Flutter instead of native iOS and Android?
One codebase for both platforms meant one team and one release cycle. For a product that needed to reach real users fast and then change quickly based on what they did, that mattered more than native-only performance this app never needed.
Next Step
Same problem, different company?
Bring the bottleneck. In 30 minutes you leave with the order of operations - whether or not you hire us.