Over the past few weeks, I came across a LinkedIn post discussing why many HR teams across Africa are expected to do more with software that was largely designed for a different reality. The post highlighted familiar challenges: unreliable connectivity, mobile-first workforces, fragmented systems, and HR platforms that assume every employee has a company email address and a laptop.
I found myself agreeing with much of it as those are genuine challenges and they’re ones we’ve encountered repeatedly while building Hafinen. But after reflecting on our own journey as an African technology company, I realized there’s another challenge that receives far less attention.
It isn’t a technology problem but rather a discovery problem.
I’ve learned that writing software is often the easiest part of building an enterprise platform. The real challenge lies in understanding workflows that have rarely been documented, standardized, or even questioned.
That realization has fundamentally changed how I think about building enterprise software and not just for Africa but from Africa.
We often assume software begins with requirements
One of the biggest misconceptions about software development is that customers know exactly what they need and developers simply translate those requirements into code. In reality this is not the case.
When people imagine building enterprise software, they picture engineers designing databases, writing APIs, architecting cloud infrastructure, and creating intuitive user interfaces. Those are certainly important aspects of product development but they all depend on something far more fundamental: Understanding how work actually happens. Something that sounds straightforward until you begin speaking with organizations.
You’ll quickly discover that very few businesses have fully documented how information flows between departments, how approvals happen, where decisions are made, or why certain processes exist in the first place.
Most organizations simply evolve and processes are created to solve immediate problems. Someone builds a spreadsheet. Another employee introduces a WhatsApp group. Payroll is tracked in one application, recruitment in another, employee records in several folders, and approvals happen over email or in hallway conversations.
Eventually, all these disconnected activities become “the way we’ve always done things.” From the outside it appears chaotic but from the inside it works, at least well enough to keep the business running.
The invisible systems every organization already has
One realization that has stood out during our conversations with HR professionals is that every organization already has a system. It just isn’t always software. The system might consist of spreadsheets maintained by one trusted employee. It might rely on WhatsApp conversations between managers. It could involve printed forms moving from one desk to another before finally reaching payroll. It might depend on institutional knowledge held by someone who has been with the company for ten years.
These invisible systems are remarkably resilient because they’ve evolved over time to accommodate the organization’s unique way of operating. The challenge for software companies is that none of this complexity appears on a requirements document. And if we’re not careful, we risk replacing visible software with assumptions while overlooking the invisible workflows that keep the business functioning.
Discovery is harder than development
One important lesson I’ve learned is that customers rarely describe workflows. They will describe symptoms. An HR manager might say… “Payroll takes too long.” Another might explain… “Our onboarding process is manual.” Or perhaps “We spend too much time following up on approvals.” These are important observations, but they’re rarely the underlying problems.
As founders, it’s tempting to treat these statements as product requirements. They should be treated as the beginning of a much deeper conversation. Why does payroll take too long? Where does information originate? Who approves salary changes? How many times is employee information entered into different systems? Which tasks exist simply because another system doesn’t integrate properly? These questions often reveal workflows that nobody has consciously mapped before.
Ironically, some of our most valuable product insights haven’t come from discussing software at all. They’ve come from understanding people.
Why many founders look beyond the continent
One question I’ve occasionally encountered is why African software companies spend so much time studying established global platforms. Shouldn’t they simply build for Africa? I believe that’s the wrong question because companies like Workday, SAP SuccessFactors, Oracle HCM, and UKG didn’t become industry leaders because they had better programmers. They became successful because decades of customer conversations shaped their products.
Behind every feature lies years of feedback from HR professionals, consultants, payroll specialists, organizational psychologists, compliance experts, and enterprise customers. That accumulated knowledge is invaluable. And studying these platforms isn’t about copying them but rather understanding why certain problems were solved in the first place. Every mature enterprise platform represents thousands of lessons learned and ignoring those lessons would mean solving the same problems from scratch.
But copying isn’t innovation
Learning from global platforms doesn’t mean assuming their solutions apply everywhere. Africa presents realities that require different thinking. These realities might include:-
- Organizations may have employees without corporate email addresses.
- Field/frontline workers often rely entirely on smartphones.
- Labour regulations differ significantly across jurisdictions.
- Connectivity can vary depending on geography.
- Business structures evolve rapidly as companies scale.
- Workforces may combine permanent employees, contractors, consultants, seasonal workers, and distributed teams across multiple countries.
These aren’t extreme cases but rather everyday realities for many organizations and building software for these environments requires flexibility rather than rigid assumptions. The goal shouldn’t be to recreate an existing HR platform with a few localized features but to rethink enterprise software around the environments in which people actually work.
Building software from Africa, not just for Africa
This distinction has become increasingly important to me. There’s a subtle but significant difference between building software for African businesses and building world-class software from Africa. The first focuses primarily on geography. The second focuses on quality, ambition, and perspective.
African founders operate within environments that demand resilience. We design for diverse regulations, mobile-first workforces, growing businesses, varying infrastructure, multiple currencies, different labour practices, and rapidly changing markets. These constraints don’t limit innovation but strengthen it.
If a platform can accommodate that level of complexity while remaining intuitive to use, there’s every reason it can compete internationally. Great software doesn’t emerge because it was built in a particular country, it emerges because it solves meaningful problems exceptionally well.
The evolving role of HR technology
As of now, many organizations are still focused on digitizing administrative processes but I don’t believe that’s where the future ends. As organizations mature, their questions begin to change. So instead of asking “How do we automate payroll?” They start asking “How do we retain our best people?”, “Which teams are becoming overloaded?”, “Where are our future leaders coming from?”, “How do we improve employee development?”, “How do we build stronger organizational cultures?”…
Technology shouldn’t merely automate existing processes, it should enable better organizational decisions. And that shift from administration to strategy is where I believe the next generation of HR technology will create the greatest value.
The future belongs to better discovery
Looking back, I no longer think the biggest challenge in building enterprise software is engineering simply because engineering problems eventually have technical solutions. Discovery problems on the other hand require curiosity. They require listening before building. They require observing rather than assuming. They require understanding organizations well enough to identify inefficiencies that have become invisible through familiarity. Every meaningful feature begins long before the first line of code is written. It all begins with understanding work.
As of now, our greatest challenge isn’t that organizations lack technology, It’s that many of the workflows technology is meant to improve have never been fully articulated. This isn’t unique to HR. It’s true across many industries where businesses have grown organically, adapted to changing circumstances, and developed resilient using largely undocumented ways of working.
For founders, this presents both a challenge and an extraordinary opportunity and the companies that succeed won’t simply write better software. They will become better students of how organizations operate because once you truly understand the work, building the technology becomes the easier part.
And just maybe that’s Africa’s greatest opportunity. Not to build software that imitates the rest of the world but to build world-class enterprise software from Africa, grounded in our realities, informed by global best practices, and capable of serving organizations wherever they are.
