“Let’s build something with AI” is not an AI use case: it’s an intention. Every year, students, researchers and project owners in Morocco start from the technology rather than the problem, and deliver an impressive demo that solves nothing for anyone. Here’s how to choose an AI use case that actually holds up, before writing the first line of code.
The trap of the “technology-first” AI project
The pattern repeats itself: someone discovers a capability — classification, text generation, computer vision — and then looks for a problem to apply it to. The result is often a solution in search of a problem: technically correct, but nobody asked for it, and nobody will use it after the defense or the demo.
The reverse order works better. Start from a real, documented problem, felt by identifiable people. Then check whether AI is actually the right answer — which isn’t always the case. A simple rule, a better-designed form, or a reorganized manual process sometimes solves the same problem faster and with less risk. Only once the problem is framed does the question of concrete generative AI uses become relevant — not before.
The cost of getting this wrong isn’t only technical. A poorly scoped use case eats up weeks of development, drains a team’s motivation and, in an academic context, uses up research time that could have served a better-framed question. Picking the wrong use case almost always costs more than the time spent choosing it carefully.
Four criteria for spotting a useful use case
Before validating an idea, run it through these four criteria. If any one of them has no clear answer, it isn’t a use case yet — it’s a hypothesis still worth digging into.
| Criterion | Question to settle | Warning sign |
|---|---|---|
| Documented problem | Who suffers from this problem, and since when? | No one can cite a concrete recent case |
| Available data | Does this data already exist, at sufficient quality? | ”We’ll collect it later” |
| Measurable value | How will you know the project works, in one metric? | No metric defined before starting |
| Possible supervision | Who checks the results over time, once the project is live? | No one is assigned to that role |
The most commonly overlooked criterion is the last one. A model that works on demo day is not the same thing as a system supervised for months, with someone able to catch drift or a silent error.
Comparing several candidates instead of deciding on instinct
A single use case evaluated in isolation rarely leads to a good decision — everything looks promising when there’s nothing to compare it to. List three to five candidate ideas, then score each on two simple axes: the estimated effort to reach a credible first test (data to gather, logic complexity, external dependencies), and the expected value if the manual test confirms the intuition (number of people affected, how often the problem occurs, real gain per occurrence).
The candidates worth pursuing first are the ones combining low effort with clear value: they let you test a hypothesis quickly, without committing months of work to an unverified bet. A high-effort, uncertain-value use case can still be worth keeping on the list, but it should wait for stronger evidence before it gets a team’s time.
This comparison exercise has another benefit: it forces you to state each idea in one precise sentence — who, what problem, how often — rather than a vague direction like “apply AI to agriculture” or “an assistant for students.” An idea that doesn’t survive this rewording is probably not mature enough to build yet.
Where to look for a real use case in Morocco
The best starting point isn’t a list of tools, but a sector where a concrete problem keeps coming up: health, agriculture, energy, education, financial services. Each sector has its own constraints — data access, regulation, seasonality — which strongly shape what’s actually feasible.
Morocco’s support ecosystem gives a useful signal of this diversity: the EIC has, to date, supported 175 projects across all sectors. That sectoral spread isn’t a coincidence: a solid AI use case is rarely found by copying a neighbor’s idea, but by digging into a problem specific to ground you already know, as a project owner, student or researcher.
For a student or researcher, the most reliable ground is often the one already explored through academic work, an internship or a final-year project: the data is more accessible there, the problem is already partly documented, and a supervisor or field partner can confirm whether the pain point is real. Starting from familiar ground sharply reduces the risk of building a use case that looks relevant on paper but meets no real user.
Test before you build
The best test of an AI use case doesn’t require a model at all. Process ten cases by hand, following exactly the logic the system would later automate. This exercise, sometimes called a “Wizard of Oz” test, reveals in a few hours what no technical spec can show: the real variability of cases, the frequent exceptions, and whether the problem truly deserves to be automated.
This step follows the same logic of validating before building already detailed in our method for testing market need before developing. The principle is identical: talking to ten affected people costs a day; building a system nobody needs costs several months.
Checklist before launching an AI project
Before committing development time, check every point:
- The problem is described by a concrete person, not by a general trend
- Three different people confirm they experience this problem regularly
- The necessary data already exists, or its collection is planned and realistic
- A success metric is defined before the first prototype
- The manual test (no model) has been run on at least ten cases
- Someone is identified to supervise the results after launch
- A simpler alternative to an AI model was considered and ruled out for a specific reason
If even one point has no answer, that’s not necessarily a dead end — but it’s a sign there’s still work to do before coding.
Conclusion
A good AI use case isn’t recognized by how sophisticated the model is, but by the clarity of the problem it solves, the availability of the data, and the presence of someone to supervise the results over time. For a student, researcher or project owner in Morocco, this upfront selection discipline often matters more than an extra month of development.
