Lessons Building CountPesa

It's been one year since I released CountPesa, an expense management mobile app that automatically tracks M-Pesa (Kenya's most used digital wallet) users' expenses.

The app automates tracking by locally capturing receipt messages which M-pesa diligently sends to users. This enables it to provide users with highly detailed analytics on their spending patterns and helps them create and track budgets with ease.

I thought it would be widely adopted — especially given how popular the advice "track every shilling" is. The biggest hurdle (for me at least) has always been the discipline and effort it takes to do that consistently. Through automation, CountPesa reduces that friction significantly.

I wasn't really building it to make money as many people automatically assumed but I definitely hoped it would. I was building the tool to solve a problem I had, and was sure many others had as well.

I was also building it to learn what it takes to build a product and have thousands of users adopt it. I wanted to see whether I had what it takes to execute something like that.

In the long run, I am a bit disappointed with the uptake after 1 year.

Here are my biggest takeaways after building it.

1. People Care More About Their Balance, Not Expenses

If you build a tool telling people how their balance got to where it's at, don't expect it to blow up. Many people might think it's a great idea, but most won't really use it. Expense tracking is one of those things people know they should do, but don't. You know, like exercise. But if you can build something that will increase their account balance (directly or visibly indirectly), then you really stand a chance of success. That's why loan apps are the most installed apps in Kenya.

Maybe I should have known this already. One of the biggest clues would have been how many people were already paying money to solve the problem of tracking and budgeting. Not that many. I wasn't paying to solve the problem myself. How would I expect someone else to start paying for it. They never had the budget for it in the first place.

It's better to build a better solution to a problem people are already paying to solve. Also, if people aren't paying for a solution, it might speak to how important they think the problem is. Not all problems are worth solving (financially at least).

There are people willing to pay for CountPesa but not enough for me to consider charging worthwhile. There definitely other monetization angles I can explore, but I've decided to move on to other things. I might try some of them out in future.

2. Marketing is the name of the game.

Good products don't necessarily translate to downloads. People first need to know that your product exists, and this isn't easy/cheap. So the question becomes is what your charging enough to cover user acquisition + operational costs? If not, it really not a business, it's something else.

I slowly came to the realisation that what most would be willing to pay (if I was to monetize through subscriptions) wouldn't justify the marketing costs. And I'd probably end up losing more money than gaining.

Another option would be to get creative and market the product in interesting ways through social media. I gave this a try and it's definitely not my strength. I don't really use Twitter, Instagram or Facebook. Therefore, I don't have a following to directly market to. I figured LinkedIn might work, so I tried it. I learnt that marketing is quite the grind, and if the upside isn’t as exciting, there’s no point you have no energy to do it.

All this hustle can be avoided if your product is so great, users want have to share it with friends and family. The elusive networks effect. Though my app does get recommended around, it's not quite at a significant rate. It's still how it's getting downloads now, though at a very slow pace.

3. Don't be pulling people into your product just to have them leave.

So we've covered knowing what people really want and are willing to pay. We've also seen the importance of figuring out the strategy to get them to know your product exists.

Next is avoid a leaky bucket.

Once you have users trying out your product, you have to make sure they stick. How? Your product has to (over)deliver on the promises you made during marketing. That's one thing I like to think I did well.

My top of funnel was bad. Slightly more than 1k downloads in 1 year, but I still have 700+ people using the app (that's majority). And a consistent 300 WAU that is steadily (though slowly) growing. That's a win at least. It shows the app provides real value to some users. This can also be seen from the number of postive app reviews.

4. Other Lessons

The dream was to have high user adoption then eventually have users pay for premium features. Now I realise that this idea didn’t have a high enough ceiling to be worth the push (financially). It seems obvious now, but the possibility really deluded me then.

I didn’t hit my original goals. But looking back, I realize I got something else — lessons far more important than the metrics I wished for. Here are a few that stood out:

• Tracking how users use your app significantly helps you make better decisions. Without it, you're essentially building blind. For example it helped me realise some features weren't being used, not because they weren't wanted, but because they weren't obvious. Users never initiated that flow in the first place.
• Talking to users is a short-cut to adding/optimizing impactful features. You get to understand what they want, how exactly they're using your product, and how best to improve it.
• Building for mobile is a lot different as compared to building for the web. Design decisions becomes more critical, especially when building something that lives just a few inches from a users face and is competing for the users' attention with the likes of IG. For the few minutes a user spends on your app, it's important to make sure it's good.
• Onboarding is important. A lot of churn happens at this point, so it's important to get it right. I'd also add argue that the messaging used prior to the user trying your products falls into this category. It tells them what to expect. One has to be very strategic about these.
• Dog-fooding your product helps your ship quality work. One of the reasons I think CountPesa has good reviews is because I use it a lot and I am the first to identify bugs or opportunities to improve it. There is no better way to empathise with the user as they are using your app.
• Building alone is hard. It would have been nice to have someone to share my excitement, wins and concerns. This hits hard during the subtle moments like brainstorming a certain idea or getting a sophisticated feature working. You'll have no-one to high five. That's when you realise, AI is not a good enough co-founder 😅

Ooh, I also won a Mobile App Award towards the end of last year. But to be honest, I'd have been happier if I'd achieved my user count goals of 10k+ downloads.

Final Notes

As a dev, doing a good job might be delivering features with quality code on time. The decisions of what features to build mostly lies with another party. I got to appreciate the significance of those decisions. And I believe, this understanding will make me a better dev.

PS: I still think CountPesa is the best solution for M-Pesa users and I hope it continues to grow in user base. I'll probably be pushing a few features here and there occasionally, when I feel inspired.