StrawLink: fifteen seconds to hear a farmer
How we built a serverless planner on AWS that gets straw off Punjab's fields before farmers have to burn it: the problem, the fourteen-service stack, and what fought back when we tried to answer a farmer's voice note within fifteen seconds.
Student | Aspiring SWE | MERN Stack | DSA | Machine Learning | Building Real-World Projects
Built by Shambhvi Sharma and Yash Aggarwal for WeMakeDevs × AWS Environmental Hacks. Live: https://main.d16side0ke5w9y.amplifyapp.com · Code: https://github.com/strawlink-1/strawlink
The problem
For a few weeks every autumn, the sky over north India turns grey. Part of that haze begins as a decision made in a single field.
A farmer in Punjab harvests his rice in October and has about three weeks to sow wheat. The field is covered in straw, and the straw is in the way. Machines that can clear it exist, but they are few, and nobody can tell him when one will reach him. When the window is closing and no machine has come, a match is the only tool left.
We measured what that adds up to on one block of 200 fields near Sangrur. In the 2025 season, satellite images show 185 of them burned, most within two days of harvest. Those fields hold about 1,450 tonnes of straw. Burned, that is up to 9.5 tonnes of PM2.5, particles fine enough to travel deep into the lungs, released over the villages and schools that happen to be downwind that afternoon. And this is one small block among many.
Nobody in that story wants to burn. Stubble burning is usually treated as a behaviour problem; we think it is a logistics problem with a deadline. So we built StrawLink to act before the harvest: it forecasts each field from satellite images, plans a machine for it every morning, and tells the farmer when, on WhatsApp, in Punjabi.
Demo
Watch it in three minutes:
The stack
StrawLink runs on fourteen AWS services and not one server. The whole system is a single AWS SAM template that AWS CloudFormation turns into one stack in the Mumbai region, with a separate least-privilege IAM role for every function. Two people could not have run this any other way.
It remembers. Forecasts from our satellite pipeline land in Amazon S3, and an S3 event wakes an AWS Lambda function that loads them into Amazon DynamoDB. Six on-demand tables hold every field, plan and message, so there was no capacity to guess and every screen reads live state.
It plans. Amazon EventBridge Scheduler wakes the planner at 06:00 India time, set in the schedule itself, with no UTC arithmetic. The planner is a Lambda function on Graviton running Google OR-Tools, and Amazon Location Service gives each machine a route along real village roads. Between plans, nothing runs and nothing is billed.
It listens and answers. Messages arrive through Amazon API Gateway. Amazon Transcribe understands Punjabi, which is what makes a voice channel for these farmers possible at all. Amazon Bedrock with Amazon Nova Pro works out what a message means and writes the reply in Punjabi, and because we used its Converse API, the model is a single parameter in our template. A farmer assistant built with Strands Agents, AWS’s open-source agent SDK, answers questions using only the current plan.
It shows its work. The 3D simulator is served by AWS Amplify Hosting. Credentials are encrypted in AWS Systems Manager Parameter Store with AWS KMS, never in the repository, and Amazon CloudWatch keeps the logs and metrics that let us prove what happened.
That is the tidy version. Two parts of it did not come quietly.
What fought back
1. A voice note has fifteen seconds
Farmers send voice notes, not text, but a WhatsApp webhook must be answered within fifteen seconds, and transcribing a note, understanding it and re-planning 200 fields takes longer. The fix was four lines: the API function verifies the message, hands it to a second Lambda function with an asynchronous invoke (
InvocationType=Event ) and answers at once. The worker gives Amazon Transcribe three language options, Punjabi, Hindi and English, lets it decide which one it is hearing, and has Bedrock turn the sentence into a date for the planner.On my own phone it then heard my “aaj” (today) as “aa”, found no date, and treated my harvest as a question. The cure was a sentence, not code: we told the model that the text may be a transcript with small mistakes, and that a farmer who is harvesting and names no day means today. Every reply also starts with what was heard, so a wrong transcript is visible to the farmer instead of becoming a wrong plan.
2. 201 MB, and no Docker
The planner’s OR-Tools package is 201 MB unzipped against Lambda’s 250 MB limit, and the usual way to build native Python dependencies is a container, which my Windows laptop could not run. We did not need one: pip fetched Linux arm64 wheels directly (
--platform manylinux2014_aarch64 --only-binary=:all: ), and AWS CloudFormation packaged and deployed the SAM template from the AWS CLI. The planner runs on a 3 GB Graviton function and plans the whole block in about 23 seconds, and the day before submission the stack handled about 750 invocations with zero errors.What I take away
Both problems looked like walls and turned out to be doors: one flag on an invoke, one flag on pip. That is what let two people ship a forecast, a planner, a voice channel and a simulator in four days.
Straw that is picked up in time is never burned.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article