From Idea to Working Farm Scoring Tool Using PostGIS, Sentinel Hub and Open-Meteo
This started as a simple experiment: could I build an AgriTech SaaS MVP using satellite data, NDVI analysis, weather APIs and geospatial tooling to score agricultural parcels?
Not a pitch deck.
Not a theoretical “startup idea”.
An actual working vertical slice.
And surprisingly, it now does something real:
- stores field geometry
- imports land parcels
- pulls satellite vegetation signals
- fetches weather data
- calculates parcel risk scores
- returns recommendations through an API
It is still an MVP.
But it is a real product slice.
And that makes it worth unpacking.
Why Build an AgriTech SaaS at All?
Because agriculture sits at the intersection of several interesting forces:
- climate pressure
- food systems
- geospatial data
- finance and risk
- increasingly accessible satellite infrastructure
And because a lot of “AgriTech” products are either:
- too hardware-heavy
- too enterprise-heavy
- or too vague
I wanted to explore something software-native.
A small digital asset.
A possible micro SaaS.
A geospatial product with a path to becoming more.
Very much a basein.dev kind of experiment.
The Startup Idea
The initial hypothesis was simple:
Can open data be used to make a quick parcel-level scoring engine?
At minimum, answer:
Is something likely growing on this field right now?
Longer term:
Can this evolve into:
- risk scoring
- monitoring
- compliance
- maybe even financial infrastructure
That became the seed.
MVP Architecture
The stack is intentionally boring.
Boring stacks scale.
Core stack
- PostgreSQL + PostGIS
for parcel geometry storage - Python
for ingestion and scoring - PHP API
for endpoints and product surface - Docker Compose
for one-command startup
Data Inputs
Current MVP uses:
1. Satellite Data (Sentinel Hub)
Used for NDVI analysis.
NDVI:
Normalized Difference Vegetation Index
Simple idea:
Higher value
→ healthier vegetation
Lower value
→ weak or absent growth
That alone gives surprisingly useful signal.
2. Weather Data (Open-Meteo)
Using:
- temperature
- rain
- daily observations
Weather becomes a second scoring factor.
3. Parcel Geometry
Stored in PostGIS polygons.
Originally entered manually.
Later imported automatically.
That changed everything.
From Fake Data to Real Data
This matters.
The project did not start with real satellite integrations.
It started with fake data.
And that was correct.
First:
prove pipeline
Field
→ ingest
→ score
→ API response
Only after that:
replace synthetic data with real sources.
This sequence saves massive time.
Many MVPs do the opposite.
And die.
The First Scoring Model
Very simple:
score =
0.6 * ndvi +
0.4 * weather_factor
Risk buckets:
- low
- medium
- high
Simple?
Yes.
Useful?
Enough for MVP validation.
And importantly:
explainable.
Not black-box AI theater.
Why the Score Alone Is Not the Product
This became obvious fast.
A score is just a number.
Users do not want:
“0.48”
They want:
Why?
What changed?
What should I do?
So recommendations were added.
Example outputs:
- weak vegetation signal detected
- verify crop presence
- monitor parcel within 72 hours
That turned a metric into a product.
Huge difference.
The Ukraine Problem (And Why Estonia Happened)
The first instinct was Ukraine.
Logical.
But public registry access is constrained.
That route was not practical for this MVP.
Rather than forcing a dead end: pivot.
AI suggested Estonia.
That turned out unexpectedly useful.
Estonian Parcel Import
This became a breakthrough.
Using public cadastral data:
enter cadastral number
import parcel geometry automatically
No manual polygon drawing.
That changed demoability overnight.
Flow became:
Parcel ID
→ Import parcel
→ Fetch data
→ Score field
Now it looked like a product.
Not a dev toy.
Current MVP Can Do This
Today it can:
- import real parcel geometry
- fetch NDVI from satellite data
- fetch weather from Open-Meteo
- calculate parcel score
- generate recommendations
- expose results via API
- display it through map UI
That is already a meaningful vertical slice.
What This Could Become
This is where startup logic matters.
Raw parcel scoring alone?
Probably weak.
But as infrastructure layer?
Interesting.
Possible directions:
1. Farm Monitoring SaaS
Recurring monitoring.
Historical trends.
Alerts.
Subscriptions.
2. Agri Risk Scoring API
Banks.
Insurers.
Input suppliers.
Much more interesting buyer category.
Personally I find this one strongest.
3. Compliance / Traceability Layer
Especially under growing EU pressure.
Potentially much larger than “farm app” territory.
4. Carbon / ESG Data Layer
Possibly later.
But only after strong data foundation.
Not as starting point.
What I Would Not Build
Probably not:
- drone startup
- agri hardware
- IoT sensor business
- robotics
- heavy field operations
Too much capital.
Too much operational gravity.
For a small digital asset thesis:
software wins.
Lessons from Building This MVP
1. Start With a Vertical Slice
Not platform vision.
One useful loop.
2. Fake Data First
Counterintuitive.
Correct.
3. Explainability Beats AI Buzzwords
Especially in early products.
4. Data Near Money Is More Valuable
Farmer dashboards are nice.
Financial risk tools may be better businesses.
5. Country-Agnostic Architecture Matters
Ukraine blocked one route.
Estonia opened another.
Architecture survived.
That matters.
Why This Fits the basein.dev Thesis
This project fits something I keep coming back to:
small digital assets.
Buildable online products.
Micro tools.
Micro SaaS.
Systems you can launch, test, automate, maybe scale.
Without needing venture money to breathe.
This was not:
“let’s start an AgriTech company”
It was:
“What happens if I build one slice?”
Much better question.
Is There Real Business Potential?
Maybe.
But not where many people think.
Not in “farm app”.
Possibly in:
- scoring infrastructure
- geospatial APIs
- compliance tooling
- risk layers
Closer to money.
Closer to pain.
Closer to budgets.
That is where products survive.
Tech Stack Recap
For people who came here via search:
Stack used:
- PostGIS
- Docker
- Python
- PHP
- Sentinel Hub API
- Open-Meteo API
Concepts used:
- AgriTech SaaS
- Satellite Data
- NDVI + API
- Parcel Scoring
- Geospatial MVP
If you searched for:
- how to build an agritech startup
- farm monitoring software MVP
- NDVI API project
- satellite data SaaS
- agritech micro SaaS ideas
…this is exactly what this was.
What I’d Build Next
If continuing:
Priority order:
- automatic re-scoring after import
- parcel metadata model
- duplicate-safe parcel import
- score history
- multi-country parcel providers
- risk scoring for finance use cases
That feels like the real next layer.
Final Thought
Funny enough, this whole experiment began because AI casually suggested:
“Maybe build an agri startup.”
I treated it as a challenge.
And challenges sometimes turn into products.
And maybe, if a long-term dream of owning a tiny vineyard ever happens…
thinking about agriculture through software today may not be the worst detour.
Question
Would you push this toward:
- Agri risk scoring API
- Monitoring SaaS
- Compliance product
- Or pivot completely?
Curious what you’d build.