The Rise of Digital Ticketing in Tanzania
Lessons from Otapp's integrated approach to travel and events
Background
Dear tech founder, innovator, or business leader,
I hope this letter finds you well.
My name is Grayson Julius from iPF Softwares.
I am reaching out to you at the request of a good friend and colleague, Isai Mathias.
He is a researcher and writer of the Tanzanian science and technology newsletter Atoms & Bits.
In this letter, I aim to share valuable insights on key issues affecting technology companies in Africa.
Here’s what you can expect:
Common challenges and pitfalls for tech startups in Africa
The true cost of poor code quality (both direct and indirect)
The domino effect: how it impacts business growth
Building a solid foundation for your startup
Strategies to get back on track and address technical debt
Disclaimers:
The insights shared in this letter are based on my experiences and those of my team at iPF Softwares, where we have built large-scale digital solutions across various industries in Africa.
These are opinions, not absolute facts.
While I will mention specific names and provide examples, some case studies have been dramatized to illustrate key points.
Please adapt the advice to your own context and situation, as said in Swahili, “Akili za kupewa changanya na za kwako.”
Some suggestions may not apply to your current stage or specific circumstances.
It’s a long piece. So brace yourself, pause, and take notes if needed.
Thank you for reading Atoms & Bits. This post is public so feel free to share it.
Introduction
I have had the privilege of leading a technical audit and review of more than 60 fintech and edtech startups in Tanzania with my team at iPF Softwares through great accelerator programs:
PesaTech (Cohorts 1 and 2), in partnership with UNCDF alongside Sahara Ventures and Anza Entrepreneurs
Mastercard Foundation’s EdTech Fellowship program with Sahara Consult.
Without mentioning names, some examples and case-studies will be based on my prior engagements with our partners and technology startups in the mentioned programs.
PART ONE
The Foundation (From an Idea to MVP)
I understand the pressure to launch quickly and disrupt the market.
However, cutting corners while building digital solutions ultimately hinders your growth.
Below are some common issues that affect most African technology startups during their early days.
They can also apply to established companies that want to build and maintain digital products.
To illustrate challenges, I have used a fictional scenario (inspired by real events) about a non-technical founder attempting to launch an app in Tanzania.
Case Study: Getting Ghosted
1. You Hire a “Full Stack Developer”
Ashura, an innovator, comes up with a great idea but lacks the technical skills to build the solution.
Like many non-technical founders, she usually ends up hiring a technology company or a freelance “full stack” developer, often opting for the cheapest option available to bring her solution to life.
For better context, let’s say the freelance developer, John, gets the gig and starts working on the mobile app.
Ashura shares her “requirements“ with him, but these specifications are often vague and undocumented.
This leads to scope creep as the project progresses.
Eager to see her idea come to life, she sets a tight deadline. “Can this be done by next month?”.
John, keen to secure the job, agrees to the timeline despite knowing it’s unrealistic.
He says, “Yes, it can be done,” hoping to figure things out along the way.
John luckily receives 50% of the payment upfront, which is crucial for him to start the work.
2. Common Challenges in Digital Product Development
John begins working on the mobile app.
Being the “Full Stack Developer," he has to handle everything from UI/UX (user interface/user experience) design to database design, system architecture, QA (quality assurance), and business logic.
The success of the project largely depends on John’s experience, professionalism, and adherence to best practices.
Unfortunately, professionalism can often be lacking among local developers, like most “fundis” (handymen).
According to a poll I conducted a few weeks ago, the biggest challenge when working with local developers is a lack of professionalism.
John chooses the framework and technology stack he is most comfortable with, often without consulting Ashura.
He designs the user interface, system architecture, and database on the fly, which can lead to inefficiencies and future problems.
As the deadline approaches, the pressure mounts.
The lack of a clear plan and proper resources leads to delays and frustration on both sides.
At this point, John could ghost Ashura at any time. Continue reading.
Fast forward to three months later.
Months of back-and-forth communication and mounting stress have led to a disappointing outcome.
Ashura, frustrated by the prolonged deadline, threatens to withhold John’s final payment.
In a bid to meet the new deadline and get paid, John resorts to quick fixes, compromising the quality of the app.
When Ashura finally receives the app, she tests it and finds multiple errors and crashes.
Frustrated, she tries to contact John, who avoids her calls and messages.
(Ashura just got ghosted.)
The relationship deteriorates, and the project ultimately fails.
Best Practices for Non-Technical Business Leaders
An Email (Letter) to Ashura
A number of things went wrong.
I’ll focus on three key areas where Ashura (as the client who invested in the app project) could have taken a different approach to avoid her financial loss.
However, most African developers currently lack the expertise to implement best practices.
Careful selection of your software development partner is important.
Dear Ashura,
I hope this letter finds you well. Sorry for what happened during your recent engagement with John.
Based on your situation, below are some things you could have done better (or improved).
1. Unclear Requirements
It is ultimately the founder’s responsibility to provide clear and specific requirements to the development team.
Without clear instructions, surprises are inevitable.
I usually use the following metaphor: Your developer is like a chef you ask to cook ugali and fish.
If those are the only instructions given, there are countless possible outcomes.
As the founder, you hold the vision and understand the problem domain better than your developers.
Ensure you have outlined all necessary business logic, and only expect feedback and technical recommendations from your developers.
Developers are not mind-readers.
They need clear requirements to work effectively.
2. “Full Stack Developer” is a myth
While not impossible, the belief that a single developer can handle all aspects of a digital solution is risky.
It’s akin to hiring a single “fundi ujenzi” mason to build a family house, expecting them to handle plumbing, electrical work, and masonry alone.
Instead, focus on assembling a team with specialized strengths (UI/UX designer, backend developer, and frontend developer).
A diverse team accelerates workflows and delivers superior software.
Don’t fall for a “full-stack” label. I understand it could be expensive, but yeah, cheap is expensive too.
If you're on a budget, I would advise you to do the engagement in phases.
When you already have clear requirements:
Hire a UI / UX designer to bring your requirements to life with visual designs.
Investing in design early is cost-effective and helps validate requirements before diving into development.
You could then engage John, and perhaps one more developer could work with John to build your solution.
With a clear design, John and colleagues can provide more accurate timelines and deliverables.
Once John is done with a couple of features, share the app with family and friends, or if you can hire a group of interns for one or two days to get hands-on on the app to identify bugs and issues.
3. Unrealistic deadlines
I understand the pressure to launch quickly and disrupt the market.
However, cutting corners while building digital solutions ultimately hinders your growth.
It takes time to build solid digital products.
And of course, some developers may have super powers.
But they can’t turn 1 hour into 2 hours.
That is beyond their magic.
It’s important to set practical deadlines with John.
Ask him for a clear plan every two weeks to see how things are going.
Give John a chance and ask him to share a clear timeline of what will be delivered weekly.
Inititially, you might not see much progress.
Why? John must first lay down the project’s foundation, understand what is needed, and plan how things will look.
Having a process where you improve and give feedback regularly is key.
This helps catch problems early.
Setting realistic timelines enables a step-by-step approach to developing your project.
It helps to have regular check-ins and discussions with John to make improvements as you go along.
In your case, there weren’t enough of these check-ins, so problems only came up later.
That rushed approach led to quick fixes that didn’t always meet the quality you were aiming for.
Regards,
Your Technology Advisor,
Grayson from iPF Softwares
PS: Please leave a comment if you have any other suggestions about what Ashura should have done differently.
PART TWO (Teaser)
Growth Stage: From a Minimal Viable Product to Scaling
To practically understand this section, I also came up with a fictional story about Shaka and Shungu.
These are two founders who have been friends since college.
Shungu, the technical founder, is a passionate developer with a bachelor’s degree in computer science.
His partner, Shaka, is a non-technical founder who majored in finance.
They have successfully built their solution and gained some paying users.
But they struggle to scale and reach their full potential due to a buggy product.
Shaka blames Shungu for not taking charge, while Shungu blames Shaka for not understanding the root cause of the issues.
To be continued...
Depending on the number of requests and engagement with this article, I will consider finishing this letter to Shaka and Shungu.
Acknowledgements
I extend my sincere gratitude to Isai Mathias for allowing me to grace his newsletter.
I also appreciate the great founders and innovators who have shared their challenges and hustles during our engagements.
Special thanks to my team and partners at iPF Softwares, who constantly focus on building solutions that drive impact in our communities.
Lastly, thank you—yes, you—for taking time to read this piece.
Please forward it to a friend or colleague who you believe should read my message to founders and business leaders.
Keep building and remember to always #BeAgile