AgTech: How House of Crops is Digitizing the Least Digital Industry

Guest post by Maximilian Commandeur, COO, House of Crops

Berlin-based House of Crops is an agtech startup that’s digitalizing the world’s most traditional industry: agriculture. Its digital trading platform is based on three pillars—the marketplace, logistics organization, and contract management—and among other innovative approaches, employs a machine learning-supported matching algorithm for evaluating potential trading partners and a predictive model for logistics price forecasting. The platform users – farmers, traders, cooperatives, and processing companies like flour mills and compound feed producers – interact via a dynamic negotiation engine which allows an efficient negotiation of over 50 contract parameters.

The idea for House of Crops originated from a casual summer-BBQ with friends four years ago. “My friends, mainly farmers and traders, were complaining about how increased administrative work was taking up a significant portion of their daily work,” says Max Wedel, my House of Crops Co-Founder and CEO, adding that 40 million tons of crops in Germany are still traded via phone every year.

As a computer scientist, Max saw an opportunity for technology to help the agri-trading business, and in 2018, he and I set out to further investigate the idea. Building on our experience in agile transformations in the financial industry, we began to methodically investigate our hypothesis that a neutral digital broker offers relevant benefits for the target group to be adopted into their everyday trading processes. Via multiple interviews and workshops, we gained an understanding of our customer’s needs, continuously developing our value proposition. The agricultural industry is known for its weak margins and constant price pressure. Consequently, market participants are often aiming at increasing the efficiency of their processes, improving their reach to find the right supplier/buyer for the product at hand and, of course, getting the best possible price. With this in mind, it was clear our digital marketplace would have to enable the user to reduce effort on its side, provide a liquid market with access to new trading partners, and offer the best possible price at the given time. After receiving positive feedback, we started forming strategic partnerships and built our first non-functional prototype in order to ensure a product-market-fit as well as market liquidity from the get go. In January 2019, we decided to officially launch the company; however, several essential questions remained. Which tech stack should we use? Which architecture was best suited to our needs? Which cloud provider should we opt for?

Finding the Optimal, Future-Oriented Architecture: Comfort Zone vs. What Your Business Needs

Initially, we screened possible product development and sourcing strategies while also comparing different cloud providers. We evaluated cloud providers based on three main factors: customer service, service offerings, and cost structure. At the end of the detailed evaluation process, we chose AWS as our preferred cloud provider. In addition to our previous positive experiences with the platform, it was easy to talk to AWS representatives who were responsible for and interested in early stage startups. Additionally, following a thorough search process for a development service provider, we opted for our current provider Tech Alchemy, a young UK company, who proposed building the application using the MEAN stack. Our initial architecture setup is depicted in Figure 1. It is a rather traditional setup with which the team has plenty of experience. However, with the unique opportunity to build our application from scratch, we re-evaluated whether the setup optimally served our business needs. Ultimately, our desire to iterate quickly, use an agile development approach, and adopt fast time-to-market goals, led us to aim for a more future-oriented, flexible, and responsive setup.

Figure 1: Initial (more traditional) Architecture Setup

Therefore, we set out to search for a solution that would better suit our needs. Not being experts in agricultural product trading, we needed to be able to ship features quickly, collect feedback from our partners, and then adjust, if necessary. Moreover, while we followed a lean Minimum Viable Product (MVP) approach, the application would be easily scalable for both an international expansion as well as the integration of additional value-added services. Of course, being an early stage, bootstrapped company, cost played an important role in our decision as well. This led us to evaluate the possibility of adopting a serverless architecture.

After talking to the AWS Startup Team during the AWS Summit in Berlin in February, we were quickly offered the opportunity to discuss our challenge with a solutions architect (SA). We were positively surprised about the engagement we received from AWS, even though we were, and are, a very early stage startup. In preparation for the meeting, we openly discussed our companies’ business goals and the concerns that each of our team members had regarding a serverless architecture. As a result, we provided Mat (“our” SA) and Marius (“our” Account Manager) with detailed information about the challenges, tech stack, and planned architecture.

In a one-hour architecture discussion, Mat and Marius were able to answer all of our questions and quickly identified possible ways to build on the teams’ expertise while ensuring a gradual evolution toward a serverless setup. As a follow-up, Mat quickly provided us with thorough and highly insightful material related to our questions and made additional suggestions to further support achieving our goals. After a couple of days of R&D, we were able to re-design our architecture (see Figure 2) in a way that sets us up for any future challenges while ensuring the team feels comfortable with it (we’d like to use this chance to say a big thank you to Mat and Marius). The focus was on using as many  serverless and fully managed services from AWS as possible, to reduce our operational exposure as far as possible. The only component that we have to manage directly now is the SonarQube installation on EC2. The public perimeter is based on CloudFront as a CDN, which serves as a host for AWS WAF and Shield services to protect our front door and give our customers a better, faster experience. This fronts a deployment of Amazon API gateway, and both of these services have certificates updated by AWS certificate manager. The API gateway uses Amazon Cognito for authentication, and then invokes a number of AWS Lambda functions to handle the business logic, talking to Amazon SNS, DocumentDB etc. For administration we use the fully managed Client VPN service.

Figure 2: Re-designed Architecture Setup after AWS Discussion

Overall, adapting the new technologies was not as tough as we initially thought. The experience taught us not to shy away from difficult decisions – i.e. traditional infrastructure vs. serverless – for short-term reasons. This is not to say that we did not run into any complications. The R&D took a bit longer than we expected, and in the first days of development, we had a steep learning curve. Additionally, we had some initial challenges with the technical setup of the new services. However, both the online documentation from AWS as well as the business technical support we received (which we accessed for free thanks to the AWS Activate program) enabled us to quickly resolve the issues. After starting development three months ago in the beginning of April, we have not run into any more issues in the last two months. This enables us to focus completely on creating new features, while decreasing the AWS infrastructure costs.

We scheduled an architecture review for July to make sure we continuously re-evaluate our setup and learn from our experiences. The team was overall contented with the architecture we have chosen and eagerly discussed potential improvements. As a result, we agreed on an approach to become (close to) fully serverless by integrating AWS Client VPN and only spinning up an EC2 instance for the time our static code analysis tool is running during build and deployment.

Up and Running: Exciting Times Ahead

Looking back at the past months, we have managed to successfully discuss challenging topics that address the foundation of our future application. By talking to AWS solution architects and opting for AWS services, we were able to objectively discuss the teams concerns and arrive at a cheap, reliable, and scalable infrastructure solution that allowed us to build on our previously acquired skills while setting the application up for future innovations.

At House of Crops, we believe in open communication and collaboration as the basis for constant progress.  We actively promote discussions with all market participants to understand their detailed requirements and identify possible benefits. If you are a farmer, trader or mill, an agtech company, or simply someone wanting to exchange ideas and experiences, feel free to contact us at founders@houseofcrops.de or visit our website www.houseofcrops.de.

We are hiring! If you are interested in joining the House of Crops Team, check out our open positions on our website or apply directly at hr@houseofcrops.de.