There's a version of building software for a new market that looks like this:
Take a product that works somewhere else, swap out the currency symbols, add a few local payment options, and ship it. We knew before we started that approach wouldn't work for African business finance. What we didn't fully anticipate was how many of our own assumptions would need to be revised once we started talking to the people who would actually use what we were building. This is an honest account of what we've learned — about the market, about our users, and about what it actually takes to build financial software that earns trust in contexts that have been underserved for a long time.
The diversity of African markets runs deeper than we expected
We knew Africa was a diverse continent before we started. That's not a surprising observation. What surprised us was how much that diversity shows up at the product level — in ways that aren't always obvious from the outside. A Lagos-based startup and a Nairobi logistics company and a Johannesburg professional services firm all have expense management needs, but the specifics diverge quickly.
The currencies are different.
The payment method preferences are different — M-Pesa is a default expectation in Kenya in a way it isn't in Nigeria, where bank transfers and mobile money from different providers coexist with different levels of adoption.
The regulatory context varies.
The org structures vary.
Even the way people think about the relationship between a finance team and the rest of the business varies in ways that affect how approval workflows should be designed.
Early on, we made the mistake of building toward a single model of how expense management works and assuming the details would be configurable. The feedback we got was consistent: the details aren't details. They're the product. A tool that handles KES correctly but treats the M-Pesa reimbursement flow as an afterthought isn't really built for Nairobi. A tool with approval workflow configurations that map to a US startup org chart isn't really built for a Johannesburg firm with a structured finance function and a clearly defined approval hierarchy by spend category.
What we've learned to look for is the common thread — the things that are true across markets — and build those as the foundation, while staying genuinely flexible on the specifics rather than treating local variation as edge cases to be accommodated reluctantly. The common thread is simpler than you might expect: people need to submit expenses, get them approved, get reimbursed, and have the records be clean enough to be useful. Everything else is context.
Finance teams have seen a lot of bad software
When we talk to finance managers — and we've now talked to hundreds of them across Nigeria, Kenya, Ghana, South Africa, and several other markets — there's often a layer of scepticism in the early part of the conversation that takes some time to work through. It's not unfounded. Finance managers at African companies have been told before that software will fix a process. Usually what that meant in practice was a months-long implementation, a steep learning curve, a tool that solved the problem it was designed to solve in its home market and approximated a solution for theirs, and an ongoing dependency on a support team operating in a time zone that made urgent issues very difficult to resolve.
The scepticism isn't about technology. Finance managers in African markets are not technology-averse — many are running sophisticated financial operations with tools assembled from whatever was available. The scepticism is specifically about whether a new piece of software will actually understand their context, or whether they'll spend six months adapting their processes to fit a tool that was never really designed for them.
Earning trust in that environment means a few things we've had to be deliberate about. It means being honest about what we do well and what we don't — not overselling in a demo and then falling short in production. It means making sure the things we do well are genuinely useful in practice, not just impressive when someone is evaluating the product. And it means being responsive when something goes wrong, in a time zone and through channels that make responsiveness actually possible.
We haven't always got this right. But the feedback from the finance managers who've stuck with us longest has been consistent: the trust was built incrementally, through reliability and honesty, not through feature announcements.
The fundamentals matter more than the feature list
Building a software product creates a particular kind of pressure to keep adding things. There's always a feature that would make the product better in some cases. There's always a competitor doing something you're not. There's always a user asking for something that seems reasonable and specific. The feedback that has shaped our product decisions most isn't requests for new features. It's the consistent signal that what users need most is for the things the product already does to work reliably and fast.
This sounds obvious until you're inside a product development cycle and weighing a stability improvement against a new capability. The stability improvement doesn't show up in a product announcement. It doesn't generate the same kind of positive feedback that a new feature does. But the absence of stability shows up immediately and visibly — in the finance manager who stops using the product because an approval notification didn't come through and a reimbursement sat unprocessed for a week, or in the employee who takes a photo of a receipt and waits thirty seconds for the upload to complete and gives up and sends it on WhatsApp instead.
We've learned, sometimes the hard way, to prioritise the experience of the core workflow over the breadth of the feature set. An expense tool that does five things reliably is more valuable to a finance team than one that does fifteen things inconsistently. Speed and reliability aren't the exciting parts of a product to talk about, but they're the parts that determine whether people actually use it.
What "built for Africa" has to mean in practice
It's easy to say a product is built for African markets. The phrase has become common enough to be almost meaningless without specifics. What we've learned it has to mean in practice is more concrete than a positioning statement.
It means the product works on the devices your users actually have. A significant proportion of the employees submitting expenses through Farthingly are doing so on mid-range Android phones, sometimes on 3G connections. If the receipt upload is slow or the interface is optimised for a fast Wi-Fi connection and a recent iPhone, the product doesn't work for them — regardless of what the marketing says.
It means the payment infrastructure your users rely on is treated as a first-class integration, not an add-on. Paystack and Flutterwave aren't alternative payment options for users who don't have Stripe. For most of our users, they're the primary payment infrastructure. M-Pesa isn't an edge case — in Kenya, it's the default expectation for how reimbursements should arrive.
It means the currencies your users work in are supported without workarounds. NGN, KES, GHS, ZAR — these should work exactly the way USD works in tools built for US markets. Not approximately. Not with manual conversion steps. Exactly.
And it means the support your users need is available when they need it. A finance manager in Lagos trying to resolve a payroll-adjacent expense issue at 4pm on a Wednesday needs a response that day, not in the next business day window of a support team operating on US Eastern time.
What we're focused on right now
Farthingly is early. There's a lot we're still building, and we're honest about that with the teams who use us. What we're focused on right now is getting the core loop right and keeping it right as we grow: an employee submits an expense, it reaches the right approver, it gets approved, the reimbursement goes out through the right rails, and it shows up correctly in the finance team's records.
When that loop works smoothly and reliably for a range of company sizes, structures, and markets, we have something worth building on. That's a less exciting headline than announcing a new AI feature or a new market expansion. But it's the work that actually determines whether the companies using Farthingly will still be using it in two years — and whether we'll have earned the right to build the more ambitious things we want to build on top of it.
If you're a finance team at an African company who's been waiting for expense management software that was actually designed for your context, we'd like to show you what we've built so far.