TeTani

Inspiration

A successful harvest can still become a loss.

When many farmers harvest at the same time, agricultural cooperatives may not have enough confirmed buyer demand or transport capacity. For perishable produce such as chili, discovering this imbalance on harvest day leaves very little time to respond.

The necessary information often already exists, but it is scattered across farmer estimates, buyer conversations, spreadsheets, and transport schedules.

We built TeTani to help cooperatives detect potential surplus before harvest and plan how available produce can be distributed.

Detect surplus early. Protect every harvest.

What it does

TeTani is an early-warning and distribution-planning platform for agricultural cooperatives.

It combines:

upcoming harvest plans;
buyer demand and accepted grades;
daily transport capacity;
optional weather context.

From this information, TeTani provides:

a seven-day surplus overview;
risk level and critical date;
plain-language risk explanations;
a feasible distribution plan;
temporary scenario comparison.

The operator can test changes such as adding buyer demand or increasing transport capacity without modifying the cooperative’s main data.

TeTani is not a marketplace and does not execute decisions automatically. It is an advisory system that supports cooperative operators before harvest day.

How we built it

TeTani was built as a modular Python application using Streamlit for the interface and SQLite for persistence.

The system separates:

user-interface components;
application services;
typed domain models;
repositories;
risk calculation;
allocation optimization;
weather integration.

Operational inputs are validated using Pydantic.

Charts are rendered using Apache ECharts through streamlit-echarts.

Explainable risk calculation

TeTani calculates surplus risk from five operational factors:

$$ R = 0.45G + 0.20H + 0.15C + 0.10W + 0.10U $$

Where:

(G) = supply–demand gap;
(H) = harvest concentration;
(C) = transport-capacity gap;
(W) = weather disruption;
(U) = uncertainty in harvest estimates.

The output includes a score, risk category, critical date, and explanation of the main contributing factors.

Constrained allocation

TeTani uses linear programming through SciPy HiGHS to allocate harvest batches to buyer demand.

The allocation must respect:

available harvest quantity;
accepted quality grade;
harvest date;
buyer deadline;
daily transport capacity;
buyer priority;
distance.

If the main optimizer fails, the system can use a deterministic fallback plan instead of presenting an invalid result as optimal.

Challenges

Defining a realistic scope

Food loss has many causes. Instead of trying to solve the entire agricultural supply chain, we focused on one decision window:

What can a cooperative do during the seven days before harvest when expected supply exceeds demand or transport capacity?

Designing for non-technical users

Risk formulas and optimization can be difficult to understand. The interface therefore focuses on simple operational questions:

What is happening?
Why is it a problem?
Which date needs attention?
What can the operator try next?

Safe scenario testing

Temporary scenarios must not accidentally change actual records. Scenario inputs are isolated from the cooperative’s primary data.

Limited development time

TeTani was developed during a hackathon. The current prototype is approximately 80% complete, and some workflows still require full end-to-end testing.

What we learned

We learned that explainability can be more valuable than using a more complex black-box model.

Because we did not have validated historical cooperative data, we chose deterministic risk scoring and constrained optimization instead of training a machine-learning model on synthetic labels.

We also learned that cooperatives are a practical starting point because they already coordinate farmers, buyers, and logistics.

Current accomplishments

The prototype currently includes:

bilingual Indonesian and English interface;
Demo and Empty workspaces;
harvest-plan management;
buyer and demand management;
transport-capacity management;
seven-day Surplus Radar;
explainable risk calculation;
constrained allocation planning;
scenario comparison;
responsive ECharts visualizations;
local SQLite persistence;
typed validation and automated testing structure.

What is next

The immediate next steps are:

Complete final end-to-end testing.
Resolve remaining UI and edge-case issues.
Deploy the public application.
Validate the workflow with one real cooperative.
Compare predicted and actual harvest, buyer fulfillment, transport usage, and unallocated produce.