Longer-term development strategy

Our longest-term, most broad vision for FarmBot is that it operates much like a home-appliance, for example a washing machine.

  • Reliable - Doesn’t require much ongoing maintenance to keep the system functioning.
  • Easy - Anyone can learn to use it with little effort. Doesn’t require a technical skill such as programming.
  • Automated - Intelligently takes care of everything better than you could. Uses a combination of existing data (eg: how to grow a crop) and real-time data (eg: how wet the soil is).

Then where FarmBot differs from a home appliance (which usually has a very limited set of options) is in its customizability.

  • If you don’t want to use the built-in “presets”, you can dive in and adjust anything and everything.
  • You grow what you want, how you want. We don’t impose limitations on timing, quantities, spacing, inputs, methodologies, seed types, order of operations, etc.
  • The software and hardware is generalized enough so you can easily adapt it to new use cases, methods, crops, environments, etc.


Roughly, I think, there are two ways to build the product described above.

Strategy 1: Start from the appliance end of the spectrum (limited set of built-in options) and then add more options over time, and eventually full customization capabilities.

Years ago when we started building, we could have first allowed users to choose from a small set of crops (say, 20) to add to their map in pre-defined locations. Built-in sequences and regimens and events (or some other control paradigms) could have been automatically scheduled for every plant in a behind-the-scenes manner. The bot could have then taken care of those plants according to the built-in methods without any other setup required on the user’s part. Sounds great, right? Yes, but only if your needs aligned well with the limited set of built-in options.

If you wanted to plant a different crop, you would have needed to ask us to add it to the system for you and/or make a way for you to add custom crops. If you wanted to grow something with a different method, we would need to add that different method as a new built-in option, or again, build in ways for you to customize as you please (sequence editor, regimen editor, custom event scheduling, etc). Until the full-customization options were built, we would be getting requests every day, for us to add a built-in option for every user’s unique desires. You can see how that would have been a huge time suck and completely unsustainable. And none of those presets would be laying the foundation for future features - they would be a distraction from the end-solution.

Many products are built this way though, and oftentimes it is a great method. For example, a washing machine doesn’t need a high degree of customizability because there is a very limited number of parameters that can be changed anyways. A decent set of built-in presets often does encompass almost all user needs, and there is limited reason to offer more customizability. However, whenever the built-in presets do come up short, that often leaves users wanting more out of their product.

Compare washing clothes to growing your own food. There are maybe 10 types of clothes out there, but thousands of types of crops. There is hot/warm/cold water for washing, but practically infinite combinations soil type, weather conditions, and crop needs that can combine to determine the best amount of water to administer, and when. Etc.

It would seem then that offering a limited set of inflexible built-in options in the beginning would not have been a good strategy for FarmBot. Nobody would have been happy with our presets because there are simply too many parameters at play. Every day we would receive email requests and complaints demanding we add a built-in preset for crop X, or method Y. It would illuminate very quickly that flexible tools are key in the context of growing food.

And as a side, FarmBot, from a philosophical standpoint, has never wanted to impose any kind of growing methods or limitations on users. FarmBot is not a grow-broccoli-my-way-or-the-high-way kind of platform, nor should it be. That would not align with the concept of owning your food. FarmBot is much more about giving tools and knowledge to everyday people.

So, strategy 2:

Strategy 2: Start from the customizable end of the spectrum

The strategy we have been following pretty much from the start is to build tools that give users the most flexibility in configuring their bot. From the start we have had the sequence editor, farm designer, OpenFarm, and the event scheduler, allowing for very versatile operation of the machine.

However, without built-in presets, this strategy has come at the cost of requiring users to take time to learn the system and oftentimes perform tedious setup in the app. This is well understood by our team, and the main tradeoff we have made compared to strategy 1. Our current users though are by-and-large early adopter type people who are not only wanting, but sometimes demanding this flexibility so they can set up FarmBot how they want. And almost everyone has a different idea of how to set up their bot the best, which is again why a flexible tool strategy is better in this context.

While we do aim to reach the average-joe consumer eventually, we recognize that that’s not the arc that new technology takes, and we won’t get there with our technology or average customer for a few more years.

This all being said, strategy 2 does leave our customers always wanting more tools (rather than more built-in presets in strategy 1). And this is where we put most of our time and effort. The reality though is that tools take much longer to build than presets. A tool needs to be carefully planned and crafted. It must balance flexibility with ease of use. It must fit into a larger system of control paradigms. It needs to provide power users what they want, while protecting novice users from bad or easy-to-make mistakes.

With some recent milestones hit (sequence variables and filter-based groups), we’ve removed some of the most tedious aspects of the app experience. There is always work left to do though, which leads me to what all this backstory is getting at:


As mentioned previously, our project board is publicly available as well as the open issues in our GitHub repositories. This shows the features we are working on and have planned, which offers a glimpse as to what the app might be like going forward.

