Registration opens on 1 September 2026 and will close on 18 September 2026
Texpo STEAMON 26 focus is on Tertiary Level Students, with a theme centered on solving challenge for small scale farmers. To be held from 5 to 9 October 2026 Texpo SteamOn 26 is a collaboration between Technopreneurship Development Centre (TDC) and Telco, it is to be hosted at Harare Institute of Technology Innovation Hub
Students from tertiary institutions across Zimbabwe will develop industry-relevant solutions while benefiting from expert mentorship, collaboration, and national exposure.
Hackathon Theme: MOVE! FARM TO MARKET
Your Mission
Somewhere in rural Zimbabwe, a farmer named Temba Moyo is standing in a field of avocados, groundnuts, and small grains that regional buyers want and can't get, because no one can trust what happened between his soil and their truck.
Your mission, should you choose to accept it, is to give Temba proof. A working, offline-capable system, built on physical hardware, that captures what happens on his farm the moment it happens, and turns it into evidence a real certification scheme or buyer could actually use.
You will have four days on the ground once selected. Before that, your team has one task: show us you understand the standard you're building against well enough to design the record it needs, and convince us your hardware plan can actually produce it.
Hackathon Challenge
Design a low-cost, offline-first Farm-Level Data Capture and Aggregation System that helps farmers like Temba build an evidence trail a real certification scheme or buyer assurance programme can use.
The system should allow smallholder farmers, or a farmer group, to:
- Capture where produce was grown and how it was handled (inputs, water source, harvest date) directly in the field, without relying on a connection at the moment of capture.
- Timestamp and structure that data so a record can't be silently backdated or altered after the fact.
- Combine handling records from multiple farms into one traceable batch, with a clear record of which farm contributed what.
- Sync captured data to the cloud in a single low-bandwidth batch once connectivity is available, rather than requiring a live connection.
This is deliberately scoped to the layer that is genuinely underserved: farm-level provenance and practice data. Government customs documentation (certificates of origin) and most existing digital traceability platforms already operate at other layers of this problem; your application must show you know this and are designing something that feeds evidence into an existing scheme rather than duplicating it.
Here is a real and active certification/assurance scheme to design against- GLOBALG.A.P. (Option 2 group certification / Primary Farm Assurance
All three share the same underlying shape, which is why the comparison is fair: registration and identity data, input and handling records, an internal audit or control function, and batch or volume traceability. Your schema and hardware plan need to map to that scheme's actual record requirements, not a generic idea of what traceability should look like.
Baseline requirement (mandatory): your schema and prototype plan must capture input/handling records and batch aggregation records, reliably, offline, end to end.
Stretch goal (bonus, not required to pass): registration/identity capture, and structure for the internal audit or control function your chosen scheme requires.
Technical Constraints
- Use Raspberry Pi 4 / Raspberry Pi 5, Raspberry Pi Pico, and affordable sensors.
- Keep the system simple, durable, and farmer-friendly — assume a semi-literate field user operating it, not an office administrator.
- The system must support secure, low-bandwidth cloud integration with collaboration and data-sharing tools in the Google Ecosystem.
- Selected teams will be given a starter boilerplate at the start of the build: a working skeleton for offline data queuing and batched Google Sheets/Drive sync. Building this plumbing from scratch is not required and not rewarded during the build — the time is better spent on data integrity and audit-readiness.
Step 1: Registration and Application
Registration is open to all teams affiliated with a tertiary institution of education (university, polytechnic, or equivalent). Registration and Application must be completed before 18 September 2026.
Your application is what the pre-selection panel scores to decide who is admitted to the Hackathon. It has four parts, and all four are mandatory. A strong schema and video with no research or business case behind them will not be enough to be selected.
Application deadline: Friday 18 September 2026. Notification of selection: Monday 21 September 2026.
Notes for completing Application Form
Data Schema (share link to attachment)
A written schema (one row per field: field name, data type, which requirement of your chosen scheme it maps to, and how it will be captured), covering at minimum the input/handling and batch aggregation record types required by your chosen scheme. If a field is your own addition beyond what the scheme requires, say so and why.
Research & Differentiation
A short written note identifying at least two existing traceability, certification, or aggregation solutions relevant to your chosen crop or region, and stating specifically what those solutions do not provide a farmer like Temba. A general claim that “no one else has built this” will not be accepted — name the platforms and be specific about the gap.
Market Validation & Farmer Adoption
Who pays for the system, what tangible benefit a farmer receives in the first season (not only eventually), and why a resource-constrained smallholder would take on the extra effort of using it.
Pitch Video (share link to attachment- maximum 3 minutes)
A short video, in the style of a pitch, that sells your solution to us as the panel deciding who gets a shot at building it. In the time you have, it must cover:
- Which of the three schemes you chose, and one concrete, specific reason at least one of the other two was the wrong fit for your chosen crop or context.
- The reasoning behind your schema design, not just what it contains. Pick one or two non-obvious fields and explain why you structured, typed, or scoped them the way you did, simply restating the schema on camera will not score well.
- The reasoning behind your hardware choices, not just a components list. Explain why a specific sensor or capture method was chosen for a specific field, including any trade-off you considered and rejected (e.g. a simpler option that wouldn't have worked offline).
This must demonstrate genuine understanding of your own design decisions, not a description of what you want to build. A team that can only describe their schema and hardware, without explaining the reasoning behind them, will not score well on this part
Click here for Hackathon Registration