Environmental Hacks: StrawLink
An AWS-powered planner that gets straw off Punjab's paddy fields before farmers have to burn it: satellite forecast, a machine plan every morning, and a WhatsApp message to the farmer.
Student | ML | Software Developer
Built by Shambhvi Sharma(@shambhvi2006) and Yash Aggarwal(@yash4428).
Our Vision:
What if every farmer knew, before he harvested, exactly when a machine would come for his straw?
Every October, a farmer in Punjab harvests rice and has about three weeks to sow wheat. The straw is in the way, the machines that can clear it are few, and nobody can tell him when one will come. So he burns it, and the smoke becomes the air of every village and city downwind.
StrawLink is a planning engine that anticipates that moment. It knows which fields will be ready, plans a machine for each one every morning, and tells the farmer exactly when, on WhatsApp, in Punjabi. We built it as a working prototype for 200 fields near Sangrur.
Why this matters?
Stubble burning is usually treated as a behaviour problem. We think it is a logistics problem with a deadline. When we replayed the 2025 season on this block, satellite images showed 185 of the 200 fields burned, most of them within two days of harvest. A plan that starts after the harvest is already too late, so StrawLink starts before it.
How We Built This?
StrawLink is fully serverless on AWS, in the Mumbai region. There is not one server to patch, and between plans nothing runs at all.
1.One template, deployed as code
The whole system is a single AWS SAM template that AWS CloudFormation turns into one stack: five Lambda functions, six tables, an API, a bucket and a schedule. SAM’s policy templates give every function its own IAM role with only the permissions it needs; the WhatsApp worker, for example, is the only function allowed to call Amazon Transcribe. All five functions run on Graviton (arm64). Our optimiser package is 201 MB, close to Lambda’s 250 MB limit, and we shipped it with the AWS CLI alone by cross-building Linux wheels, with no Docker.
2.Data: S3 and DynamoDB
Forecasts from our Sentinel-2 satellite pipeline land in Amazon S3. An S3 event notification triggers an AWS Lambda loader, which writes them into Amazon DynamoDB. Six on-demand tables hold fields, plans, events, messages, machines and certificates, with a global secondary index to find a field’s certificates. On-demand capacity meant no sizing decisions: the tables simply absorb whatever the planner and the app ask of them. Clearance certificates are PDFs stored in S3 and handed out through presigned URLs.
3.Planning: EventBridge, Lambda and Amazon Location Service
Amazon EventBridge Scheduler wakes the planner every day at 06:00, with the schedule’s time zone set to Asia/Kolkata so there is no UTC arithmetic. The planner is a 3 GB Lambda function running Google OR-Tools. It first reads the rain for each village from a weather service, with nobody entering anything, then assigns balers, trucks and seeders to the fields dry enough to work, in about 23 seconds for the whole block. The same function answers every “what if” from the simulator in about five seconds, invoked directly by the API. Amazon Location Service then computes each machine’s route along real village roads.
4.The farmer’s channel: API Gateway, Transcribe and Bedrock
A WhatsApp message reaches an Amazon API Gateway HTTP API. Messaging webhooks must answer within 15 seconds, so the API Lambda verifies the signature and passes the message to a second Lambda function with an asynchronous invoke, then returns at once.
That worker sends voice notes to Amazon Transcribe. We give it three language options, Punjabi, Hindi and English, and it identifies which one the farmer spoke and returns the text; the recording is deleted as soon as it is transcribed. Amazon Bedrock does the understanding. Through the Converse API, Amazon Nova Pro reads what the farmer means, turns “I harvested today” into a date the planner can use, and translates every reply into Punjabi. Because we used the Converse API, the model is a single template parameter. One rule protects the farmer: every date, time and field number must survive translation exactly, or a hand-written Punjabi message is sent instead.
For questions, a farmer assistant built with Strands Agents, AWS’s open-source agent SDK, has tools that read the current plan, so it can say when a machine will come but can never invent a time.
5.The web app and operations: Amplify, Systems Manager and CloudWatch
The React and three.js web app is served by AWS Amplify Hosting: a 3D map of the block where every slider calls the real planner. Twilio credentials and phone numbers are SecureString parameters in AWS Systems Manager Parameter Store, encrypted with AWS KMS and never in the repository. Amazon CloudWatch holds the logs and metrics, and gave us the number we are proudest of: about 750 Lambda invocations the day before submission, with zero errors.
Demo
Watch it in three minutes:
What We Learned?
With the same information, our planner only matched first-come booking in the 2025 replay (75 against 74 of 185 fields). That told us where the value is: not in cleverer routing, but in knowing early. So StrawLink writes to the farmer before the harvest, and listens to his voice.
Serverless is what let a team of two build all of this in four days. Fourteen AWS services, one template, nothing to manage.
Straw that is picked up in time is never burned.
StrawLink is not a fire detector. It is the plan that makes the fire unnecessary.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article