Ghana's FMCG Restocking App: 10,000+ Installs Built by a Dedicated Squad

ASA Dwaso Limited arrived with distributor relationships and a market hypothesis, not a product specification. Four problems were visible in the first workshop. The fifth only surfaced after the app had been live for three months.

• Nobody could write the spec. There was no reference product to point at. Sell by unit or by carton? Show the supplier before the price? Allow credit at all? Every answer had to be tested against real shop owners and reversed when we guessed wrong — and we guessed wrong often in the first quarter. That is a poor fit for fixed-scope mobile app development and the reason the engagement model became the first real decision on the project.
• The user is not the user you design for by default. Our first mockups were clean, spacious, image-heavy and English-first. Then we watched a trader use them on an itel with 2GB of RAM and a rationed data bundle. Photos ate her data, text vanished in sun glare, and she searched "Ideal milk" — not "evaporated milk, 380g, tin".
• Payments in Ghana do not work like payments in a tutorial. Cards are a rounding error. Mobile money is everything, cash on delivery is expected by first-time buyers, and informal short-term credit runs the wholesale trade. Ignore credit and you have built an app that ignores your best customers.
• Half the delivery addresses do not exist. "Behind the blue kiosk near the Shell station, ask for Auntie Grace." That is a functional address in Accra. It is not an address a routing algorithm can use.
• The real problem was supply, not demand bold text. Three months after launch, orders were failing because supplier stock feeds were stale — cartons sold that had left the warehouse that morning. The app looked broken; it was not. The supplier side was underbuilt, and fixing it reprioritised roughly a quarter of the roadmap.

Engagement model first, because it shaped everything else. Fixed-scope is the right call when you already know what you are building. ASA Dwaso didn't. When requirements are being discovered rather than documented, fixed-scope becomes a machine for generating change requests, estimates, approvals and delays. So they ran a dedicated development team on a rolling monthly engagement and paid for capacity, which we spent on whatever mattered most that fortnight. The supplier-side pivot in month four would have been a formal change request under fixed scope. Instead it was a Monday conversation and a reordered backlog.

• The team. Five core: two Flutter developers, two Node.js backend engineers, one full-time QA lead — plus design at roughly 40% and DevOps at 20%, flexing to near full-time design during the rider app sprints. You interview the engineers who will do the work, and those are the engineers who do it. Standups at 07:30 GMT, a comfortable Accra–Jaipur overlap. Two-week sprints, one shared board the founder had the same access to as our PM, and a WhatsApp group for anything urgent.

• Testing on the hardware the market actually owns. We bought cheap physical phones — Tecno, Infinix, itel, a couple of low-end Samsungs. Emulators lie about 2GB devices: about performance, about background process kills, about what happens when signal drops mid-checkout. A dedicated QA engineer sat on this team from week one, running full regression on real hardware throttled to bad-3G conditions under a metal market roof. We treat software testing and QA as part of the build rather than a phase bolted on at the end, and the release gates, code review and defect handling behind it follow the documented path set by our ISO 9001:2015 quality management certification.

• Security, stated plainly because of what this build handles. Buyer phone numbers, delivery locations, payment references and a live credit ledger showing what every trader owes. Emizentech is ISO 27001:2022 certified for information security, covering access control, encryption, vendor review and incident response — audited, not self-declared. If your build touches payment data or personally identifiable information, ask any partner for the certificate rather than the claim.

• Phase one (~14 weeks): get something real in front of real traders. Android customer app, catalog and search, cart, mobile money, cash on delivery, a basic ops console, order status by SMS. Deliberately narrow — no supplier portal, no credit, no rider app. Orders were dispatched from a spreadsheet, and at that stage that was the right call. You cannot learn from a prototype; you learn from an order with real money and real cartons attached.

• Phase two: the supply side and everything after. Supplier portal with live stock, the order allocation engine, credit accounts with limits and terms, the rider app, landmark-tolerant routing, offline-first behaviour, WhatsApp notifications and the reporting layer. Most of the engineering sits here, and almost none of it was in the original plan.

What shipped, and why each piece exists:

