Hard Problems
A working list of genuinely difficult, genuinely useful engineering problems, from AgenticGHX. If you’re an engineer, ML researcher, or CS student looking for problems that matter and that you can’t find in a fintech-clone tutorial — start here.
Why this list exists
Most “AI for Africa” work is a wrapper around an English-language API serving people who already have smartphones and literacy. The interesting problems are the ones underneath: low-resource languages, voice-first interfaces, offline and intermittent-power constraints, and data nobody has cleaned yet. These are hard for real reasons, and solving them is worth real money and real careers.
What we bring that a solo hacker doesn’t: real problem owners (clinics, cocoa co-ops, market associations, schools) who will test your work, domain experts from our life-sciences community who understand the users, API/compute credits, mentorship from diaspora ML engineers, and — for sponsored problems — paid bounties (GHS 3,000–12,000) and paid pilots. You bring the engineering.
How to take one on: join a weekly talk, say which problem interests you in the community chat, or bring it to a hackathon. Strong work on any of these is also the best possible fellowship application. Pick a wedge, ship something small that works for 20 real users, then expand.
1. Ghanaian-language speech models flagship hardest
The problem. Automatic speech recognition (ASR) and text-to-speech (TTS) for Twi, Ewe, Dagbani, Ga, and beyond. Most Ghanaians are more comfortable speaking than typing, and many speak little English — so voice in local languages is the interface layer that unlocks almost everything else on this list.
Why it’s hard. These are low-resource, tonal languages with code-switching (people mix English and Twi mid-sentence), dialect variation, and very little transcribed audio. Off-the-shelf ASR falls over. You’ll wrestle with data scarcity, tone modeling, and evaluation with no clean benchmark.
Where to start. Fine-tune/adapt open models (Whisper, MMS, XLS-R) on the audio that exists; build a data-collection pipeline (community voice donation is a project in itself); publish a benchmark. Collaborate with Ghana NLP, who have done foundational work here — don’t duplicate, build on it.
What we provide. Introductions to Ghana NLP, community members who are native speakers for data + eval, compute credits, and the strongest fellowship signal on this list. Every other problem below can reuse what you build.
Success looks like. A usable Twi ASR/TTS model with a published word-error-rate benchmark and a demo anyone can try — even a narrow domain (numbers, market vocabulary, health terms) is a real contribution.
2. Voice-note bookkeeping for market traders NLP high-value
The problem. A trader says, in Twi, “I sold five bags of rice at three hundred cedis each and bought two crates of tomatoes for eighty” — and gets a running ledger, a daily profit summary, and a month-end report. Ghana’s informal economy is enormous and largely unrecorded, which is exactly why traders can’t get loans (see problem 3).
Why it’s hard. Spontaneous multilingual speech, numbers spoken in mixed languages, no fixed schema, noisy market-audio conditions, and users who will never type a correction. It’s ASR (problem 1) + a forgiving information-extraction layer + a design challenge: how does a low-literacy user confirm or fix an entry by voice?
Where to start. Even a text-first prototype (typed pidgin/Twi → structured ledger) proves the extraction logic before you add speech. WhatsApp is the delivery channel.
What we provide. Market-trader problem owners in Kumasi/Accra to test with, and a sponsored bounty is likely — this is a Tier-1/Tier-2 candidate.
Success looks like. 20 real traders keeping a week of records by voice note, with a profit summary they trust.
3. Credit-readiness from informal records ML fintech
The problem. Turn a smallholder farmer’s or trader’s messy, voice-captured records into the documentation a rural bank actually requires — and tell the owner exactly what a lender will ask before they apply.
Why it’s hard. It’s the downstream of problem 2 plus real domain modeling: what do Ghanaian rural banks and microfinance institutions require? Building the rubric is half the work. Then it’s structuring sparse, irregular data into something a loan officer trusts, without over-claiming.
Where to start. Interview two rural banks (we can help arrange), codify their actual checklist, then build the record → loan-pack transformer.
Success looks like. A farmer walks into a bank with an agent-generated pack and the loan officer says “this is what we needed.”
4. Offline-first agent architectures systems infrastructure
The problem. Everything on this list assumes connectivity and power that Ghana doesn’t reliably have (dumsor = the local word for rolling blackouts). Design agent applications that degrade gracefully: queue actions offline, sync when connection returns, run useful inference on cheap Android phones or at the edge.
Why it’s hard. It’s a genuine distributed-systems and on-device-ML problem — local model quantization, conflict-free sync, SMS/USSD fallbacks when data is out entirely, and a UX that never loses a user’s work. This is infrastructure the whole community can build on.
Where to start. Pick one app from this list and make it work end-to-end on a $60 phone with the plane in airplane mode for an hour. Document the pattern.
Success looks like. A reusable offline-first template other builders adopt.
5. MoMo SMS parsing at scale NLP data
The problem. Mobile money (MoMo) is how Ghana pays for things, and every transaction generates an SMS. Reliably parse those SMS across networks (MTN, Telecel, AT), reconcile them against a shop’s sales, and flag discrepancies — the plumbing under half the commerce problems here.
Why it’s hard. Message formats vary by network and change without notice, edge cases abound (reversals, fees, partial payments), and it must be near-perfect — money is involved. A boring-sounding problem that’s secretly a robust-parsing and reconciliation challenge, with privacy constraints (this is financial data — handle it accordingly).
Where to start. Collect anonymized SMS samples across all three networks, build a parser with an honest test suite, then the reconciliation layer.
Success looks like. A parser that handles real messages from all networks with a published accuracy number and a clear privacy model.
6. Cocoa disease detection on cheap phones computer-vision agriculture
The problem. A cocoa farmer photographs a diseased pod or leaf and gets a likely diagnosis, urgency, and a treatment grounded in COCOBOD extension guidelines — in Twi, by voice. Cocoa is Ghana’s economic backbone; crop disease is a livelihood threat.
Why it’s hard. On-device or low-bandwidth computer vision, a long tail of diseases with little labeled Ghanaian data, tricky field conditions (lighting, angle, phone-camera quality), and the last-mile challenge of delivering advice a farmer can act on. Pairs naturally with problems 1 and 4.
Where to start. Start with the few most common, most economically damaging diseases; partner with agricultural extension officers (we can connect you) for labeled images and ground truth.
Success looks like. Correct triage on real farmer photos for the top handful of diseases, delivered as a Twi voice note.
7. WASSCE/BECE tutor that tracks weak topics education LLM
The problem. A WhatsApp tutor that drills students on real past exam questions, explains step by step, and tracks each student’s weak topics to focus practice — targeting Ghana’s national exams, where results gate a young person’s whole future.
Why it’s hard. The LLM part is the easy half. The hard half is the student model (inferring what someone doesn’t understand from sparse, noisy interactions), pedagogy that explains without just giving answers, curriculum alignment, and doing it all over low-data WhatsApp for students who share phones.
Where to start. One subject, one exam, real past papers. Measure mock-score improvement — that’s your metric and your funding story.
Success looks like. A cohort of students whose mock scores measurably rise after using it.
8. Bio × AI problems research our-unfair-advantage
The problem. Our community is life-sciences-heavy, which means we have problems most engineering groups can’t touch: African genomics analysis (populations under-represented in global datasets), a literature-monitoring agent for African biomedical research, a community-health-worker decision-support tool (protocol-based next steps from voice-described symptoms — support, never diagnosis), and lab-report explainers that turn results into plain Twi a patient can act on.
Why it’s hard — and why it’s the moat. These need engineering and domain knowledge, and we have the domain experts in the room. An ML engineer paired with a genomics or public-health member can build things neither could alone. This is the single best reason for a technical person to join this community rather than any other in Ghana.
Where to start. Come to a talk, meet the biologists, and pick a problem together. The pairing is the point.
Success looks like. A published tool or analysis that a clinician, researcher, or health worker actually uses — with a clinician’s sign-off on anything touching patient care.
Ground rules for all of these
- Ship for 20 real users before you scale to 20,000. Real beats impressive.
- Privacy is not optional — anything touching health, financial, or children’s data gets handled with explicit care, and we’ll flag it with you.
- Voice and local language are features, not afterthoughts — design for the actual user, who may not read English or type quickly.
- Open-source by default so the next builder stands on your work.
Ready?
- Join a weekly talk (/join) and say hello.
- Tell us which problem pulls at you in the community chat (/join).
- Bring it to the next hackathon — sponsored problems come with bounties.
- Strong work here is the best fellowship application you can submit.
This list grows. Have a hard Ghana-specific problem we should add? Tell us.