I Built an Offline AI for Cassava Farmers on a 2015 MacBook Air, and Lost Because I Asked One Question Too Late

My score was 3 out of 10.

It was not for speed. My little AI model was answering at about 18 tokens per second on a 2015 MacBook Air, faster than the judges' own target of 15. It was not for effort either. The reviewers described my experimentation as strong and unusually rigorous.

I got 3 out of 10 for originality, and that one number ended my run in the Africa Deep Tech Challenge 2026 before the technical judging even started.

This is the story of how a full stack web developer with zero machine learning experience built an offline AI advisor for cassava farmers in about two months. I will explain, in plain English, what I learned about quantization, RAG and fine tuning along the way. And I will show you the one mistake that cost me, so it never costs you.

If you build software, enter hackathons, run a startup or take on client projects, keep reading. The lesson at the end could save you months.

The email I almost ignored

I first saw the Africa Deep Tech Challenge in the Ebonyi State 3MTT group, and I scrolled right past it. I am a full stack software engineer. I build websites and web apps with Next.js, React, Node.js and PostgreSQL. This challenge was about machine learning, and machine learning was not my world.

Then a second email came about the same challenge. This time I opened the official challenge page, read everything and went through the FAQs.

The idea behind it caught me. They called it The Laptop LLM Challenge. Builders had to make a useful AI run completely offline on the kind of laptop Africans already own: 8 GB of RAM, no graphics card, no internet and no monthly API bills. Their reference machine was an ordinary Core i5 or Ryzen 5 laptop that sells for about $150 to $250 refurbished.

I have always dreamed of building technology that solves African problems. Here was a challenge built around exactly that. Building for Africa, with the hardware Africa actually has.

There was also the money. The grand prize was $8,000. Money was not my main reason, but I won't lie to you, it gave me that extra ginger. I could already see myself winning it and putting it into turning whatever I built into a real product.

I was also scared. This was applied machine learning, not the software engineering I do every day. But earlier in 2026, I had learned Next.js with the help of AI and built my first full stack notes app that way. So I made a decision. I would use AI as my teacher and learn machine learning by building something real with it.

Why a web developer picked cassava

Before I wrote a single line of code, I sat down with Claude, the AI assistant I use for most of my learning, and asked hard questions. How complex is this? Can I realistically finish it? Which track should I choose? I did not want to start something I could not finish.

The challenge had seven tracks: Math and Scientific Reasoning, Healthcare, Agriculture, Creative Writing, Coding Assistants, Corporate, and Autonomous AI Agents. Before I became a software engineer, I was a copywriter, and I have done a lot of academic writing. Creative Writing looked like the natural choice.
After talking it through, Agriculture made more sense. I live in an area full of farmers, and I knew real people I could talk to. A tool for farmers could be tested by the very people it was meant for.

So I went looking for experts.

A Ghanaian PhD student at Ebonyi State University worships in my church. I remembered him speaking in the children's ministry department and telling us about his research: how farmers can grow far more food on small plots of land with very little money. When this challenge showed up, he was the first person I thought of.

He had travelled to the Umudike area, home of Michael Okpara University of Agriculture, for his field research. So one of the elders in my church introduced me to his wife, an agricultural officer with the ministry of agriculture in Abakaliki.

She gave me the advice that shaped everything: pick one crop. She belongs to an international WhatsApp group of agriculture professionals. Farmers growing cocoa, maize, pepper, groundnut and rice keep coming into that group with photos of sick plants, asking experts to name the pest or disease and tell them what to do. The need was real. It just needed focus.

I chose cassava. Nigeria is the world's largest producer of cassava, at around 59 million tonnes a year in FAO's data. Yet our average yield has stayed at roughly 10 tonnes per hectare or less, while the improved varieties in IITA's variety guide are rated at up to about 40 tonnes per hectare. That gap is where good advice can change a farmer's life.

Later, I also spoke with a production manager at a cassava processing company in Edo State. Their biggest headache was weeds, and their two goals were more yield and more starch. Three conversations, and I understood the problem better than any document could have taught me.

Learning machine learning by building it

My method was simple. Claude explained a concept, I applied it to my project the same day, I tested it, and I came back with questions when something broke. Words that used to sound like magic became easy. Let me explain the main ones the way I wish someone had explained them to me.