Tailored for Ghanaian traders, this B2B e-commerce platform streamlines B2B procurement with a slang-tolerant search index, trade-unit conversion logic (cartons to singles), and a high-traffic "Buy Again" feature for instant reordering. To solve local delivery challenges, its multi-modal addressing system combines Ghana Post GPS, dropped pins, and landmark descriptions.

The solution drives digital adoption through three payment tracks: mobile money, auditable credit ledgers with live exposure tracking, and Cash on Delivery (COD) to establish zero-risk trust for first-time online buyers. Communication runs entirely via WhatsApp to maximize open rates.

Built on a single offline-first Flutter codebase powering both buyer and rider apps, the system relies on idempotency keys to prevent duplicate orders across unstable market networks. Drivers handle offline proof-of-delivery and cash collection, while a centralized ops console completely replaces legacy spreadsheets for dispatch, credit, and performance tracking.

Public numbers where they exist, internal reporting where they don't. Where there is no clean before-and-after, we have said so rather than inventing a percentage.

• 10,000+ installs on Google Play. Grown through distributor networks and word of mouth in market communities, with minimal paid acquisition. Modest until you remember the buyer: most of this customer base had never bought anything on a phone before, and getting a trader to trust an app with a GHS 800 order is a real achievement.
• 4.7 Google Play rating. Across verified reviews, for a B2B utility app used daily by non-technical buyers.
• Manual dispatch retired. The spreadsheet-and-phone-calls process from phase one is gone. Orders now route through the ops console straight to riders.
• Cash on delivery opened the market. Pay-on-delivery brought in buyers who were never going to pay a new app in advance. Many switched to mobile money on later orders.
• Informal credit moved onto a ledger. Undocumented trade credit became ledgered accounts with limits, terms and automated reminders — the longest-tail change of any we made, and the one that most changed how ASA Dwaso manages risk. Handled under ISO 27001:2022 controls throughout.
• Zero handover loss across two years. The same core engineers stayed on the project throughout. Nobody had to rediscover why the allocation engine works the way it does, and the squad is still running today — smaller now, same people. That continuity is the practical argument for the dedicated developers model over rotating contractors.

Most funded startups hit the same fork in year one: build in-house, use contractors, or run a dedicated squad through a partner. In-house is right eventually and expensive early. Contractors are quick and leak context. ASA Dwaso had commercial depth and no engineering function, which is exactly the shape the middle option suits. They paid for capacity on a rolling monthly basis rather than for a scope document, so learnings became backlog reordering instead of change requests. The honest test for any buyer weighing this up: are your requirements knowable yet? If they are, take a fixed quote from someone. If they aren't, the ability to hire dedicated developers is what stops you paying twice to learn what nobody could have known upfront. Where a client needs strategic direction as well as delivery capacity, the same model extends to a fractional CTO.

Design assumptions that work in a studio fail on an itel with 2GB of RAM and a metered data bundle. We rebuilt for aggressive image compression, high-contrast type legible in direct sun, and a cached catalog with a persistent cart and queued, idempotent order submission. QA ran full regression on a drawer of real budget handsets — Tecno, Infinix, itel, low-end Samsung — throttled to bad-3G under a metal market roof. If you are building for this kind of market and testing on a Pixel, you are testing a different app.

Three rails, three levels of trust. Mobile money (MTN MoMo, Telecel Cash, AirtelTigo Money) through a Ghanaian aggregator with webhook reconciliation and retry logic so finance is not matching payments by hand. Cash on delivery as the on-ramp for first-time buyers. And a credit ledger with per-buyer limits, per-supplier terms, live exposure for ops and automated pre-due reminders — bringing informal wholesale credit into a system that can actually be reported on.

Mobile, backend, DevOps, QA and design under one roof. When the roadmap moves — and on this project it moved a great deal — you are not sourcing a new discipline mid-sprint. Whether an engagement needs Android developers, backend engineers, a QA lead or design capacity, the people come from the same team and stay on it. Average developer tenure runs to years rather than months, which on a two-year build is the difference between a team that knows your domain and a team that keeps asking the same questions.