What you might not see though is that many of the open issues are stepping stones towards even farther ahead ideas. For example, we plan to build support for sequence variables of different types (eg: time for dosing water). That - in itself - will be a big undertaking. But then it paves the way towards watering information coming from OpenFarm and being dynamically loaded into a sequence. And that, paves the way towards an intermediary algorithm to adjust the water dose in real-time based on other data sources (weather, soil measurement, etc). And that, combined with plant growth analytics would allow for the training of an AI system.

With the way we’ve been building out features (strategy 2), everything sort of builds on itself. But we can’t just “jump ahead” a few steps. And the example above is just one of many dozens of spires and flying buttresses that are being built brick by brick to form the FarmBot cathedral. If we focus too much one one thing, people begin complaining the other things aren’t getting enough attention. It’s tough with a small team!

Anyways, I encourage everyone who is interested to look through our project board and if something in particular piques your interest, please leave a comment with your ideas or let us know it is important to you. Also feel free to open up new issues with your ideas, or write about them here on the forum. That’s the feedback that helps us steer.

There are also dozens of issues marked Good First Issue and Low Hanging Fruit which are great places to get started if you would like to contribute.

For the next few months you can expect us to spend most of our time on the following:

  • MARK AS variable support and custom write-in options (in progress now)
  • “Random Jitter” movements (immediate next feature)
  • Working down technical debt and increasing test coverage, particularly in FarmBot OS (ongoing)
  • Calibration and homing improvements in the firmware (in progress now)
  • Improved support for our latest electronics boards and the Trinamic TMC2130 stepper drivers (ongoing)
  • Minor UI/UX improvements (ongoing)
  • Other issues tagged High Priority on our project board (exact issues subject to change)

After that we’ll have a discussion as to which major feature should be built out next. The decision will be informed by customer feedback, analytics of how FarmBots are being used, where we want to be at certain points in the future, what we think the market wants, the makeup of our customer base, market conditions, etc.

1 Like

I appreciate the technical roadmap and addressing some of the current problems. I would welcome it if part of the strategy addressed improving and standardizing documentation. The videos are frustrating. “Hey, you just kinda do it this way on a previous version of our software.” The written documentation really falls short after mechanical assembly. It would be great if there were built-in function verification test routines developed by FarmBot that could be run to verify that the Farmbot is fully functional or if is not and where it is not.

FarmBot has come a long way in a short time. I actually bought it to have a fiddly figure it out kind of project. It ticks a lot of boxes: robot, Arduino, Raspberry Pi, does a real function, open source. And at the end of the season, I will have vegetables to eat.


1 Like

Thanks for the feedback @John_D. We’re glad you’re enjoying FarmBot! We do have a ways to go with our documentation and I appreciate the feedback (in this thread and in the one from a few days ago). We’re keeping your suggestions in mind for the next batch of documentation videos.

To expand on Rory’s comments, I would say that the trajectory that FarmBot follows today mimics the same path seen by many other early consumer technologies and I firmly believe that we are on a path to mainstream adoption, but there are absolutely challenges to be addressed in the interim. I am confident that these challenges will be addressed, albeit at a slower pace than anyone (including myself) would like.

If you’re still wanting more from the feature set or ease of use that your device offers you today, the first thing I would say is thank you for making this possible by taking a leap of faith and becoming an early adopter. Secondly, I would say that most of what FarmBot lacks today can be improved in software updates and the value of your hardware (even if an early model) will improve with time, as it has been over the last three years. Your initial support has helped us build the hardware foundation that will pave the way for advanced software features. Thanks again for your continued support as our small team of 4 employees take on this monumental challenge.


Thanks for the feedback @John_D. I’ll spend some significant time the rest of this week updating the written software documentation. And you make a good point about the videos - they become outdated quickly and have many feature gaps, so we may phase them out in favor of better written docs with time.


One area of the strategy which I think has created significant customer demand is the commitment to open source. It’s also close to the hearts of those that demand the flexibility. This in turn feeds a faster virtuous cycle of product evolution and reinforces why the second strategy was the best at this stage.

It’s interesting companies that take the appliance first strategy usually aren’t open source companies. They don’t have to publicly
share code documentation, CAD models, PCB schematics etc. It is actually a fair amount of overhead.


I really appreciate your transparency on your guiding principals and the commitment to open source. I think you might want to build out your backlog a bit more and express how you want to prioritize work and, importantly, what makes it into the trunk/master. Additionally I have found developing formal “personas” is an indispensable way to understand end-user values, expectations, workflows, and the impact of your decisions. Personas are also a great way to understand when your product can be considered “turn-key” for different market segments. I have worked many underfunded R&D robotics projects and realize all of this is a big ask in addition to supporting the work that you have already committed to.

1 Like

We do have several generic personas that we regularly discuss internally: “power users”, “teachers”, “homeowners” though we don’t have more specific definitions of various users, and certainly not anything formally documented at this point. Maybe we’ll try and get something more concrete written down next time we’re able to have our whole team together in-person. Thanks for the suggestion!