A language model is a very large file of numbers. Those numbers are called weights, and they hold everything the model learned during training. When you ask it a question, it uses those numbers to predict the next piece of a word, then the next, then the next. Each piece is called a token.

The model I ended up using was Llama 3.2 1B Instruct, a small open model from Meta. The "1B" means it has about one billion weights. That sounds huge, but in the AI world it is tiny.

Quantization is how you make a model small enough for a cheap laptop. Think about prices in the market. Instead of writing ₦1,249.37, the trader just says ₦1,250. You lose a tiny bit of precision, but it is easier to carry around and quicker to work with. Quantization does the same thing to a model's billion numbers. At full size, my model was about 2.5 GB. After quantization, it was about 800 MB.

GGUF is the file format these shrunk models are saved in. llama.cpp is the free, open source program that runs them on an ordinary computer, no graphics card needed.

Then there was a strange name I kept seeing everywhere: Q4_K_M. For a while I thought it was a type of fine tuning. It is not. It is a quantization level, and the name reads like this:

• Q4 means each number is stored in roughly 4 bits instead of 16.
• K is the "K quant" method built into llama.cpp.
• M means medium. It keeps the most sensitive parts of the model at higher precision, so the quality does not fall apart.

I tested three levels on my own laptop: Q3_K_L, Q4_K_M and Q8_0. Q4_K_M was the fastest of the three. Even Q3_K_L, which is smaller, ran slower at about 11 tokens per second. Smaller is not always faster, and you only find that out by measuring.

My final setup produced about 18 tokens per second and used about 1.4 GB of memory at its peak, on a 2015 MacBook Air with 8 GB of RAM. That is faster than you can read. For heavier jobs my old laptop could not handle, I used Kaggle, which gives anyone free access to cloud GPUs right inside the browser.

Bigger is not always smarter

I did not just pick a model and hope. I tested four of them against the same questions.

Qwen 2.5 1.5B looked smarter at first. Its answers sounded confident and detailed. Then it started recommending fungicides that were nowhere in my source documents. For a farmer, a confident wrong answer about chemicals is worse than no answer at all.

Llama 3.2 3B, the bigger brother, followed my safety rules better than any other model I tried. But its reasoning was no better, and it took about two minutes to answer one question on my laptop. No farmer is waiting two minutes for an answer.

SmolLM2 1.7B kept echoing my instructions back to me instead of answering the question.

In the end, the smallest serious contender won: Llama 3.2 1B. An engineer looks before he leaps. You measure, you compare, and you let the results decide, not your excitement.

RAG, or giving the AI an open book exam

RAG stands for Retrieval Augmented Generation. This project was the first time I truly understood it.

Imagine a student writing an exam. A normal exam tests what is inside the student's head. An open book exam hands the student the textbook and says: answer from the book. If the student sticks to the book, the answers stay accurate, even when their memory is weak.

RAG gives an AI model that open book. Before the model answers, my program searches a small library of trusted documents, pulls out the four most relevant passages, and hands them to the model with a strict instruction: answer from these facts only.

One honest correction to something I used to believe: RAG does not make a model faster. It actually adds reading time, because the model has to process those passages first. What RAG did for me was let a tiny model, which is fast by nature, give accurate answers it could never give from memory alone.

My library came from six trusted sources, including IITA's guides on cassava pests and diseases, the NAERLS guide on cassava production and processing, FAO's Save and Grow guide for cassava, and IITA's booklet of improved Nigerian varieties. I cut them into nearly 700 small chunks the computer could search.

The most surprising lesson of the whole project came from those chunks. The variety booklet listed yields like this: "Hope 40.1 tonnes per hectare, Obasanjo-2 38.7 t/ha". When I asked my system which variety gives the highest yield, that chunk ranked 71st. Seventy first! A list of names and numbers does not look like an answer to a search engine.

So I rewrote it as a full sentence: "The improved cassava variety that gives the highest yield is Hope, which produces 40.1 tonnes per hectare." It jumped straight into the top four.

Write your knowledge in the shape of the questions people will ask. This works for AI search, and it works for Google search too.

I also wanted farmers who think in Igbo to be understood. Instead of training a new language model, I built a vocabulary bridge. Igbo words and everyday farmer words are mapped to the technical words in the guides. So akwụkwọ, the Igbo word for leaf, points the search to the right chunks, even when a farmer types it without the accent marks.

