Agricultural technology in smallholder farming communities tends to follow a predictable adoption arc: initial enthusiasm, followed by declining usage, followed by abandonment, followed by a gap that looks like technology resistance when it is actually a design problem. Farmers do not resist technology in the abstract. They reject technology that requires more effort than it returns, that is legible to the people who built it but not to the people who use it, and that creates dependencies on external support structures the farming community does not control.
The design decisions that determine which category a platform falls into are not primarily technical. They are architectural: decisions about who holds the operational knowledge the platform encodes, where the value captured by the platform flows, and how the technology relates to the existing governance structures of the farming community. These decisions are usually made early, often implicitly, and they shape the entire downstream relationship between the platform and the community it serves. By the time a platform is in the field and stalling, the choices that determined the outcome were made months earlier, in architecture meetings where no farmer was present.
Bayanihan Harvest is a 66-module integrated agricultural platform designed for Filipino cooperative farming communities. I built it with a specific commitment: that every design decision would be tested against the question of whether it served farmers' operations or imposed a parallel system they would have to maintain in addition to their existing operations. That commitment produced three specific design decision points where the choices were most consequential for whether the platform integrated with how communities actually work versus creating new dependencies. This piece names those three decisions, shows the mechanism behind each, and is honest about where the approach costs more than the alternative.
The Extraction Pattern in Agricultural Technology
Before examining the design decisions themselves, it is useful to be precise about what extraction looks like in agricultural technology, because it does not announce itself as extraction. It presents as service, convenience, and modernization. The vocabulary is always cooperative: empowerment, access, inclusion, digitization. The structure underneath the vocabulary is frequently the opposite.
The core extraction pattern is data asymmetry: the platform aggregates information about farming operations — yield data, pricing data, supply chain data, cooperative membership data — and the entity that controls the platform has access to that aggregated data while the individual farmers who generated it do not. This asymmetry is not incidental. It is the design of most agricultural data platforms, because the aggregated data has commercial value to input suppliers, financial institutions, commodity buyers, and agricultural research organizations. The platform is nominally a service to farmers and structurally a data collection mechanism for those buyers.
The consequences are material. Farmers who generate the data that makes precision agriculture systems valuable are rarely the beneficiaries of that value. The pricing intelligence the platform accumulates is available to buyers before it is available to sellers. The yield prediction data that would allow a cooperative to negotiate better contract terms is held by the platform rather than by the cooperative. The knowledge that the community had before the platform existed — informal, distributed, accumulated through generations — is formalized into the platform and becomes inaccessible without the platform. If the platform shuts down, raises its fees, or changes its terms, the community has not just lost a tool. It has lost access to the operational knowledge that the tool encoded.
There is a slower, quieter version of this pattern that is harder to see. A platform can extract without ever selling a row of data. It extracts when it makes itself the only place a particular decision can be made — when the cooperative can no longer plan a season, price a harvest, or settle a member's account without opening the application. At that point the platform has not stolen anything. It has simply become load-bearing, and the cooperative's bargaining position has quietly inverted. The fee can rise. The terms can change. The community absorbs it because the cost of leaving is now the cost of rebuilding capacity it used to have. Avoiding this pattern requires making explicit design decisions at the points where the choice most directly determines who controls the value — and making them before the dependency exists, because once it exists, it is expensive to reverse.
Design Decision One: Where Does Operational Knowledge Live?
The first and most consequential design decision is the locus of operational knowledge: is the knowledge about how the farming operation works encoded in the platform, or does the platform assist knowledge that remains in the community?
These are not the same thing. A platform that encodes the operational knowledge is one where the crop planning module defines what planting decisions look like — the parameters, the sequences, the rules. A community that adopts this platform has its decision-making structure migrated into the platform's design. The platform knows how to run the operation; the community follows the platform. If the platform goes offline, the community has less operational capacity than it had before the platform existed. The dependency is total because the thinking now lives in the software.
A platform that assists community knowledge is one where the decision structure originates in the community's own practices and the platform supports those practices with information, record-keeping, and communication. The crop planning module asks what the cooperative's own planting practice specifies and helps track execution against it. The platform is a tool, not a system of record for operational logic. The distinction sounds subtle. In implementation it changes nearly every screen.
In Bayanihan Harvest, this distinction shaped the architecture of every module that touched operational decision-making. The seed management module does not define what seeds should be used or when. It records the cooperative's own seed inventory, tracks the movement of seeds through the cooperative's distribution practices, and flags deviations from the cooperative's own standards. The cooperative's agronomists determine what the standards are; the platform helps maintain visibility against those standards. The knowledge stays in the community; the platform reduces the cost of applying it consistently. The difference shows up in what happens after a bad season: a community whose agronomists set the standards can revise them from experience, while a community that inherited the platform's defaults waits for the vendor to ship an update.
There is a concrete test that operationalizes this principle, and it is the question I returned to whenever a module's design felt ambiguous: if a new cooperative officer joined and the platform were unavailable for a month, could the cooperative explain its own operation to that officer without the software? Where the answer was yes, the knowledge was still in the community and the platform was assisting. Where the answer was no, the knowledge had migrated into the platform, and the module needed to be redesigned so that the platform held the record rather than the reasoning.
This design is more difficult to build and less scalable in the conventional sense — it requires the platform to be configurable to the variety of practices across different cooperatives rather than imposing a single practice structure. That cost is real, and it compounds: every configurable surface is a surface that has to be supported, documented, and tested across more states. The alternative is a platform that cooperatives adopt and that gradually becomes the de facto owner of their operational knowledge — a dependency that is invisible until the dependency is tested.
Design Decision Two: Where Does the Value Captured by the Platform Flow?
Agricultural platforms create value by reducing transaction costs — connecting buyers and sellers, aggregating demand for inputs, making pricing information visible. The design question is not whether to create this value but who captures it.
The default design for commercial agricultural platforms routes value capture to the platform owner through transaction fees, subscription revenue, or data monetization. This is a viable business model. It is also a design that, in communities with thin margins and limited alternatives, concentrates value extraction in an entity that the farming community does not control. A cooperative that depends on a commercial platform for market access has traded one dependency (on informal market relationships) for another (on the platform's fee structure and continued operation). The new dependency is often worse, because the informal relationships were many and substitutable, while the platform is one and is not.
Bayanihan Harvest was designed so that the value created by the marketplace module flows to the cooperative, not through the cooperative to a platform operator. The marketplace connects cooperative members to buyers and provides pricing transparency that the informal market previously obscured. The revenue from marketplace transactions stays within the cooperative's own financial structure. The platform does not take a transaction percentage from buyer-seller exchanges within the cooperative's own market. This is the decision that most directly determines whether the platform is aligned with the cooperative or quietly competing with it for the same margin.
This design has a direct consequence for the platform's sustainability: it requires a different revenue model than transaction percentage capture. Bayanihan Harvest's revenue model is a cooperative membership fee — cooperatives that use the platform pay a membership fee that covers the operational cost of the platform. The fee is transparent, predictable, and not tied to transaction volume, which means cooperatives can predict the cost of using the platform without risk of fee increases correlated with their own productivity improvements. A transaction percentage punishes a cooperative for getting better; a flat membership fee does not. That difference is not cosmetic. It determines whether the platform's incentives point in the same direction as the community's.
The practical implication is that the platform must provide sufficient value to justify the membership fee on its own terms — not subsidized by transaction capture that happens to benefit the cooperative. This creates a stronger incentive to design for genuine operational value rather than for engagement metrics that increase transaction volume. If the platform is not solving a real problem that the cooperative will pay a predictable fee to have solved, it is not a viable platform. The membership-fee model is therefore also a discipline on the builder: it removes the option of hiding a weak product behind transaction volume, and it forces the value to be legible enough that a cooperative's officers can defend the line item to their own membership at the annual assembly.
The honest cost of this model is that it raises the bar for the first sale. A transaction-fee platform can onboard a cooperative for nothing and grow into the relationship. A membership-fee platform has to be worth paying for on day one, before the cooperative has experienced the value. That is a harder commercial position, and it slows acquisition. It is the price of an incentive structure that does not drift toward extraction as the platform scales.
Design Decision Three: How Does the Platform Relate to Existing Governance?
Agricultural cooperatives in the Philippines have existing governance structures: elected officers, established decision protocols, accountability mechanisms that have been built over years of collective operation. A technology platform that interacts with cooperative governance in the wrong way — even with good intentions — can undermine structures that took years to develop. The damage is rarely intentional. It is a side effect of software that was designed to be efficient without being designed to be deferential.
The failure pattern is substitution: the platform creates its own communication channels, its own record-keeping systems, its own escalation pathways, and these gradually substitute for the cooperative's own governance mechanisms. Members communicate through the platform instead of through the cooperative's assembly. Records exist in the platform rather than in the cooperative's own documentation systems. Decision authority shifts from the cooperative's officers to whoever manages the platform's settings. None of these shifts is announced. Each one is a convenience that, accumulated, relocates authority from people the membership elected to a configuration screen the membership never sees.
Bayanihan Harvest was designed around an explicit principle: the platform extends cooperative governance, it does not substitute for it. The communication module integrates with how the cooperative's officers already communicate — it provides a channel, not a replacement for the assembly. The record-keeping system outputs records in formats that the cooperative can store and access without the platform — CSV exports, printed reports, human-readable formats. The platform is not the system of record; the cooperative is. The platform makes maintaining that record cheaper and more consistent. The CSV export is not a minor feature. It is the structural guarantee that the cooperative can walk away with its own data in a form it can use, which is what keeps the relationship voluntary rather than captive.
This design required, at the module level, asking a specific question about every feature: if the cooperative stopped using the platform tomorrow, would the feature have left the cooperative with more governance capacity, the same capacity, or less? Features that would leave the cooperative with less capacity — because the knowledge or the records or the decision authority had migrated to the platform — were redesigned until the answer was neutral or positive. This is a slower way to build, because the natural gradient of software design pulls toward consolidation: it is always easier to make the platform the single source of truth than to keep mirroring authority back to a human governance body that moves at the pace of monthly assemblies.
The governance integration principle also shaped the rollout approach. New modules are introduced after the cooperative's officers have decided to adopt them, through a process the officers control. Adoption is not incentivized through pricing structures that make the platform nearly free initially and expensive later. It proceeds at the pace the cooperative's own governance can absorb. This is slower than a growth-at-all-costs adoption model. It produces adoption that holds, which is more valuable than adoption that stalls six months in. A module that the officers chose to adopt survives a leadership change; a module that was pushed in through an incentive leaves with the officer who accepted it.
The Design Philosophy These Decisions Reflect
The three design decisions described here — knowledge locus, value flow, governance relationship — are not independent choices. They reflect a single underlying philosophy: the technology exists to increase the operational capacity of the community, not to capture a portion of that capacity for the platform's benefit. The three decisions are the three places where that philosophy either holds or fails, because they are the three places where the natural design gradient runs against it.
This philosophy is not naive about the need for platforms to sustain themselves. Bayanihan Harvest needs to generate enough revenue to be maintained and developed. The argument is not that platform sustainability is unimportant; it is that platform sustainability and community service are not in conflict if the value proposition is genuine. A cooperative that is genuinely more operationally capable because of the platform will pay for it. A platform that extracts value while appearing to provide service will eventually be abandoned when the extraction becomes visible — which, in smallholder farming communities with long institutional memory, it eventually does.
The test for any agricultural technology design decision is not "will this make the platform more valuable?" It is "will this make the farming community more capable?" The two questions produce different answers with some regularity. When they diverge, the community-facing answer is the right one for platforms that intend to operate in those communities for years rather than quarters. The platforms built to answer the first question optimize for the next funding round; the platforms built to answer the second optimize for the next decade of use.
Where This Approach Breaks Down
Cooperative-first design is not free, and it does not win every contest it enters. There are three places where it is genuinely costly, and a builder who pretends otherwise is selling the same overconfidence the approach is supposed to correct.
The first cost is speed. Every decision in this framework slows the platform down: configurability slows engineering, the membership-fee model slows acquisition, and governance-paced rollout slows adoption. A competitor willing to encode operational logic, take a transaction cut, and push features past the officers will move faster on every axis a slide deck measures. In a market where capital flows to growth curves, the cooperative-first platform is structurally disadvantaged in the fundraising that funds survival. The approach trades short-term legibility to investors for long-term legibility to communities, and not every funding environment rewards that trade.
The second cost is that it does not solve problems outside the cooperative's own boundary. Bayanihan Harvest can align a platform's incentives with a cooperative's, but it cannot fix the structural disadvantages a smallholder cooperative faces in markets it does not control — input prices set elsewhere, climate variability, the thin and volatile margins of Philippine smallholder agriculture itself. Designing for community capacity is necessary; it is not sufficient. A well-designed platform inside a badly tilted market is still inside a badly tilted market.
The third cost is that the discipline depends on the builder, not the architecture. None of these three decisions is enforced by a standard, a regulator, or a contract. They are enforced by the person making the architecture choices choosing the harder path each time the easier one is available — and the easier one is always available, on every module, indefinitely. A change of ownership, a change of business model, or a single quarter of pressure can reverse all three decisions without violating anything written down. The approach is robust against farmer resistance and fragile against a change of management.
What This Means for Platform Builders
For builders of agricultural technology, the three decision points described here are not the complete checklist of cooperative-first design. They are the points where the design choices have been most consequential in practice — where the wrong choice at this specific point would have produced a platform that extracted rather than served.
The actual design work is ongoing, iterative, and dependent on the specific community the platform serves. No framework substitutes for direct engagement with the cooperative officers, field workers, and farmers who will use the platform — not as a research activity that precedes design, but as a continuous feedback loop that shapes design decisions throughout the development cycle. The most important design information about Bayanihan Harvest has come from cooperative officers who have used the platform for months and have encountered the places where the design assumed conditions that their community's actual operations do not provide.
If you build agricultural technology and can adopt only one thing from this without rebuilding your platform, adopt the governance test from Decision Three: take any single feature you are about to ship and ask whether, if the cooperative stopped using your platform tomorrow, that feature would leave them with more capacity, the same capacity, or less. Run the test on one feature this week. It costs nothing, requires no rearchitecture, and it will surface the extraction you did not know you were designing — because the feature that fails the test is almost never the one you would have suspected.
Building agricultural technology for smallholder communities is not a special case of building technology for a specific market segment. It is a different kind of technology work, one that requires the builder to internalize the community's operational logic as thoroughly as they have internalized the technical systems they are building. The platforms that work are built by people who could explain how the cooperative's seasonal planning process works, not just how the database schema models it.
Continue in this series
This piece is part of Agritech in Emerging Markets: A Field Guide for Practitioners, my systematic guide to agriculture and community technology. Related reading:
- Technology Adoption in Filipino Farming Communities: What Actually Works
- Why Agricultural Technology Fails at the Last Mile
- Why Most Agritech Fails in Philippine Agricultural Communities
- Why Agricultural Data Belongs to Farmers, Not Platforms
See how this plays out in practice across my portfolio of ventures.
