Straw2Cash: Turning Crop Residue into Income with AWS
Straw2Cash connects farmers with industrial buyers to turn crop residue into income, reduce stubble burning, and promote sustainable agriculture using AWS-powered technology.
Building Straw2Cash: Turning Crop Residue into Income with AWS
1. Introduction
Every year, after the paddy harvesting season, farmers face the challenge of managing large quantities of crop residue. In many regions, burning this residue is still a common practice because farmers often lack affordable alternatives for collecting, transporting, and selling it. This contributes to air pollution and wastes a resource that could otherwise generate income.
We built Straw2Cash, a crop-residue marketplace designed to connect farmers who have leftover paddy straw with buyers who can use it as raw material. These buyers may include biomass power plants, paper mills, brick kilns, and cattle-feed manufacturers.
Our goal is to make crop residue commercially useful by helping farmers find buyers, coordinating the people and equipment required for collection, and simplifying the process of turning agricultural waste into a marketable resource.
The project combines a multi-backend architecture with AWS services for conversational assistance, voice accessibility, data storage, and authorization. Each part of the system has a specific responsibility, allowing the team to develop different components independently while integrating them into one platform.
2. Understanding the Problem
Crop residue management is not simply a matter of telling farmers not to burn their fields. A practical alternative must address the economic and logistical difficulties farmers face.
The major problems we identified were:
- Limited access to buyers: Farmers may not know which nearby industries need crop residue or how to contact them.
- Collection and transportation difficulties: Even when a buyer exists, moving bulky straw from a field to a processing facility requires equipment, labour, and transportation.
- Uncertain pricing: Farmers need a way to understand the commercial value of their residue before committing to a sale.
- Fragmented coordination: Farmers, buyers, and baler operators need to coordinate quantities, collection schedules, and delivery arrangements.
- Accessibility barriers: A platform designed only around complex forms and English-language text can be difficult to use for people who prefer local languages or voice-based interactions.
These problems are interconnected. Finding a buyer is not enough if the farmer cannot arrange collection, and arranging collection is not useful if the transaction is commercially unviable.
Therefore, our approach focuses on connecting the marketplace with the operational steps needed to move crop residue from a farm to a buyer.
3. Our Solution: A Crop-Residue Marketplace
Straw2Cash brings farmers, baler operators, and industrial buyers into a common workflow.
3.1 Farmer listings
Farmers can provide information about the crop residue available for sale, such as the crop type, estimated quantity, and collection location. This information helps the platform represent available supply.
3.2 Buyer requirements
Industrial buyers can specify their requirements, including the type and quantity of residue they need. These requirements provide the basis for identifying suitable listings.
3.3 Matching supply with demand
The Go backend contains the core marketplace logic. It processes farmer listings and buyer requirements to identify potential matches based on relevant criteria.
The objective is to reduce the effort required for farmers and buyers to discover suitable trading opportunities.
3.4 Collection and logistics coordination
Once a potential match is identified, the process must account for baling equipment, transportation, collection timing, and delivery. Straw2Cash is designed to bring these operational requirements into the marketplace workflow rather than treating a buyer-seller match as the end of the process.
3.5 Accessible assistance
AWS conversational and voice services support a more accessible interaction model. Users can interact with an AI assistant and use speech-to-text and text-to-speech capabilities where appropriate, reducing reliance on typing alone.
3.6 Residue estimation and fire-related information
The project also includes a data-processing component for estimating residue quantities from inputs such as crop type and area. Fire-related information can help identify areas that may require attention.
Satellite fire detections should be treated as indicators of possible fire activity, not definitive proof that a particular field is burning crop residue. Such information is most useful when presented with its limitations clearly understood.
4. End-to-End System Workflow
The following diagram illustrates the main marketplace workflow.
plaintext
FARMER BUYER| |v v+-------------------+ +-------------------+| Create Straw | | Buyer || Listing | | Requirements || - Crop type | +-------------------+| - Quantity | || - Location | |+-------------------+ || |v |+-------------------+ || Straw2Cash | || Marketplace | |+-------------------+ || |+----------------------------------+|v+-------------------+| Go Backend || Matching Engine |+-------------------+|v+-------------------+| Identify || Potential Matches |+-------------------+|v+-------------------+| Coordinate || Collection and || Baling || Requirements |+-------------------+|v+-------------------+| Arrange || Transportation |+-------------------+|v+-------------------+| Delivery to || Buyer |+-------------------+|v+-------------------+| Commercial || Opportunity for || the Farmer |+-------------------+
This workflow shows how the platform connects information about available supply with industrial demand. The matching stage identifies potential opportunities; the logistics stage addresses the practical work required to fulfil them.
A match does not automatically guarantee a completed transaction. Actual fulfilment depends on factors such as availability, agreed terms, equipment, transportation, and successful delivery.
5. System Architecture
Straw2Cash uses separate backend services for different business responsibilities. Rather than forcing all functionality into a single application, we divided the system into Go, Java, and Python components.
The Go backend focuses on the core marketplace, the Java backend handles transaction-related and user-related responsibilities, and Python supports data processing.
5.1 High-level architecture
text
+----------------------+| Frontend || Marketplace UI || Accessible Interface |+----------+-----------+|+--------------+--------------+| |v v+-------------------+ +-------------------+| Go Backend | | Java Backend || | | || Straw Listings | | User Profiles || Buyer Requirements| | Pricing and Quotes|| Matching Logic | | Agreements || Marketplace Flow | | Settlement Records|+---------+---------+ | Impact Records || +---------+---------+v |+-------------------+ v| PostgreSQL | +-------------------+| Core Marketplace | | Amazon DynamoDB || Data | | Java-managed Data |+-------------------+ +-------------------++-------------------+| Python Processing || || Residue Estimation|| Data Processing || Related Analysis |+-------------------+AWS-BASED CAPABILITIES- Amazon Bedrock Agents- Amazon Transcribe- Amazon Polly- Cedar Authorization Policies- AWS Deployment Components
The diagram represents the major responsibilities of the system. The AWS services are integrated according to their specific roles; they are not a replacement for the Go and Java business logic.
5.2 Go backend: The core marketplace
The Go backend is responsible for the central marketplace workflow. Its responsibilities include managing straw listings, processing buyer requirements, and implementing the matching logic that connects supply with demand.
PostgreSQL stores the structured marketplace data used by this component. This makes it possible to query listings and requirements, apply matching criteria, and maintain relationships between marketplace records.
The Go backend is particularly important because it handles the main business problem the platform is intended to solve: helping available crop residue find suitable buyers.
5.3 Java backend: Transaction and user-related operations
The Java backend handles a separate set of responsibilities, including authentication-related functionality, user profiles, pricing information, agreements, settlement records, and impact records.
Amazon DynamoDB is used for data managed by this backend. This provides a separate persistence layer for these responsibilities rather than putting all application data into the same database.
The Java backend and its associated components are designed to run on AWS.
5.4 Python: Residue estimation and data processing
The Python component supports data-processing tasks related to agricultural residue. For example, an estimation process can use crop type and field area to calculate an approximate quantity of residue.
A simplified conceptual flow is:
text
Crop Type + Field Area|vData Processing|vResidue Estimation|vEstimated Quantity|vMarketplace Decision Support
An estimate is not a direct measurement of the actual amount available for collection. Its accuracy depends on the assumptions, input data, and estimation method used.
The purpose of this component is to make residue-related information more useful for marketplace decisions.
6. AWS Technologies and Their Roles
We used AWS technologies to address specific application needs, including conversational assistance, voice accessibility, persistent storage, and authorization.
6.1 Amazon Bedrock Agents: Conversational assistance
Amazon Bedrock Agents supports the AI-assistant functionality in Straw2Cash.
The intention is to let users ask questions about the platform in a more natural way rather than requiring them to navigate every feature manually. For example, a farmer might ask how to list available straw or what information is needed before arranging collection.
A conversational interaction can follow this general flow:
text
User Question|vApplication|vAmazon Bedrock Agent|vInterpret the Request|vGenerate an Appropriate Response|vReturn the Answer to the User
The agent provides a conversational interface; it does not automatically replace the application's business rules or database operations. Any action involving listings, agreements, or transactions still needs to be handled through the appropriate application logic and authorization checks.
6.2 Amazon Transcribe: Speech-to-text
Amazon Transcribe converts spoken language into text.
This capability is useful for users who may find typing difficult or prefer speaking in their usual manner. Instead of entering a query through a keyboard, a user can speak, and the application can process the resulting text.
A simplified workflow is:
text
User Speaks|vAmazon Transcribe|vRecognized Text|vApplication Processes the Query
Transcription and language support must be configured appropriately for the languages and speech patterns the application intends to support. The availability of speech recognition alone does not guarantee accurate recognition for every local language or dialect.
6.3 Amazon Polly: Text-to-speech
Amazon Polly converts text into spoken audio.
It complements Transcribe by supporting the response side of a voice-based interaction. After the application has generated a response, Polly can turn that response into audio so the user can listen instead of reading everything on the screen.
text
Application Response|vAmazon Polly|vGenerated Audio|vUser Listens
Together, Transcribe and Polly provide the building blocks for voice input and spoken responses. When combined with an AI assistant, these services can support a conversational experience that is more accessible to users who prefer voice interaction.
6.4 Amazon DynamoDB: Data storage
Amazon DynamoDB is used by the Java backend for data associated with user profiles and transaction-related operations, including authentication-related data, agreements, price quotes, settlements, and impact records.
The application separates this data from the core marketplace data maintained in PostgreSQL.
This separation reflects the division of responsibilities between the backends:
- PostgreSQL: Core marketplace records and structured relationships used by the Go backend.
- Amazon DynamoDB: Data managed by the Java backend for its user-related and transaction-related responsibilities.
Using two databases introduces additional design considerations. The team must clearly define which backend owns each record, how services exchange information, and how consistency is maintained when a workflow involves more than one component.
6.5 Cedar: Fine-grained authorization
Cedar is a policy language designed for expressing authorization rules. In Straw2Cash, it is used to define policies that control what different categories of users are allowed to do.
This is important because authentication and authorization solve different problems.
Authentication answers: Who is making the request?
Authorization answers: Is that user allowed to perform this action on this resource?
For example, a farmer, a baler operator, and an industrial buyer may all be authenticated users, but they should not automatically have the same permissions.
Cedar allows these permissions to be expressed as policies instead of scattering every role-based rule throughout the application code.
Example authorization scenarios
User role | Example action | Intended access |
|---|---|---|
Farmer | Create a straw listing | Allowed under the relevant policy |
Buyer | Submit a buyer requirement | Allowed under the relevant policy |
Baler operator | Access assigned collection work | Allowed under the relevant policy |
Farmer | Modify another farmer's private listing | Denied under the relevant policy |
Unauthorised user | Access a protected transaction | Denied |
These examples describe the intended authorization model. The actual result for a request depends on the policies, entities, resource attributes, and application context supplied to Cedar.
Cedar authorization workflow
text
Incoming Request|vAuthenticate the User|vIdentify User, Action,and Requested Resource|vBuild Authorization Context|vEvaluate Cedar Policies|v+---+---+| |v vAllow Deny| |v vExecute RejectAction Request
The application must enforce the authorization decision before executing a protected operation. Cedar evaluates the authorization question; the surrounding application remains responsible for authenticating requests, providing the correct context, and enforcing the result.
One lesson from working with Cedar was that it was relatively easy to start using and understand. However, more extensive documentation with larger, end-to-end code examples would make it easier to understand how policies, application code, and authorization context fit together in a complete system.
7. How the Components Work Together
Consider a farmer who has paddy straw available after harvesting and wants to sell it rather than burn it.
Step 1: The farmer provides listing information
The farmer enters the relevant details, such as the crop type, approximate quantity, and collection location.
The frontend sends the listing information to the Go backend, which manages the core marketplace workflow and stores the relevant records in PostgreSQL.
Step 2: The platform identifies potential buyers
An industrial buyer submits its requirements. The Go backend compares the available listings with those requirements and identifies potential matches.
The matching process can use relevant attributes such as residue type and quantity. Additional criteria can be incorporated according to the application's implemented business rules.
Step 3: The parties coordinate fulfilment
A suitable match creates an opportunity to arrange collection. The workflow must account for the equipment and transportation required to move the straw from the field to the buyer.
This is where marketplace matching connects with the practical logistics problem. The platform aims to reduce the coordination effort involved in arranging a sale and its fulfilment.
Step 4: Transaction-related information is managed
The Java backend manages its assigned responsibilities for user-related information, pricing, agreements, and settlement records, using DynamoDB for its associated data.
Where a workflow crosses backend boundaries, each service must respect its defined ownership of the data and communicate with the other components through the agreed integration mechanism.
Step 5: Users receive assistance when needed
A user who needs help navigating the platform can interact with the AI-assistant functionality. Amazon Bedrock Agents supports conversational assistance, while Amazon Transcribe and Amazon Polly provide speech-to-text and text-to-speech capabilities for voice interaction.
The user-facing experience should still make important commercial details, such as quantities, pricing, collection arrangements, and agreement terms, clear and understandable.
Step 6: Authorization is checked
Before a protected action is performed, the application identifies the user, requested action, and resource, and evaluates the applicable authorization policies through Cedar.
For example, a buyer should not gain permission to modify another user's private records simply because the buyer is signed in.
This example demonstrates how the marketplace, transaction services, AWS capabilities, and authorization model contribute to a common workflow without requiring every responsibility to live in one backend.
8. Security, Accessibility, and Responsible Design
Security and accessibility are important because the platform involves different user roles and potentially sensitive transaction information.
Role-based access and authorization
Different participants require different permissions. Farmers need to manage their own listings, buyers need to submit requirements, and baler operators need access to relevant collection work.
Cedar provides a way to express authorization policies explicitly. These policies must be designed and tested to ensure users can access only the operations and resources they are permitted to use.
Clear data ownership
The use of PostgreSQL and DynamoDB across separate backends requires clear ownership boundaries. A record should have a defined authoritative service, and changes that affect multiple components need an explicit coordination strategy.
This reduces the risk of conflicting data and makes the system easier to maintain as it grows.
Voice accessibility
Voice interaction can reduce the need for users to type long queries or navigate complicated screens. However, speech recognition and generated speech must be appropriate for the supported languages and intended audience.
The application should also provide a text-based alternative and make it possible for users to review important information before confirming a transaction.
Responsible use of fire-related data
Fire hotspot data can help identify areas of concern, but a detected hotspot does not necessarily establish that crop residue is being burned. Weather, other fires, sensor limitations, and the timing of satellite observations can affect interpretation.
Any fire-related information should be presented as a signal requiring context or verification, not as conclusive evidence about an individual farmer.
9. Challenges and Lessons Learned
9.1 Marketplace matching is only one part of the problem
Connecting a farmer to a buyer is valuable, but a successful marketplace also needs to account for collection, baling, transportation, and delivery.
Lesson: A real-world marketplace must consider the operational process required to fulfil a match, not only the matching algorithm.
9.2 Separate backends require clear boundaries
Dividing responsibilities between Go, Java, and Python allows the team to work on different parts of the system independently. However, it also introduces integration challenges.
Each service needs a clearly defined responsibility, data ownership model, and communication contract.
Lesson: Separating services is useful when the boundaries are meaningful. The complexity introduced by multiple services must be justified by their responsibilities.
9.3 Different databases serve different responsibilities
PostgreSQL and DynamoDB are used for separate parts of the application. This makes it important to avoid unclear ownership or unnecessary duplication of data.
Lesson: Database selection should follow the needs of the component and the shape of its data, while the overall system must still define how the components stay consistent.
9.4 AWS services should address specific needs
The project uses different AWS capabilities for different purposes: Bedrock Agents for conversational assistance, Transcribe for speech recognition, Polly for spoken responses, DynamoDB for Java-managed data, and Cedar for authorization policies.
Lesson: Cloud services are most useful when their responsibilities are clearly defined and connected to a real application requirement.
9.5 Authorization should be explicit
Authentication alone does not ensure that users can access only the resources they are permitted to use.
Lesson: Defining authorization policies explicitly helps make security decisions easier to reason about, test, and maintain.
9.6 Accessibility must be considered in the design
A platform aimed at agricultural communities should not assume that every user is comfortable with lengthy forms, English-language text, or keyboard-based interaction.
Lesson: Local-language support, voice interaction, and simple workflows should be considered part of the product's usability requirements, rather than added as an afterthought.
9.7 Technical functionality must connect to a practical outcome
The value of the platform depends on whether it helps users discover opportunities and coordinate the work needed to sell crop residue.
Lesson: A technically functional application is only part of the solution. The workflow must also be understandable, commercially meaningful, and practical for the people expected to use it.
10. Conclusion
Straw2Cash is our attempt to make crop residue a useful economic resource rather than a material that farmers struggle to dispose of after harvesting.
The project combines a Go-based marketplace and PostgreSQL data layer with a Java backend and Amazon DynamoDB, supported by Python-based data processing. AWS services provide conversational assistance, voice accessibility, and authorization capabilities through Amazon Bedrock Agents, Amazon Transcribe, Amazon Polly, and Cedar.
The central idea is straightforward: connect farmers who have crop residue with buyers who need it, while accounting for the collection and transportation work required to make the exchange possible.
Beyond the individual technologies, the project helped us think about the complete system: how services divide responsibilities, how data is owned and exchanged, how permissions are enforced, and how technical decisions relate to the needs of real users.
Our long-term vision is to help make crop residue commercially valuable and make selling it a more accessible alternative to burning it. By connecting agricultural supply with industrial demand and supporting the workflow around that exchange, Straw2Cash aims to contribute to a more practical and economically sustainable approach to crop-residue management.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article