The day my AI prescribed fungicide for a virus

One test answer still gives me chills. I asked about cassava mosaic disease, and the model produced a neat numbered list recommending copper and chlorothalonil fungicides.

Here is the problem. Cassava mosaic disease is caused by viruses, which spread through whiteflies and through infected stem cuttings. Fungicides kill fungi. They do nothing to a virus. A farmer who followed that advice would waste money on chemicals and still lose the crop. Worse, none of the four passages the model was given mentioned any chemical at all. It made them up.

This matters because the stakes are real. IITA estimates that cassava mosaic disease and cassava brown streak disease together cause more than US$1 billion in damage across Africa every year.

I tried to stop it with instructions in the prompt. I tested that many times, and it does not hold. A small model can obey a rule and break it in the same answer. So I moved the safety check out of the prompt and into code. My program now reads every line of the answer. If a line names a chemical that does not appear in the source documents, the line is deleted and replaced with a clear note: a recommendation was removed because it is not in the guides.

When I finally reached the PhD researcher from my church, he reviewed the whole system and sent me twenty written recommendations from his years in the field. He has worked with IITA and met more than 400 farmers across Nigeria and Ghana, many of whom could barely write their names. One idea I implemented straight away. Every diagnosis now follows four headings: Most likely problem. Why. What to check. What to do. His other ideas, like voice input for farmers who cannot read English, became my roadmap.

Reading the scoring formula like an engineer

The organisers published their scoring formula for everyone to see:

S total = 0.50 × S acc + 0.30 × S perf + 0.20 × S eff − P thermal

In plain English:

• Accuracy (50%): how good the model's answers are, judged by benchmarks and by the judges' own questions.
• Speed (30%): tokens per second, compared against a reference of 15.
• Memory efficiency (20%): how little RAM the model uses out of a 7 GB budget. Less is better.
• Thermal penalty (minus 10 points): when a laptop's processor gets too hot, it slows itself down to protect itself. That is called thermal throttling. If it happened, or the core temperature went above 85°C, you lost 10 points.

When I sat down and did the maths, I found something important. The speed score was capped. Anything at 15 tokens per second or above earned the full 100. I was already at 18. Every extra hour I could have spent making my model faster would have earned me exactly zero points. My memory score was already about 80 out of 100.

That is the first engineering lesson of this story: read the formula, then do the maths before you spend your time.

The second lesson is bigger. It is the one that cost me.

The question I asked too late

Here is what confused me. The official Devpost page described the contest as optimising across the full stack, and it listed RAG over local document collections right there beside fine tuning and quantization. So I built a RAG system, and a careful one.

In the live Q&A sessions leading up to the deadline, people kept asking the same question. What exactly are we submitting? The model alone, or the model plus the system around it? The answers never felt straightforward. From the questions in those sessions, I was clearly not the only one confused.

After the last live session, I wrote a detailed message in the Discord channel and tagged the organisers. A staff member replied on August 21, four days before the deadline. The model would be tested as if it ran offline with no access to any other data. The judges' hidden questions would go straight to the bare model file.

That meant my retrieval system, my nearly 700 chunks, my Igbo bridge and my safety filter would not be part of the test. The parts I considered most original were invisible to the scoring.

Four days.

A proper fine tune changes the model's weights by training it on your own examples. Done well, that usually takes thousands of good question and answer pairs. In the time I had, I wrote 206. I trained a small fine tune (a method called LoRA) on Kaggle's free T4 GPU. The training took 104 seconds and looked successful on paper.

Then I tested it, and my heart sank. In one answer, it said the Hope variety yields 40 tonnes per hectare, then 34 tonnes. It answered a weed question with disease content and invented a crop called "flue grass". Worst of all, when I asked it about goats, a question it should have politely refused, it made up a vaccination schedule. Those 206 examples taught it my writing style, not my facts, and they trained its safety refusal right out of it.

So I took a different route. Every model file carries a chat template, a small set of instructions that wraps every conversation before the model sees it. I wrote a compact cassava knowledge digest, about 2,200 characters, and placed it inside that template. Now even the bare model reads my cheat sheet every single time.

