Death by waterfall, or death by pilotitus? There is a better way to build tech at nonprofits.

Organisations tend to gravitate toward overly prescriptive tech requirements, or piloting with no requirements at all. Both of these approaches will leave a graveyard of failed projects. But there is a better way.


We have spent the last 10 years and countless hours working to understand what works and what fails when implementing technology at nonprofits and agribusinesses. There are two missteps that most organisations make:

Death by waterfall. In the waterfall approach to technology development, requirements are documented in full, followed by long development timeframes. At least one of the following things happens in this case. First, it’s impossible for anyone to know all requirements ahead of time, especially as businesses grow and market conditions change. Second, this approach is incredibly slow, expensive, and risky – it requires long development timeframes before technology can be tested and used. Meanwhile, agribusinesses or their donors are required to carry all risk up front. In the end, agribusinesses are saddled with a solution that only partially works and cannot be changed without additional costs. Essentially, you have to “buy before you try”, and once you buy, you are stuck.

Death by pilotitus. As an answer to combat a slow death by the waterfall approach, many organisations have pendulum swung back in the other direction, declaring that “pilots” are the solution to the technology woes noted above. This is a valid thought, in part because a huge number of valuable insights will almost always come from pilots and technology should always be developed through iterations. The problem with pilots, however, is that they rarely form a foundation for long term, sustainable technology solutions. In most cases, the paralysis and disappointment of the waterfall approach is averted, but funding is endlessly devoted to learning, rather than simply being used for building things that work well in practice. This is especially true for almost every technology use case within the context of agriculture, where requirements are typically unique and nuanced for each business, but are common at a high level across all agribusiness.

Neither of the missteps noted before are helpful for the agribusiness or the technology firm supporting the agribusiness. The agribusiness feels handcuffed, and the technology provider does not have the resources required for sustained innovation. In response, most AgTech SaaS companies focused on farmer management and traceability will promise the world and usually underdeliver. This perpetuates a cycle of frustration and a lack of technology innovation.

There is a better way

The better way is to roll out technology quickly, iteratively, and risk-free using low-code / no-code tools that can be easily modified as requirements evolve. With this approach, we do not need to document requirements in full and at the onset, but rather let the requirements evolve organically over time. This may be digitising existing operations or launching a new business model that is only feasible with digital tools. Either way, we do not need to solve everything all at once, but instead we can start small, keep things simple, and implement a solid foundation that will scale once a solution is proven to have a positive impact on the business.

You can think of this approach as the perfect middle ground that agribusinesses have always needed. This optimal implementation strategy is only possible through the emergence of powerful tools – such as Google Appsheet – which have catalysed new opportunities for technology innovation. These tools, along with the template apps we have developed, allow agribusinesses to implement solutions in days, instead of months, and with no upfront risk. In short, agribusinesses and donors can “try before they buy”, which means they can focus on what matters most – growing organisations and their impact - instead of endlessly fighting technology that does not work as expected.