Editor's Note: Brad Koch is Co-founder & CTO at FarmLogs. Chris Schneider is Software Engineer at FarmLogs.
FarmLogs, the software helping to make fields more profitable for farmers, is now estimated to be used by 20% of US row crop farms. FarmLogs lets you know how much it rained last night in specific areas of your fields, gives you interactive maps to keep track of your fields, allows you to upload geospatial data, and soon will be able to automatically track and upload your tractor's activity. Their end goal is to be able to give farmers insights into their farm and its activity in a way that's never been done before. Being able to let farmers know exact coordinates for where it's most beneficial to plant crops on their fields and sending automatic notifications based on changes in farm activity and conditions are just some of the things they've got planned.
But FarmLogs didn't start out with a next-gen farm management system. In the latest tech stack interview, we find out how FarmLogs went from a basic bookeeping app to a full-on farm management suite using PHP, Clojure, Heroku, AWS, and more. This interview also marks the launch of The Official StackShare Podcast, click below to hear the full audio of the interview!
- Background & MVP
- Maps, Mobile, and Data
- Backend & Infrastructure
- Front-End
- Build & Deploy Workflow
- What's Next
In the beginning, it was just this basic CRUD app that basically let you create your fields, create your activities, and not much else. The front-end was built using Backbone.js... and the backend was written in CakePHP. It was a really simple, light-weight way for us to get the CRUD portion of it off the ground initially. Long-term, not the same story, but initially that's where we started.
Everything else was stuck in the 90's. It's all these nasty windows form desktop software that still give them some utility, so they used it... They were making do with what they had, but there's plenty of room for improvement, and so they were just eager to start coming in when we built something better.
[Maps] came along shortly after our second iteration. We had done a little bit of design overhaul, and helped make the mapping aspect kind of a central feature allowing them to start punching in their fields and drawing shapes on the map. It was initially done through a very poor implementation of Google Maps... Then, we started using Mapbox and Leaflet as well.
Leaflet was a huge, huge bump in feature capability... it had better, just layers that we could draw on top of the map with crop colors and also showing where rainfall had occurred... They had better color correction and stuff like that so once you zoomed down, they just looked a lot prettier than what Google Maps had, and I think they were slightly more updated.
So when we started, we had this CakePHP CRUD app that was very, very straightforward, very simple. The issue that we started hitting as we started growing a little bit was that we were having a lot of difficulty testing things. It was very, very unreliable in terms of what the PHP app was doing making sure it performed consistently, and when we started to try to write unit test, that turned out to be very difficult. And so, we started looking around at other options...
So one day I was just looking around, and I finally decided to start digging into some Clojure just simply because a lot of people around us had talked a lot about LISP and had been really big fans of it.. And so, I went in and tried it out and was able to recreate the CRUD portion of the app in less than a week. It was really, really, quick and easy to do. And not only that, the biggest part of it was that it enabled us to test it very, very easily. All the unit testing functionality in Clojure made it more so of a joy to write unit tests than anything else, which was really, really surprising because usually that's the boring part.
Yonas: Do you want to just start off with a little bit of background on yourselves? Just introduce yourselves.
Brad: Sure. I'm Brad. I'm the co-founder and CTO here at FarmLogs. Jesse and I worked together since junior high school, and after college we decided to start FarmLogs together.
Chris: I'm Chris Schneider. I'm the technical front-end lead for FarmLogs. I've known Brad and Jesse since my second and third year in college. I worked for them a couple of years prior to starting FarmLogs and joined them shortly after graduation.
Yonas: Can you talk a little bit about how FarmLogs started?
Brad: Sure. I mentioned that Jesse and I had been working together since junior high school. We had been building websites for this one class that we got to take that year, and we realized, "Hey, we can build these websites for school and win these competitions with these. Why don't we just go build websites for money?" So, that's what we did. We started consulting. That was something we did throughout college, doing consulting jobs, making a little bit of money off of it. But, we realized that after we graduated that we needed something a little bigger to be able to support us afterwards. And, we knew that the software for farmers problem existed. We had at that time been building software for a grain elevator, and then all these farmers started asking us, "Hey, when can we start using it? When can we start using it?" And so we realized that the farmers themselves had this big unsolved problem that they needed someone to build software and come along and help fill in that gap. We applied to Y Combinator with the idea for FarmLogs, got in, and built the company up from there.
Y: Can you talk a little bit about what that first product was?
B: Yeah, sure. Originally, when we applied to YC, we didn't have much of anything in terms of a product. It was just this really drag-and-drop, black-and-white interface, dragging this tractor out on this field, things like that. It didn't really do a whole lot. YC let us in anyways. We had shown a lot of potential with a lot of the other stuff we were doing. That's when we really started building it up.
In the beginning, it was just this basic CRUD app that basically let you create your fields, create your activities, and not much else. The front-end was built using Backbone.js, which was pretty popular at the time, and we had a pretty kind of heavy single page web app, and the backend was written in CakePHP. It was a really simple, light-weight way for us to get the CRUD portion of it off the ground initially. Long-term, not the same story, but initially that's where we started.
Y: Okay, so the idea for that first iteration was really you guys wanted to help farmers just keep track of their books?
B: Yeah, absolutely. They've got these big record books they keep. They just go and sit on the shelf, and we wanted to bring all that data and put it into a computer so they can look back and analyze it.
Y: At the time were they using anything else, or was it literally pen and paper?
B: Everything else was stuck in the 90's. It's all these nasty windows form desktop software that still give them some utility, so they used it. Farmers are actually quite early adopters of technology. They've got a lot of different stuff going on with their operation, and they'll use anything that helps them be more efficient. They’re very business-minded like that. They were making do with what they had, but there's plenty of room for improvement, and so they were just eager to start coming in when we built something better.
Y: Where was this hosted?
B: This was hosted on Heroku. In YC, we got Heroku discounts, and so I went ahead and set all that up to start using them, and it was very easy to just git push and deploy onto Heroku, and for that to run there. They also had their Heroku Postgres service. You just clicked a button and spun up a Postgres instance, and so that's where we stored all of our data as well, in Heroku Postgres databases.
Y: Again, back to the primary use case here, were people using this on the desktop?
B: They had been using other software on the desktop. Yes, we were able to build a web application that they could use on their desktops, then after we had built the initial early beta versions of FarmLogs, they were starting to use that to record their data.
Y: What did the next version of the product look like or what did you guys start adding in that you found out farmers needed along with the basic record keeping?
B: Kind of that first year was exploring along those lines of sticking with some of the basic data logging, data creation stuff. A lot of stuff happening in the mean time, raising a seed round, Chris graduated college and joined the team during that time. It was the spring after YC a year later, in spring of 2013 when we started building out this rainfall feature. The National Weather Service has rainfall data available for how much rain occurred across the United States. I think it's something on a four-kilometer grid, and we were able to tell the farmers how much rain they got on their field after it happens. You wake up in the morning, what we are able to do was send you an email and say, "Hey, last night while you were asleep, you got half an inch of rain on these fields." That gives the farmers a lot of very valuable information because the weather is the one thing they can't control, and they like being all over that. In addition, it lets you get an idea of where your wettest spots are going to be so that when go out scouting in the morning, you know which place is most likely to be dry and ready for you to work.
Y: I assume they were already getting this data somehow, right? Was it that you just made it "push" where you'd say, "All right, we'll keep you updated and send you that email," and bring it into one place, or what were they using at that time?
B: Yeah, yeah. They use a lot of the technical stuff like, I don't know, The Weather Channel, maybe Acuweather, things like that to go and check, and those would tell them like this forecast, and things like that, and obviously they’re farmers. They're looking outside and say, "Yeah, it did rain last night," things like that. They know that that's going on. What's a little bit unique about us is that we were able to put a number in front of them. This is how much rain you got, and that's something that isn't typically provided elsewhere. That was a little bit unique to what we were offering them. We were pushing to them that morning what exactly they had gotten on that field last night.
Y: You were basically taking the rainfall data and then some geospatial data that you got from them. How did you mix the two? What were you using on the geospatial side?
B: A lot of different stuff on that side of things. A couple sides to that, right? We had the rainfall data we were getting in from the National Weather Service, and that came in as a shapefile that we went and loaded into PostGIS to build this database of what the rainfall picture looked like overnight for the United States. That was one step of it, but the other step was getting the farmer’s location too. Typically we got that when they logged in, when they signed up for FarmLogs. You could just go geo-code their IP to figure out roughly where they are. To get a little bit better picture of it, we'd ask them for their address, and then we'd go and geo-code that address. And then we'd have their location to go off of from that. In addition to, by that point, we were having them map out their fields. They would go into FarmLogs and draw out their field on a map, and so we knew based on the position there what the latitude, longitude coordinates of their field were, and so we could do this look up to go and find where exactly this rainfall data occurred.
Y: So at this point, they've got the record keeping, they've got the weather, at least the rainfall, right, about what happened. Was there any forecasting in there or was it purely based on what had happened already?
B: Yeah, no forecasting. We let the weather companies do the forecasting business. Maybe someday, but we're not going to get ourselves stuck in that mess about being the most accurate forecast. We just want to provide them data about what happened.
Y: Can you talk a little bit about the maps aspect of this? Because that was pretty big, right? Wehn did that come along?
C: That came along shortly after our second iteration. We had done a little bit of design overhaul, and helped make the mapping aspect kind of a central feature allowing them to start punching in their fields and drawing shapes on the map. It was initially done through a very poor implementation of Google Maps. But then, we were able to make some more hires and bring people in who had some map knowledge. Then, we started using Mapbox and Leaflet as well. Leaflet was a huge, huge bump in feature capability because it had Leaflet.draw with better drawing tools. It also had better, just layers that we could draw on top of the map with crop colors and also showing where rainfall had occurred.
Y: So can you describe what the maps were being used for? A farmer would log in, and then they'd see a map of their actual field, right?
C: Yeah, yeah. Once they had gone and drawn it out, you could zoom out, you could see where all your fields are as well as what crops they had currently planted on them for that year.
It was kind of a crude version. It wasn't as customizable as we'd like. Being able to display colors on the map once we had color-coded a lot of the commodities like corn, soy beans, and things like that, you really get a better visual distinction of what your farm looks like.
Y: So then Mapbox came along and just had better layers.
C: Oh yeah. Their tile layers were much more beautiful. They had better color correction and stuff like that so once you zoomed down, they just looked a lot prettier than what Google Maps had, and I think they were slightly more updated. I'm not exactly sure what source they were pulling it in from, but back when they first started it, they were still way, way better looking than Google Maps.
Y: Now, you're still using Mapbox but with Leaflet.
C: Yes, absolutely.
Y: Cool. So the product is now getting to be this full suite. You've got record books, you've got the weather, and then now you’ve got maps that are sort of bringing those two things together or rather bring some of this stuff together. What came after that?
C: We started developing for mobile after that. We had a very simple mobile app that we had done or tried to implement with web technologies. It was kind of a flop and also difficult to maintain and debug.
B: Yeah, once upon a time back in the day when I was the only engineer, I went ahead and tried building a web-based app for the phones, and that kind of failed spectacularly. I'm not super, super skilled on the frontend stuff to begin with, and so we tried doing it. It just wasn't working out. It turned out to be very very difficult to architect a web app well on a mobile environment. We tried a lot of crossover stuff like Trigger.io, things like that. What we realized was to get decent performance out of it, get a decent feel to the app, it was going to be pretty much impossible to do with some of the html5-based mobile apps, and we realized that we were going to need to do some native development to be able to do a better job at that.
Y: It's not like that was mainly because of the maps...
C: Maps was a big part of it. It was simply just the CRUD forms align them to do the record keeping, but we did want a lot of feature parity on mobile, so we brought in an iOS engineer. He started developing, and then one of our original front-end guys, he moved to Android and led up that team with I think one other intern. They eventually started running in parallel, and they just built feature after feature, and now we have full support for maps, and we're doing a lot of pulling down of data and showing those on the mobile app. You're really getting a lot similar experience as you get on the web on the mobile devices now.
Y: Mobile was a big step though for you guys, because at that point farmers were still tied to their desktop pretty much right?
C: Yeah, it pretty much seemed that way just because that's all they had available so we were getting into this new realm of allowing them to just pull their devices out of their pocket and be able to even just see rainfall on their fields, in their pocket was pretty big for them.
Y: For the mobile side of things, you saw that most folks were using phones or was it also tablets? What did you see mostly?
C: Everybody's got a cellphone out. They're all smartphones so nobody has just a tablet that they're carrying around all the time. We haven't found the need to build for tablets specifically, but we are starting to see a lot of people asking for it.
B: Tablets has been growing a lot in share, but like Chris mentioned, smartphones were the single most ubiquitous device... I mean, everybody had one. They all wanted to be able to use apps on their phone to help them out with their farming operations. Tablets are important. They're growing in importance, but they came in second after smartphones.
Y: You guys actually targeted Android first, right?
C: Eh, I would say that iOS was actually a bit faster in adoption, but we did see a lot of need for Android as well, and we try to keep them both pretty much in sync with what features are available on mobile.
Y: Ok. I guess that takes us to now, right? Right now, you guys have... is there any other functionality you want to talk about before we dive in to some of the other aspects like data?
C: Sure. We start pulling in a lot of data from other sources. We kind of hit this pivot point where we realized we didn't just want to be the place for the farmers to enter information. We also want to be the place where they can get information from us. So, we started pulling in some SSURGO soil data that the government had done. They did a huge survey across the nation a while back.
We also allowed them to upload shapefiles of their fields that gave us the ability to upload their fields and draw them for them instead of them having to do it themselves.
Y: Ah, okay, yeah. Let's talk about that because there's a bunch of different data sources, since everyone was using something different, so one of them was the government, USDA right?
B: Yeah, yeah. There's a lot of different government data sources I mentioned, The National Weather Services being one. The USDA also has a lot of data available too. They had the soil information that we were able to load from them containing a survey of all the soil across the US.
There’s also third-party services too. We're able to go to some third parties to get some market data. We're also able to go to some third parties now and get some satellite data. That’s one of the new data streams we’re working on integrating.
So you had the government as one source, some third party private sources, and also we've been always been, from the beginning, collecting data directly from the farmers, and we're starting to get a little bit more into that as well where we're collecting not only data they enter manually, but also collecting data based on what their smartphone is doing, based on what's going on with their tractors. We’re able to collect data off of the bus on the tractor and directly upload it into our system where instead of carrying around a USB stick from their field computers, they’re able to just have it show up in their FarmLogs based on what they're doing on the field.
Additionally, just with the smartphone, we’re able to grab GPS location to be able to tell when you're on your field and be able to automatically tell you, "Hey, you were out in your field today. Looks like you decided to go out and plant that field there."
Y: You're collecting information from their mobile devices, and then you mentioned tractors as well. How are you collecting data from tractors?
B: Yeah, tractors are actually highly networked. There are sensors on them that continuously feed in, just like your car, as to what exactly is going on on your tractor. The most important part that we care about is that your implements, so for example the planter, it's telling you what rate you’re seeding at. So, we’re able to record how many seeds per acre you started dropping at this point, and we're able to use that data later on to tell you a little bit more about how you performed in terms of yield, and where you might be able to make adjustments to do better next year.
Y: Oh, so the tractors are already collecting this data?
B: It's already on the tractors, yup, but then it goes on their field computer in the cab, and it's on this USB stick that they have to get out of there, and then figure out what the heck they'd do with that USB stick, right? We are able to just directly take it from the tractor and present it back to them in a nice, easy to use way.
Y: How do you do that? How do you take it from the tractor?
B: This is one of the things that's still in development right now, but what we have is a device that we're able to put into the tractor to be able to broadcast that data out of the tractor and be able to upload it straight to FarmLogs. That data about their planting rates, about their yield that comes in, and we’re able to go and present that back to them in FarmLogs.
Y: So previously, they'd go to the tractor, and I guess they'd take the data out of the actual tractor somehow?
B: There's like a flash memory card in there, USB, windows came around, you pulled that out and then you put in some other software, I mentioned some nasty desktop software that was able to get some stuff with it, maybe hand it over to their agronomist. Their agronomist would do something with it and give it back to them, things like that. But, what they use it for is it does enable them to see a yield map. These are the spots where you got the most yield out of your field. You are able to take that information, and especially with us with having compiled all these other data sources of rainfall, on soil, all of this other information that we're collecting, we're able to aggregate that and do more in-depth analysis than they've been able to do before about what exactly is causing negative performance in various sections of their field, and what they can do to improve it.
Y: Ah, yeah. That's really cool because it sounds like what's happening is now they're getting all of the... they had these pieces, right? They had the record keeping, they had rainfall, they had some of these things in isolation, but now they can do it all in one place and get a better view of how they're actually doing. So that's really cool.
B: Exactly. We're bringing together all the data about farmers' fields, and putting it together in one place so that they can use it to farm their fields more profitably.
Y: Can you talk a little bit about some of the other data sources? What sorts of things were you seeing farmers give you in terms of data that they had?
B: Oh sure. They tried giving us a lot of different stuff. One of the big pain points for them was creating the fields, and a lot of them had shapefiles already indicating the boundaries of all their fields. And so, one source that we created was an uploader to import your shapefiles to be able to automatically create your fields for you. When we created that, they started giving us other stuff. They'd send us in stuff like PDFs of drawings of their fields. They'd send us in weird pictures. They'd send us in yield data as well. After they started sending all this yield data, we realized, "Hey, we should just maybe support yield uploading too," so we did that. A lot of different types of data the farmers decided to start uploading once we exposed that uploader capability to them.
Y: Google Earth was in there?
B: Yup, yup. There were some KML files. Some of them had previously drawn out their fields in Google Earth, and that resulted in these KML files that they were able to upload to import their field boundaries.
Y: And you guys are just throwing all these files in S3, or how do you guys...
C: Yes, we store all those in an S3 bucket. When the farmers either want to upload shapefiles, even images if they're taking notes, we do store those in S3, and we interface that with Filepicker.io. For doing file uploads, it's just a really nice SDK. I think they have native SDK's so we use those on all three of the clients to move files into S3.
Y: Maybe we can talk a little bit about the actual stack. In the beginning you were pretty much just using PHP, right? CakePHP with Backbone, and then what does it look like now? At least the web presence.
B: There's a pretty long journey along the way. So when we started, we had this CakePHP CRUD app that was very, very straightforward, very simple. We accepted the data that was submitted to us, and then we sent it back for rendering on the client. The issue that we started hitting as we started growing a little bit was that we were having a lot of difficulty testing things. It was very, very unreliable in terms of what the PHP app was doing making sure it performed consistently, and when we started to try to write unit test, that turned out to be very difficult. And so, we started looking around at other options. We played with Python for a little bit because of a lot of the geospatial utilities that existed with Python. We didn’t specifically end up needing them, and we still had some issues where testing stuff existed for Python, but it wasn't necessarily as convenient.
So one day I was just looking around, and I finally decided to start digging into some Clojure just simply because a lot of people around us had talked a lot about LISP and had been really big fans of it, obviously Paul Graham being one. We had Aaron Iba who was one of the YC partners while we were there. There was also people like Eric Raymond and things like that that had said over time like, "Hey, you should always try to learn programming languages that are going to teach you something new," and always kind of highlighting LISP, and so it was finally a moment to look into it and say, "Okay, what is this actually about?"
And so, I went in and tried it out and was able to recreate the CRUD portion of the app in less than a week. It was really, really, quick and easy to do. And not only that, the biggest part of it was that it enabled us to test it very, very easily. All the unit testing functionality in Clojure made it more so of a joy to write unit tests than anything else, which was really, really surprising because usually that's the boring part. But it was so easy to do that you proved immediately that your code worked correctly. And, it kind of forced you to write good code as well. After having such a good experience with Clojure, we decided to continue migrating things into the new Clojure application, which is what we're running on now.
Y: Ok, and when was this?
B: This was in the end of the summer of 2013 was when we started this migration.
Y: This was well after, I guess, not only the CRUD but after some of the rainfall and mapping had already been done?
B: Yes. Some of that original stuff had been written in Python, a lot of the CRUD was over in PHP, and so you notice that that's three different stacks there. We did have a transition period where we said, "Hey, it doesn't make sense to do a big, huge rewrite. We'll waste tons and tons of time getting caught up on that," so what we did was we set up an nginx server to act as a router there to point different URL routes at different applications. So as we moved things off of CakePHP into the Clojure app, we'd simply just point the route over to the correct backend to handle it. That's how over time we were able to move off of just this CakePHP app, and start slowly moving things into this Clojure application and still levrage that Python application as well without having to incur this massive rewrite.
Y: At one point you actually had three different apps running on Heroku?
B: Yeah, three different apps running on Heroku.
Y: One was CakePHP CRUD app. The other was Clojure for what specifically originally?
B: Clojure took over CRUD from CakePHP pretty quickly, and so there were just eventually fewer and fewer things running on it. We finally killed off this one news feed that was there the other day, and I think that was one of the last responsibilities in the PHP app. Most of it's work has been taken over by other applications now.
Now, we're entirely over on Clojure at the moment.
There are a few background processes that are written in Python, but for the most part we are running on Clojure. That's been very, very helpful to us, and something we’ll probably continue to do, but there are a few specific cases where just the geospatial libraries in Python, some of the scientific analysis stuff there is very useful to us, and so from time to time as Python's more useful, we sometimes use that too.
Y: Because you do have some of the data science stuff going on, so you're using R and Python for that?
B: Yeah, yeah. Our data science team kind of models some stuff out in R, Python if that's more sufficient for that situation, and so we’re able to have the data science team pull in the satellite imagery and start playing around with it, just start trying to identify what algorithms we should start using to process this imagery. And then, we’re able to build that up using... they'll start specing out in R or whatever, maybe they'll use Python, and then we'll be able to implement it eventually on our side. Maybe, we'll use Clojure, maybe we'll use Python, depending on what's most appropriate.
Y: For the database side of things, Postgres all around?
B: Yup. We're entirely using Postgres on the backend and lot of PostGIS as well for doing a lot of the geospatial analysis.
Y: That's all on Heroku of course, right?
B: Yup, all running on Heroku Postgres, except that we started to kind of move a little bit of it into Amazon RDS, and that's probably the direction we'll keep going. We started hitting some of the limits with the Heroku Postgres platform. So some of these data sets that we're using, each time we get a new one, it just keeps getting bigger and bigger. They haven't really gotten to a size where it's unmanageable within a DBMS, but they are getting to in the multiple terabytes range at this point, and Heroku's cap is at one terabyte. That's the biggest plan they offer. Postgres is capable of handling that much at the right query volume, but on Heroku Postgres, that's what we are capped at. So, we started playing around with Amazon RDS because to even get to one terabyte, you're already paying Heroku thousands of dollars a month.
So we setup an RDS application, and we're able to replicate that same database there with the correct space requirements for our needs, correct RAM, correct processing only for a few hundred dollars a month, and able to set that all up. So we've started moving more and more of our read-only data sets over from Heroku Postgres to Amazon RDS.
Y: That makes a lot of sense. It sounds like you're just going to continue to start ingesting more data, the more farmers you get, right?
B: Yes. Not only ingesting more data, but always adding new data sources as well. Just with a lot of satellite imagery we’re adding now, being able to take the tractor data in, always finding new data sources, and so always needing to spin up new databases to store that.
Y: Very cool. Chris, do you want to talk a little bit about the front-end? You guys were using Backbone originally, right, for all the web?
C: Yes. All the web originally was written in Backbone and CoffeeScript. A majority of it still is. We've actually done a new feature rewrite using React to expand how we use the front-end, how we expect to move forward, especially with a lot of the data that clients are consuming. We ran into some rendering issues, having to mess with data binding, and stuff like that, so we started playing with React and found that it was a really, really nice flow for how the data comes in and how the UI states update, so we've been pretty happy with using that.
Y: Okay, so you started using React, but you're still using Backbone for the models.
C: The features we use for Backbone are mostly just the models and the collections. The REST adapters they have built in, they just play really nice with our CRUD API, and no sense in reinventing the wheel at that point. React doesn't have any sort of data flow for interfacing with an API yet. I actually heard that they are working on something, but we'll see how that plays out.
Y: That's also on mobile too, right? You guys have mobile web?
C: Actually, I don't think we have mobile web. It is on our timeline to do a responsive app.
B: Isn’t that part of the big redesign that Sam's been working on, so that we do have a little bit more responsive capabilities.
C: Yeah. The biggest thing is the maps. The maps, trying to get those to work on mobile has been kind of difficult. Leaflet does work with mobile but doing the Leaflet draw stuff where you're actually being able to use touch gestures to make shapes for your fields is not the easiest, but we are working on it.
Y: Okay, I mean you guys have the native app so that's probably not too much of a priority.
C: It's not much of a priority, but it definitely should be done. You find people who even still are using... Even though we have the mobile apps, they still want to use their mobile browser just because it's what they're comfortable with.
Y: Let's talk about your actual workflow. What do you guys have set up in terms of your local environments and then all the way to production?
B: Sure. It varies a little bit from team to team, but we're all running Git here. We're all using GitHub repositories. We have CircleCI set up to be able to do continuous integration to automatically run our unit test there, so a lot of integration on that end, and we've mentioned Heroku too where it's as simple push to deploy on that. It runs a little bit different team to team. Different teams have different preferences. Different people on teams have different preferences. I think on the backend like there’s people using Vim, there's people using Emacs, there's people using Sublime. I don't think anybody on the backend uses Sublime, but I know you guys like it.
C: No, on the frontend we’re pretty much all Sublime. Sublime, Atom.
Y: Are you guys using VM's locally or no?
C: I don't think we're using VM's locally. The repositories you’re able to pull down and spin up, like on the front-end we use a node server to proxy all our requests to our staging server, so we don't have to actually run a local instance of an API. They're all able to play pretty nice together.
Y: You've got staging and prod, iOS and the mobile side of things, is it the same setup?
B: Yeah similar stuff, yeah. Whatever the IDE they use for iOS and Android development is, they've got that set up, but they also have a lot of their tests on that side too, and so they have integrated some things like Jenkins on the iOS side to be able to go and process their unit test automatically do their builds from them. So they do have a Jenkins test server set up.
Y: For exceptions, what are you guys using to catch those?
B: For doing a lot of our debugging, logging a lot of exceptions. We were pretty early adopters of Bugsnag. They were able to support PHP very easily for us, and they also have a number of different platforms. It's just easy to go set it all up. Not many people had done a good job at doing a lot of the exception tracking at that point. There were services like Airbrake, there was something called Rescue JS. There were so many different services that we tried at the beginning and just can't find anything great. And then finally, Bugsnag came along, and we were able to start going with them, and they were just great. Those guys are just fanatics at being able to just build out the best error tracking platform they can there, constantly making improvements to it. So we're able to really start getting a lot of value when we switched over to Bugsnag for our error tracking.
Y: Messaging internally, how do you guys communicate in the office?
C: Slack. We started using Slack after, I think, HipChat. HipChat had a couple days where they were just going down day after day, and we just kind of got sick of it so we switched over to Slack. And a couple of people who were gone, came back from the weekend, and realized that everyone had moved completely away from HipChat. So, that's what we use exclusively now.
Y: So then, everything is fed into there, exceptions, pushes, all that stuff.
C: Yup, all the deploy hooks and any exceptions especially when exception rates get high, it will notify us, so that's really nice.
Y: I think we covered everything. Do you want to talk a little bit about what's coming up next, and some of the challenges you guys are dealing with now, and moving forward?
B: We're always feeding new data into the system, right? Some things are increasingly getting bigger and bigger, satellite imagery we're going to have multiple scenes per month covering the entire globe. Rather, not the entire globe, the United States at least for now. Eventually, the entire globe though. We've also got these tractors that we're going to start putting devices in to be able to get the data off the bus there. I mean, just all the chatter alone on that bus, there's several gigabytes per hour that are generated on that tractor alone. We don't use all of that, but there's a lot of data that’s going on just out on their tractors. We’re able to just continually grab new data sources like that and start putting them in.
There was a few different tiers that we went through of value that we started to provide to farmers over time. Initially, we did a lot of data collection where we're just grabbing that from them directly. We started to then be able to go back and provide them data where we realized that, "Hey, it's not just about collecting data from them," but really pushing a lot of the rainfall, a lot of soil data, a lot of the market data, whatever we were able to get, be able to push it to them directly. And so, we're just working at this point on automating it more and more, automatically collecting data from them instead of forcing them to type it in themselves, and eventually to a point where we'll be able to take all this data that we've collected and be able to start running some analysis on them to be able to improve their, you can call it cultural practices, so that they're able to farm their fields more efficiently.
Y: Right, right. At a certain point, it sounds like you're going to be able to actually say, "No. Actually, you should be focusing on this portion of your field for the next day or so." Something like that, right?
B: We might be able to go to them and say, "Hey, we know there's a problem spot in that field. You know there's a problem spot in that field. There's a sand bar there. It's never going to get more yield than what you're getting out of there right now. But, there is a spot over here that looks like it's yielding good, and it is, but with using a little more fertilizer, maybe if you had a little bit more irrigation," or whatever the limiting factor is, help them identify it. This is the part of that field that needs more attention, or maybe even a little less attention. Maybe, you're using more water than you even need. You can cut back and save on your water there. Whatever the case may be, help them optimize a little bit more around what their field needs and to be able to really get the best of their field, and to also use resources efficiently in the process.
Y: That's really cool because it sounds like where you guys started was really just saying, "All right, let's help you do what you're already doing, just a little easier," right, with the CRUD app, which they were pretty much just doing on paper, and then you said, "All right, let's start taking on more of that," bringing in the rainfall data for instance into one place, bringing in the tractor data into one place. Once you've done that, you can move on to other things and say, "All right, now that we have all this, we can actually be really smart about what you should and shouldn’t be doing moving forward." That's really cool. So data is the next big focus for you guys, and trying to make sense of everything that's coming into the system.
C: Yeah, being able to read in that data and analyze it, and provide insight to the farmers, not even just being able to tell them what to do, but to give them the data that they can even intuitively act upon that they didn't have before.
Y: Right, really moving towards a push model. By the way, did you talk about fertilizers and seeds?
B: Yeah that’s part of using your resources more efficiently, right? Not only we'll be able to say that, "Hey, this is the part of your field that needs more water attention," something like that, but maybe you're able to use their tractors to do variable rate seeding, variable rate applications of fertilizers, pesticides, to be able to say that, "Hey, your field is not this uniform thing. It's a very large area with a lot of very distinct characteristics in different sections, and by using a higher seeding rate here, you're able to get a bit more yield. Maybe you don't need as much fertilizer in that section," able to make more efficient use of resources to be able to ultimately get more efficient yields, and also to use a little bit less fertilizer, a little bit less pesticide where you don't really need it.
Y: And you guys are hiring, right?
B: Yes, we're always hiring, looking at doubling the team this year. We were fortunate to raise a Series B from a bunch of existing investors as well as Sam Altman and SV Angel just at the end of last year, so a lot of cool stuff. We're always looking for people who have any sort of talent they want to bring to the team. A lot of engineers, anybody who is interested can always go to farmlogs.com/jobs and look at what's available there, and just shoot us an email if they’re interested in contributing.
Y: Thanks a lot, guys. This was awesome. Really appreciate you taking the time. Software for farmers!
B: Yup, thanks for having us!