The difference was clear. Without the digest, the stock model called cassava mosaic disease "a serious fungal disease" and suggested copper and sulfur fungicides. With it, the model named the right diseases and pests and pointed to real improved varieties. In one early version I forgot to list the real varieties, and the model invented one called "Kiko". It does not exist. Lesson learned.

My internet was so slow that uploading the 800 MB model from my laptop was projected to take about 20 hours. So I built the final model inside Kaggle and pushed it to Hugging Face from there, in seconds. If you are building in Nigeria, that trick alone could save you a day.

I submitted on August 24 with my video, my report and my numbers: a speed score of 100 and an efficiency score of 79.8. I was proud of what I had built.

3 out of 10

I did not make the 20 semifinalists. My originality score was 3 out of 10, below the threshold, so my project never reached the technical scoring at all.

The reviewers' reason was fair. My shipped model was a stock Llama 3.2 1B with a knowledge digest in its template. The weights, the actual learned numbers, were unchanged. They praised the experimentation and noted the fine tune I had trained, tested and rejected. But the file they were judging was not itself original.

For context, 1,862 people registered for the challenge on Devpost, and 223 projects made it into the submission gallery.

A few weeks later, I read a post by Daniel Nwaneri, a fellow FUTO graduate. He built StacksNG, an offline coding assistant grounded in the documentation of Nigerian payment APIs like Paystack and Flutterwave. He shipped a strong RAG system around an unchanged model, and he also scored 3 out of 10 for originality. Then he went further than I did. He cloned all 20 semifinalist repositories and read their reports. Every single one had modified the base model in some way, through fine tuning, distillation or merging models.

One more detail stood out to me. Six of the ten finalists built for agriculture. Choosing agriculture was the right call. I picked the right field and built the wrong deliverable.

Some people in the Discord group complained about the process. I understand the frustration, but I do not share it. Yes, the instructions could have been clearer. Still, the question was mine to ask at the start, and I asked it at the end. I strongly believe that if I had asked in week one, I would have built the right thing and at least made it past the first round.

How to avoid my mistake in your next hackathon

This is what I do now, and what I would tell you before you write a single line of code.

1. Find out exactly what will be tested. Not what the challenge is about. What will the judges actually run, on which file, with which inputs? I call this the scoring surface. Anything outside it does not count, no matter how good it is.
2. Ask in writing, in public, in week one. Post your question where the organisers answer, tag them, and save the reply. A written answer in the first week is worth more than a perfect answer in the last week.
3. Do the maths on the formula. Look for caps, thresholds and gates. My speed score was capped at 100, and the originality gate came before everything else.
4. Study what serious competitors and past winners are doing. If everyone strong is changing the model, ask yourself why before you decide not to.
5. Build the smallest thing that can be scored, first. Get a complete, valid submission ready early. Then improve it with the time you have left.
6. Test before you believe. The model that looked smartest in my first tests was the one inventing chemicals.
7. Talk to real users early. Three conversations with farming experts shaped my product more than any tutorial did. I wish I had had them in week one instead of halfway through.
8. Document your decisions honestly. My report recorded every rejected model and every failed experiment. It was the part the reviewers praised.
9. Finish what you start. Most people who registered never submitted. You learn the most from the things you finish.

This goes far beyond hackathons. In client work, the scoring surface is whatever the client will judge you on. Ask about it before you start building, not after you deliver.

Why I still count it as a win

I lost the prize. I did not lose.

Two months earlier, words like GGUF, quantization, LoRA and RAG were noise to me. Today I can explain them to you in plain English, and I have a working offline AI system to show for it: a public repository, a model on Hugging Face and a project page on Devpost. AI did not just help me build. It taught me a whole new field while I built, something that would have been close to impossible for me a few years ago.

Most of all, I learned to ask the hard questions at the start, while mistakes are still cheap to fix.

I believe there is always a way, because I believe that with God nothing is beyond us. With faith and the right tools, even the tallest mountain can be climbed.

I am already looking forward to the next challenge, whether it is a hackathon or a hard problem a company needs solved. If you have something difficult to build and you want a technical partner who is not afraid of unfamiliar territory, email me at hello@chukwumaukaha.com or send me a message on WhatsApp.

And if what you need right now is a fast website that ranks on Google and turns visitors into customers, see the client case studies on my website and what my clients say about working with me.