Mobile Banking Platforms

The phone your customer actually owns

Smartphone ownership in Tanzania keeps growing, but the market that growth has produced is not the one app designs are usually drawn for. The typical customer is holding an entry level smartphone, often a few years old, with little storage to spare. Data is bought in small bundles and the price of a megabyte is felt. Outside the main towns the connection comes and goes through the day. An app built on the assumption of a recent flagship and an office connection quietly excludes a large part of the customer base it was meant to serve.

That gives the app a harder brief than it first appears. It has to be light enough that a customer installs it and keeps it on a phone with no room to spare, quick enough to be worth opening for a balance check, and dependable enough that someone will trust it with a rent payment on a weak signal. Customers do not grade it against other banks alone, but against the mobile money apps they already use every week, and against a public store rating anyone can read before downloading.

This matters most to institutions with a retail book to defend. For a bank, the app is where the everyday relationship now lives while the branch sees the customer less each year. For a microfinance institution or a SACCO, it is what younger members expect before they will join. For a fintech it is the entire business, with nothing behind it to fall back on.

What customers come to the app for

An app earns its place by absorbing the reasons a customer would otherwise come in. Accounts and balances across everything they hold with you. Statements they can search by date or amount and send on when a landlord, an employer or an embassy asks for one, instead of collecting a printout at a counter.

Moving money is the bulk of the traffic: transfers between their own accounts, to other customers, to other banks, and to and from mobile money wallets in both directions, which in this market is the first journey most customers look for. Then bill payments for utilities, television, school fees and government charges, payments to merchants in shops, and airtime for themselves or someone else.

Beyond payments sit the products that make the app worth keeping. Card controls: seeing the card, freezing it, adjusting limits, ordering a replacement, raising a dispute. Savings goals and fixed deposits opened, tracked to maturity and rolled over without a visit. Loans, from checking eligibility and applying to watching the balance come down and settling early. Alerts on every debit, on a salary arriving and on a payment falling due, often the first thing customers name when asked what they value.

Then self service, which is where the operational return usually sits. PIN and password reset, changing a registered device, adjusting a limit within the band you allow, updating contact details, requesting a statement, raising a complaint. Those are the calls that fill a contact centre and the queues that fill a branch on a Monday morning. Which journeys launch first is a decision we make with you, and we will argue for the handful your customers repeat every week ahead of a longer menu with half of it unused.

One product, wherever a customer meets it

An app does not reach everyone on your book, and planning as though it will is expensive. Customers on feature phones, customers in districts where a data connection is not dependable, customers who would rather hand cash to a person they know: those are served by USSD and by an agent network, and for many institutions they are still the majority.

The same customer often uses more than one channel in a single day. A salary alert arrives on the app, the cash comes out at an agent, and a transfer goes through a USSD menu on a trip upcountry. What they should find in each case is the same product: the same limits, the same charges, the same balance, the same account. Where an institution has commissioned its channels separately over the years, they drift, and customers meet the drift as being quoted a different fee or refused something they were allowed to do yesterday. That costs trust faster than an outage does.

The app can carry more than the other channels, and it should: richer statements, card controls, applications, documents. The judgement worth making early is which of those must also exist in a simpler form elsewhere. We build across these channels, so a mobile engagement can fit the estate you already run or be the first piece of a wider programme, scoped against what you have rather than in isolation.

What it takes to get an app live

Publishing a banking app is a commercial exercise with a queue inside it. The app reaches customers through developer accounts on the app stores, and those should be opened in your institution's name, with your legal entity and your billing, held by you rather than by a supplier. Someone on your side has to be authorised to accept the stores' terms and to stand as the named publisher. An app published under a vendor's account is a dependency you do not want to discover later.

Every submission is reviewed before it appears, and financial apps attract more scrutiny than most. A store will commonly ask a publisher to show it is the regulated institution it says it is. The review is not instant and not fully within your control, so it belongs in the launch plan as a real step, not a formality at the end of one.

Brand and design decisions need an owner with authority. What the app is called, how it is found when someone searches, the icon, the colours, the tone of the messages it sends, which of your product names a customer sees. These look like small choices, and they hold up more launches than the build does.

If you already have an app, the move is the harder half of the work. Existing customers have to be told what is changing and what they must do, in the languages they bank in, through channels they will actually read. Branch staff and the contact centre need to be able to answer before the first customer asks rather than a week after. The old listing, its ratings and its history are a marketing question as much as anything else. And choosing a launch window away from salary week and month end is worth more than most teams expect.

What working with us looks like

We start with discovery: your customers, your products, the channels you already run and the constraints you actually operate under, then an agreement on what the app must do at launch and what follows. You get a scope and a plan out of that, and the plan is yours whether or not we build it.

Through delivery you review the app on your own phones, in an environment you control, rather than reading progress reports. The source code and documentation are yours from the first commit. We support the app in production afterwards and train your team to take on as much of it as you want. There is no lock-in, by design and by contract.