Haptly
Haptly was an agritech product that tried to help farmers monitor grass growth using drone and satellite imagery.
View original storyProduct snapshot
What it was
Haptly tried to estimate pasture dry matter for farmers using drone and satellite imagery.
Who it was for
Problem / value
Help farmers plan feed availability by measuring grass growth more accurately than visual estimates.
Core workflow
Collect imagery and farm data, estimate dry matter across paddocks, and help farmers plan feed budgets.
Core dependency
A technically reliable model using imagery, farm data, local conditions, and affordable data sources.
Product form
Pricing model
Revenue was not reached; the team received about $20,000 through an accelerator and used savings and side income while working on the business.
Competitors or alternatives
What happened
Summary
Haptly was a New Zealand agritech product for measuring grass growth with imagery.
Outcome
The company did not reach revenue and moved on after failing to solve the technical accuracy problem.
Core risk
Technical feasibility was not proven before startup effort scaled
Shutdown reason
The founder cited unresolved technical feasibility, data requirements, satellite data cost, uncertain R&D timeline, and limited founder attachment to the farming domain.
Demand signal
The source shows farmer interest, but demand could not become the deciding test because the team could not achieve the technical accuracy needed for the product.
Distribution issue
The issue was not primarily distribution: press, accelerator exposure, and farmer inquiries existed, but the technical model and data requirements blocked a reliable product.
Timeline
- started exploring drone use cases in late 2015
- focused on farmers and dry-matter measurement
- built an early React demo and gathered farmer feedback
- entered the Vodafone Xone accelerator in early 2016
- worked from January to October 2016
- shut down after the technical feasibility remained unresolved
Before you build
Why it matters
Customer interest is not enough when the product must outperform a messy real-world process with data, sensors, and accuracy constraints.
Primary check
Prove the hard sensing and accuracy requirement before joining accelerators, building business assets, or promising an agricultural automation product.
Checklist
- Can you prove the hard mechanism on one real customer workflow?
- Can you measure accuracy against known ground truth?
- Can the product work without expensive or rare sensor data?
- Can you stop before broader startup work if feasibility fails?
- What exact technical result must be true for the product to work?
- What minimum accuracy beats the current manual workflow?
- What ground-truth data is needed to test the model?
- What data, sensor, or field-operation cost breaks the business case?
Relevant if
- Your product depends on machine learning, computer vision, hardware, robotics, or physical-world data.
- Your users want the outcome but the technical path is uncertain.
- You are joining an accelerator or building business assets before feasibility is proven.
Less relevant if
- Your product is a straightforward software workflow with known technical implementation.
- You already have a working prototype that meets the required accuracy threshold.
Pre-build tests
- Run a narrow feasibility study on one farm with measured dry-matter ground truth.
- Build a throwaway model before creating the full product interface.
- Compare data-source costs against expected customer pricing.
Transferable lessons
- Identify the hardest technical assumption before general startup work.
- Use real ground-truth data for feasibility testing.
- Define the accuracy threshold needed to beat the current workflow.
- Price data, sensors, and field operations before promising automation.
If you build this today
Start with the smallest feasibility study: one farm, known ground-truth dry-matter measurements, required accuracy thresholds, and data-cost assumptions before broader startup work.