Hard Problems

A working list of difficult, useful engineering problems, from AgenticGHX. If you’re an engineer, ML researcher, or CS student looking for a problem with a real user at the end of it — start here.

Why this list exists

These problems sit underneath the app layer: low-resource languages, voice-first interfaces, offline and intermittent-power constraints, and data nobody has cleaned yet. Each one is hard for a reason we can name, and each stays open because the people who feel the problem and the people who could build for it are rarely in the same room.

What you get from doing it here. A room: a weekly talk where you can put the problem in front of people, a community chat where the question that would cost you a week gets answered, and a board that is deep in life sciences — Prof. Alexander Kwarteng’s lab at KNUST, and Paz Polak on genomic data. Most of these problems need someone who understands the user as much as someone who can build. Pairing with a domain expert from the community is the part you can’t do from a laptop.

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.

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.

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, 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 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 life-sciences

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

Ready?

This list grows. Have a hard Ghana-specific problem we should add? Tell us.