Lessons Building CountPesa

It's been one year since I released CountPesa, an expense management mobile app that auto-tracks user expenses.

The app automates tracking by locally capturing receipt messages which M-pesa (Kenya's most used digital wallet) diligently sends to users. CountPesa provides the user 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. CountPesa reduces that friction significanly by automating much of the process.

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. A lot of people might think it's a great idea, but most won't really use it. It's one of those things, people know they should do, but they 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 big the problem is. Not all problems are worth solving (financially at least).

There were people willing to pay for my app but not enough for me to consider charging worthwhile. Another angle was selling user expense data, but I'm not a fan of that.

2. Marketing is the name of the game.

Good products don't necessarily translate to downloads. You need to get the product infront of as many people as possible for them to decide whether they want it. And it isn't cheap. So the question becomes is what your charging enough to cover the acquisition + operational costs? If not, it really not a business, it's something else.

Considering how people valued the tool and the numbers I had, I slowly came to the realisation that what most would be willing to pay wouldn't justify the marketing costs. And I'd probably end up losing more money than gaining.

Alternatively, you have to be really creative and market your product through social media. I gave this a try and it's definitely not my strength. I don't use Twitter, Instagram or Facebook. Therefore, I don't have a following. I figured LinkedIn would be the place to market. Well, marketing is quite the grind, and if the upside isn’t exciting, there’s no point you have no energy to force it.

All this hustle can be avoided if your product is so great, users want have to share the product with friends and family. The elusive networks effect. Very rare. My app did get recommended around, but not quite at scale. 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.

Avoid the leaky bucket. Even before solving this, obviously know where the users will come from. How you'll get them and have a sense of their interest.

Once you have them, you have to make sure they stick. How? Make sure they understand your product and what to expect from it. If they like you're offer and you deliver on it, they'll stick to it. That's one thing I did well.

My top of funnel was bad. Slightly more than 1k downloads in 1 year, but I still have 600+ people using the app (that's still majority). And a consistent 300 WAU steadily but slowly growing as more people discover the app by themselves. That's growth. Slow, but it's still growth. It shows the app at least has some real value to some niche users.

It would have been great to have growth on a paid product with decent margins. But at some point, I realised that this idea didn’t have a high enough ceiling to be worth the push. It seems obvious now, but the possibility really deluded me then.

4. Other Lessons

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 web development. Good design becomes critical, especially for something living just a few inches from a users face and competing with other apps like IG for the user's attention. This really forced me to level up.
• Onboarding is important. A lot of churn happens at this point, so it's important to get it right. I'd also add that the messaging used prior to the user trying your products falls into this category. 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.
• Building alone is hard. Imagine having no one to share your excitement, small wins and concerns. This especially hits you in the subtle things 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.

In Conclusion

As a dev, doing a good job is probably delivering functionality x, y and z on time ensuring your code is performant, maintainable, bug free and all those other important things. 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.