Building AgriSense: My Final Year Project for Smarter Crop Decisions in Sri Lanka

Agriculture depends on decisions that have to be made long before you know the final result. You choose a crop, prepare the land, spend money, and wait months to see how things turn out.

For my final year Software Engineering project, I wanted to build something around that problem.

The result is AgriSense.

AgriSense is a mobile application that helps you choose suitable crops and estimate crop yield using location, seasonal weather, and soil information. I built the project around Sri Lankan agricultural data, so the system works with local districts and crops instead of using a generic global setup.

Where the idea came from

The main question behind AgriSense was fairly simple.

If you know where a farm is located, the growing season, the soil conditions, and the weather for that area, can a machine learning model use that information to give you a useful crop recommendation or yield estimate?

That question turned into two main features.

The first recommends crops for the conditions you provide. The second predicts the expected yield of a crop you select.

I also wanted the application to feel practical on a phone. A farmer shouldn't have to understand machine learning or manually look up every environmental value before using it.

Building the dataset

The dataset became one of the biggest parts of the project.

The final dataset contains 30,603 records with 42 crops across 25 Sri Lankan districts. It covers data from 2001 through 2025.

Each record contains information about the crop and growing season along with environmental values used by the model.

Weather information includes rainfall, temperature, humidity, rainy days, dry spells, and solar radiation. I collected and processed the weather data using NASA POWER.

Location information includes latitude, longitude, elevation, and an agro ecological zone.

Soil information includes pH, nitrogen, organic carbon, and the percentage of clay, sand, and silt.

Preparing this data took a lot of work because the model needs consistent inputs. A value calculated one way during training needs to be calculated the same way when someone uses the finished application.

That became especially important when I started connecting live APIs to the mobile app.

Training the yield prediction model

I tested the prepared dataset with machine learning models and eventually selected an Extra Trees Regressor for the final system.

I trained the model using data from 2001 through 2022. Data from 2023 through 2025 was kept for testing.

The final model produced an R² score of 0.6867 on the test data. Its mean absolute error was about 2,009 kilograms per hectare.

Those results aren't perfect, and I don't think an agricultural prediction system should pretend they are. Local farming conditions can change in ways a dataset doesn't capture.

The model gives you an estimate based on the information available to it.

Turning the model into an API

A trained model sitting in a Python file isn't very useful to a farmer.

I built a FastAPI backend around the model so other applications can send agricultural inputs and receive predictions.

The API supports two main machine learning operations.

The yield prediction endpoint accepts a selected crop and its environmental conditions, then returns the estimated yield.

The crop recommendation endpoint evaluates supported crops and returns the top recommendations based on predicted yield.

I kept the machine learning code on the server. This means the mobile application doesn't need to bundle the trained Python model.

Making the app easier to use

The model has a lot of inputs. Asking someone to manually enter every value would make the app frustrating.

I started reducing that work by using the selected district.

AgriSense supports 25 districts. When you select a district, the backend can provide its representative latitude, longitude, elevation, and agro ecological zone.

Weather needed a little more thought.

The machine learning model was trained using seasonal weather data from NASA POWER. I needed the production API to calculate weather features the same way they were calculated during dataset preparation.

When you select a district, season, and year, the backend retrieves the relevant NASA POWER data and converts it into the weather features expected by the model.

These include total rainfall, mean rainfall, rainy days, heavy rain days, and the longest dry spell. The model also receives temperature, humidity, and solar radiation values.

For completed seasons, the system can use observed historical weather.

A future or incomplete season doesn't have a full season of observed weather yet. In that situation, the backend can estimate the required seasonal values using historical data from previous completed seasons. The application tells you when those values are estimated.

You can still edit the automatically filled values before submitting the form.

Soil data stays in your hands

I chose to keep soil information as manual input.

You enter values such as soil pH, nitrogen, organic carbon, and soil composition.

This keeps the source of the soil measurements clear. Soil conditions can vary within the same district, so using one district level soil value for every farm could give the model a misleading picture.

Designing the mobile workflow

The mobile application is built with React Native and Expo.

My early version placed a large number of inputs on one screen. It worked, but it wasn't pleasant to use.

I later changed the prediction process into a multi step form.

You start with your location and season. The app then loads the environmental information. After that, you enter the soil values and choose your crop. A review screen lets you check the information before sending the prediction.

Crop recommendation follows a similar process with fewer steps because you don't need to choose a crop first.

This made a big difference to the mobile experience. You deal with one part of the form at a time, and you can go back without losing the values you've already entered.

Keeping useful data available offline

Internet access can't be assumed all the time, especially when you're designing software that may be used outside cities.

AgriSense keeps prediction and recommendation history on the device.

When you run a prediction, the request and result can be saved locally. You can open that saved result later without asking the machine learning API to calculate it again.

New predictions still need the backend because the machine learning model runs on the server. The app doesn't pretend otherwise.

The local history gives you something useful when the connection disappears.

Adding farmer accounts

I also added farmer registration and login to the mobile application.

Account information uses a hosted MySQL database through a server side authentication API.

The mobile app never connects directly to MySQL. Database credentials stay on the server, while the application communicates with the authentication API.

I kept this separate from the existing local storage workflow. Your saved local prediction history doesn't suddenly depend on the hosted database just because authentication was added.

That separation was important because I didn't want an account feature to remove the offline behavior I had already built.

What I learned while building AgriSense

AgriSense taught me that building the machine learning model is only part of an ML based application.

A model can produce a prediction in a notebook, but the real application has to collect the same type of input the model saw during training.

Weather was a good example. Using any weather API and passing its values into the model would have been easy. It could also have created a mismatch between training and real use.

I had to go back to the dataset preparation process, inspect how each weather feature was calculated, and reproduce that logic in the backend.

The mobile side created a different challenge. A technically correct form can still be difficult to use. Breaking the inputs into steps and automatically filling values that the system already knows made the app much easier to understand.

Where AgriSense can go next

There's still plenty of room to improve the project.

One area I'd like to explore further is farm specific soil information. Better access to reliable local soil measurements could reduce how much data you need to enter manually.

The prediction model can also improve as more verified agricultural data becomes available. More recent records and better farm level observations could help the model represent local conditions more accurately.

I also want to keep improving how the application explains its predictions. Showing an estimated number is useful. Helping you understand what influenced that estimate can make the result easier to judge.

Final thoughts

AgriSense started as a final year project, but building it pushed me through much more than model training.

I had to prepare real datasets, build a prediction service, connect external environmental data, and turn the whole system into a mobile application that someone can actually use.

There were plenty of points where the easy implementation wasn't the right implementation. Weather processing was one of them. Offline behavior was another.

That's what made the project valuable to me.

You can build a model that works in a notebook fairly quickly. Turning that model into a complete application forces you to think about where every input comes from and what happens when a service fails.

AgriSense gave me the chance to work through those problems from the dataset all the way to the mobile app.