Smart farming platforms are frequently conceived around persistent connectivity, modern devices, scalable cloud services, specialized technical support, and the financial capacity to adopt integrated digital systems. These assumptions may not hold in smallholder and connectivity-constrained agricultural settings, where infrastructure gaps, uneven digital skills, limited advisory access, maintenance difficulties, data costs, language diversity, and uncertain platform governance shape whether digital services are usable or sustainable. This article develops a conceptual design science framework for low-resource smart farming platforms. The framework links problem relevance, contextual requirement definition, design principles, platform artifact logic, implementation conditions, evaluation needs, feedback, and framework updating. It focuses on affordability, transparent costs, incremental adoption, modular architecture, interoperability, offline-first operation, low-bandwidth communication, local usability, accessible interaction, advisory integration, maintenance capacity, farmer data control, and trust. The proposed approach treats smallholders as heterogeneous users operating within diverse production systems, infrastructures, institutions, and knowledge networks. Platform functions are therefore organized as configurable responses to identified conditions rather than as a universal technology package. The principal contribution is a structured design science logic for translating low-resource agricultural problems into bounded platform requirements and evaluable conceptual artifacts. The framework can guide platform design and research planning, but it does not independently demonstrate affordability, inclusion, adoption, scalability, sustainability, operational safety, or deployment readiness. These outcomes require local usability assessment, affordability analysis, governance review, maintenance evaluation, implementation research, and field validation involving intended users and supporting institutions.
Digital agriculture is increasingly associated with connected sensors, data platforms, decision-support services, mobile applications, remote sensing, automated analytics, and digitally mediated farm management. However, the significance of this transformation cannot be understood only through the availability or technical performance of individual technologies. Digital agriculture also changes work practices, knowledge relationships, data ownership, advisory roles, institutional responsibilities, and the distribution of decision-making power. These sociotechnical dimensions are particularly important in low-resource agriculture, where technology choices interact with constrained capital, uneven infrastructure, limited technical support, and diverse farmer capabilities. A platform may be technically functional yet remain poorly aligned with local priorities, unaffordable over its operating life, difficult to repair, inaccessible to some intended users, or dependent on institutions that cannot sustain it. Consequently, low-resource smart farming should be treated as a contextual design problem rather than as a simplified version of high-resource precision agriculture [1].
Smart farming platforms also operate within agricultural knowledge and advice networks rather than functioning as isolated information products. Farmers may interpret digital outputs through extension officers, agronomists, cooperatives, input suppliers, local service providers, peer networks, or other trusted intermediaries. Digitalisation can alter how information is produced, validated, transmitted, and acted upon, while also shifting responsibilities among public institutions, private firms, advisers, and farmers. In connectivity-constrained settings, a platform that generates data without providing understandable interpretation or feasible access to human assistance may have limited practical utility. Advisory integration must therefore be considered an architectural and organizational requirement, not an optional feature added after technical development. Platform design should clarify how information moves between digital components and human actors, how recommendations can be questioned or escalated, and how farmer feedback can influence later revisions [2].
A further challenge is that low-resource agricultural platforms combine social, cyber, and physical elements. Their operation depends not only on software and data processing but also on devices, communication networks, energy access, farm environments, institutional arrangements, user practices, and local support capacity. These elements interact across several levels. A mobile interface may be usable but unavailable during network interruptions; a sensor module may collect data but become ineffective when replacement parts are inaccessible; and a cloud service may process information while leaving farmers uncertain about how their data are used. A context-sensitive design process must therefore map the social actors, technical dependencies, physical conditions, and responsibility relationships surrounding the intended artifact. This mapping helps distinguish requirements that can be addressed through platform architecture from constraints that require institutional support, training, financing, governance, or infrastructure development [3].
Design science is appropriate for this problem because it connects consequential problems with explicit requirements, prescriptive design principles, artifact configurations, implementation conditions, and evaluation. It can help structure how low-resource conditions are translated into modular functions, offline workflows, accessible interfaces, governance controls, and maintenance arrangements. Nevertheless, a design science framework does not by itself establish that a platform will be affordable, adopted, inclusive, trusted, scalable, sustainable, or suitable for deployment. Such outcomes depend on farmers’ priorities, institutional capacity, infrastructure, economic conditions, social relations, and evidence generated through appropriate evaluation. This article therefore develops a conceptual framework for designing and assessing low-resource smart farming platforms while maintaining explicit boundaries between proposed design logic and demonstrated implementation outcomes. Its contribution lies in organizing context definition, design requirements, platform principles, artifact logic, evaluation, feedback, and updating around smallholder and connectivity-constrained agriculture [4].
Low-resource smart farming contexts are characterized by combinations of constrained finance, uneven infrastructure, limited access to specialized equipment, variable digital skills, fragmented advisory services, and restricted capacity to maintain complex systems. These conditions should not be interpreted as a single fixed category. Smallholder farms differ in production orientation, labour organization, market participation, asset ownership, risk exposure, language, education, and access to collective institutions. Digital agriculture in these settings is therefore better understood as an ecosystem involving farmers, communication services, data systems, advisers, public institutions, technology providers, cooperatives, local technicians, and market actors. Weakness in any of these components can affect the utility of the overall platform. An application may be accessible through a phone but remain unusable because information is poorly localized, costs are unclear, training is unavailable, or the service cannot connect farmers with trusted support [5].
Resource constraints influence both the scale and sequence of digital adoption. Small farms may be unable to justify systems designed around extensive sensing infrastructure, continuous subscriptions, specialized calibration, or high volumes of data. The relevant design question is not whether precision agriculture can be miniaturized, but which functions are valuable enough to justify their full economic and operational burden in a specific setting. This requires attention to initial acquisition, connectivity, replacement, repair, training, technical support, and the time required to enter or interpret data. Incremental adoption may allow users to begin with farm records, weather information, lightweight advisory communication, or limited sensing before considering more complex modules. However, staged access does not guarantee affordability or progression. Each configuration requires separate assessment of utility, recurring cost, maintenance demand, and compatibility with existing farming practices [6].
Physical and communication infrastructure further shapes feasible platform architecture. Smallholder-oriented sensing and Internet of Things systems may depend on network coverage, power availability, durable hardware, local gateways, device storage, or access to cloud services. Where these dependencies are unstable, continuous data transmission and centralized processing may be inappropriate for essential functions. Edge processing, local data storage, delayed synchronization, or intermittent upload can reduce reliance on continuous connectivity where supported by the use case and validated under actual operating conditions. Similarly, sensor integration should remain modular so that platform utility does not collapse when a device fails or cannot be replaced. Maintenance responsibility, diagnostic procedures, component availability, and repair capacity should be specified during design rather than treated as concerns that arise only after installation [7].
Low-resource conditions are also produced by institutional and social arrangements. Government support, advisory capacity, platform business models, technology access, farmer knowledge, collective organization, and local service ecosystems influence whether digital services can be used meaningfully. Platform design must therefore begin with stakeholder and context mapping rather than a predetermined technical package. This includes identifying intended users, intermediaries, infrastructure providers, data stewards, maintenance actors, and groups that may be excluded by device, language, literacy, gender, age, disability, income, or geographic location. It also requires an explicit no-one-size-fits-all boundary. A configuration developed for one smallholder setting cannot be assumed to transfer to another without examining differences in farm systems, institutions, infrastructure, advisory relationships, and data-governance expectations [8].
Mobile access is often treated as the primary route for reaching smallholder farmers, but the existence of mobile networks or household phone ownership does not demonstrate effective access to agricultural services. Devices may be shared, technically outdated, unavailable to particular household members, or unable to support data-intensive applications. Farmers may also face high data costs, limited storage, intermittent charging, unfamiliar interfaces, or concerns about privacy when accounts are accessed through shared devices. Mobile agricultural services should therefore be assessed according to practical utility, accessibility, task completion, information quality, and continuity of use rather than the number of potential users who possess a phone. Lightweight messaging, assisted access, or voice interaction may be appropriate in some contexts, but each channel requires local evaluation of language, comprehension, cost, privacy, and reliability [9].
Digital adoption among small-scale farmers is shaped by interacting economic, technological, individual, organizational, and social conditions. Affordability may affect initial access, while perceived usefulness, digital confidence, training, compatibility with farm practices, and continuing support influence whether a service is used after introduction. Social networks and institutional relationships can also affect how farmers judge the legitimacy or risk of a platform. These factors caution against assuming that a simple interface or low purchase price will produce adoption. Design can reduce avoidable burdens by limiting unnecessary steps, clarifying expected benefits and costs, and supporting gradual engagement, but structural constraints may remain. Sustained use should consequently be treated as an empirical evaluation question requiring attention to discontinuation, selective use, adaptation, and reliance on intermediaries [10].
Connectivity constraints also affect the relationship between digital platforms and agricultural extension. Digital communication may increase the potential reach of advisory services, but it does not automatically provide locally relevant interpretation, accountability, or responsive support. Farmers may require assistance to translate alerts, forecasts, sensor readings, or model outputs into decisions that reflect crop conditions, resource limitations, and risk. Platforms can support hybrid advisory arrangements by enabling structured referrals, adviser access, shared records, feedback, and escalation when automated or standardized information is insufficient. Such integration depends on the capacity and mandate of extension services, cooperatives, agronomists, and other intermediaries. Where human support is limited, adding a digital channel may redistribute workload rather than resolve the advisory constraint [11].
Intermittent networks, low bandwidth, electricity limitations, restricted device access, data costs, digital literacy, and language diversity collectively delimit which platform functions can be relied upon. Essential tasks may need to remain available without a continuous connection, while non-essential updates can be synchronized later. Interfaces may require text-light, localized, or multimodal alternatives where these are supported by user research. Yet connectivity-resilient design cannot resolve all exclusion risks. Farmers may remain excluded through income, social position, disability, limited control over devices, distrust, or lack of institutional support. Platform dependency and vendor lock-in create further risks when data cannot be exported, functions cannot be transferred, or service continuity depends on a single provider. Low-bandwidth and offline-first operation should therefore be combined with interoperability, understandable data controls, local support, and explicit inclusion and adoption boundaries [12].
Design science distinguishes between the problem being addressed, the requirements derived from that problem, the principles proposed to guide design, the artifact that instantiates those principles, and the evaluation needed to examine utility. A design principle should not be expressed as a broad aspiration such as “make the platform affordable” or “design for farmers.” It should specify the intended action, the mechanism through which the action is expected to address a problem, the users or implementers involved, the contextual conditions under which it may apply, and the boundaries of the resulting claim. For example, a modular architecture may permit components to be introduced or replaced incrementally, but this mechanism does not establish that the overall platform is affordable or scalable. Those properties require separate economic and implementation evidence [13].
Within agricultural systems, design science offers a way to connect complex practical problems with iterative artifact development. The process begins with problem relevance: the proposed artifact should address a consequential need identified in the intended context rather than a technical possibility selected in advance. Contextual evidence is then translated into functional requirements, such as access to farm records or advisory communication, and non-functional requirements, such as offline operation, accessibility, maintainability, privacy, and interoperability. These requirements guide architecture and interface decisions, but they must remain traceable to the problem evidence from which they were derived. Design utility is examined by determining whether intended users can perform relevant tasks under realistic conditions, not merely whether the software executes as specified [14].
Farmer-centered, human-centered, participatory, and co-design approaches can strengthen this logic by involving intended users in problem formulation, requirement definition, prototype interpretation, and revision. Participation is especially important where designers may otherwise rely on assumptions about farmer priorities, literacy, technology access, risk tolerance, or trusted sources of advice. Nevertheless, participation should not be treated as a ceremonial consultation or as proof that the resulting artifact has been approved by farmers. Meaningful co-design requires attention to representation, decision rights, facilitation, time, resources, and the extent to which participant input changes the artifact. It should also recognize differences among farmers rather than treating the most accessible participants as representatives of all intended users [15].
Artifact evaluation must be staged according to the maturity and claims of the design. Conceptual review can assess the coherence and completeness of requirements and principles. Architecture evaluation can examine modularity, interfaces, synchronization, security, and failure recovery. Usability assessment can examine task completion, comprehension, accessibility, error, and support needs. Implementation evaluation can investigate maintenance, advisory capacity, governance, cost, institutional fit, and sustained use. Field validation is required before claims are made about performance or utility under operational farming conditions. Evaluation findings should feed back into context mapping, requirements, architecture, interfaces, and boundary statements. Accordingly, the framework developed in this article is a conceptual design artifact and a structure for future evaluation; it is not an implemented system, validated platform, universal standard, or deployment-ready architecture [14].
Affordability should be treated as a contextual requirement rather than an inherent property of a low-cost device or simplified application. The relevant cost includes acquisition, connectivity, subscriptions, training, maintenance, repair, replacement, data entry, and the time required to obtain and interpret information. These burdens may be distributed differently among farmers, cooperatives, advisers, service providers, and public institutions. Farmer-centered design can help reveal which costs and tasks users regard as acceptable, which functions address meaningful priorities, and which forms of support are necessary. It also requires designers to recognize that farmers can participate as co-designers only when processes, resources, representation, and decision rights enable meaningful influence. Farmer involvement should therefore inform affordability requirements and configuration choices without being interpreted as evidence that a platform is affordable, accepted, or approved by all intended users [16].
Local usability begins before interface production. Designers must understand how farmers describe problems, organize tasks, interpret information, share devices, seek advice, and respond to uncertainty. Empathising, defining, and ideating with farming communities can expose differences between a technically convenient feature and a practically useful workflow. Interface decisions should reflect locally validated language, terminology, reading practices, numeracy, device capability, and accessibility needs. Text-light layouts, icons, audio prompts, voice interaction, or assisted workflows may reduce some barriers where locally appropriate, but each option can introduce new risks, including ambiguous symbols, transcription errors, privacy concerns, and dependence on external assistance. Usability must consequently be examined through representative task completion, comprehension, error recovery, and support requirements rather than visual simplicity alone [17].
Modularity can support incremental configuration by separating farm records, sensing, communication, analytics, advisory services, and external data connections into replaceable or optional components. A smallholder-oriented platform architecture may, for example, permit a farmer or supporting organization to begin with limited data capture and advisory functions before considering sensor or remote-sensing integration. Local processing and edge components may also reduce some dependence on continuous communication. Nevertheless, modularity is valuable only when module boundaries, data formats, interfaces, dependencies, and maintenance responsibilities are clearly specified. A platform described as customizable or cost-effective in one setting cannot be assumed to remain affordable, maintainable, interoperable, or scalable elsewhere. These properties require independent assessment under the intended institutional, economic, and infrastructural conditions [18].
Mobile and lightweight agricultural services further demonstrate that accessibility depends on more than technical availability. Perceived usefulness, ease of use, confidence, training, service reliability, and continuing support influence whether users can integrate an application into farming practices. Offline-first operation may preserve selected tasks during network interruption, while low-bandwidth modes, local storage, SMS, or voice channels may support alternative access where validated. However, these mechanisms can create synchronization conflicts, stale information, incomplete advice, data-security risks, or additional costs. Maintenance and repairability must also be planned through diagnostic procedures, replaceable components, documented interfaces, local support roles, and realistic access to parts. Table 1 summarises low-resource context conditions, connectivity constraints, design science logic, affordability requirements, modularity needs, and local usability requirements for smart farming platforms [19].
Table 1. Low-Resource Context Conditions and Design Requirements for Smart Farming Platforms: Smallholder Agriculture, Connectivity Constraints, Rural Infrastructure, Mobile Access, Offline-First Design, Low-Bandwidth Operation, Affordability, Modularity, Interoperability, Local Language Support, Low-Literacy Interfaces, Maintenance, Repairability, and Inclusion Boundaries
Context condition or design requirement | Core design problem | Required contextual understanding | Platform design response | Potential platform output | Failure or exclusion risk | Evaluation need | Framework role |
Smallholder farm heterogeneity | A standardized configuration may not match diverse production systems and priorities | Farm type, crops, livestock, labour, market relationships, risk, and decision practices | Create configurable workflows and context-specific requirement profiles | Locally bounded platform configuration | Misaligned functions and inappropriate recommendations | Relevance assessment across distinct farmer groups | Defines the primary adaptation context |
Resource-constrained farming | Platform demands may exceed available finance, time, equipment, or support | Capital availability, seasonal income, labour burden, and existing assets | Define minimum viable functions and optional modules | Staged functional configuration | Financial burden, underuse, or abandonment | Total-cost and operational-burden assessment | Establishes resource-feasibility requirements |
Rural infrastructure | Essential services may rely on unreliable electricity, networks, transport, or repair systems | Power access, coverage, charging, hosting, transport, and service availability | Map and minimize critical external dependencies | Infrastructure-aware architecture | Persistent downtime or inaccessible services | Dependency and uptime assessment | Defines implementation conditions |
Mobile access | Phone ownership may not equal private, continuous, or technically suitable access | Device type, sharing, storage, operating system, privacy, and charging | Support appropriate device diversity and secure shared-device workflows where validated | Mobile or assisted-access channel | Gendered, household, technical, or privacy exclusion | Access and task testing by device and user group | Defines access-channel choices |
Intermittent connectivity | Continuous online workflows may fail during essential tasks | Outage frequency, duration, latency, and synchronization opportunities | Provide local task completion, queuing, and delayed synchronization | Recoverable offline workflow | Lost transactions, conflicts, or stale records | Disconnection, recovery, and reconciliation testing | Supports offline-first operation |
Low-bandwidth operation | Data-heavy interfaces may be slow or unaffordable | Throughput, tariffs, device capacity, and task urgency | Use compressed payloads, text-first modes, and deferred media | Low-data communication mode | Incomplete information or unusable response times | Payload, latency, comprehension, and cost assessment | Establishes communication-efficiency requirements |
Electricity limitation where supported | Devices and local nodes may not remain continuously powered | Charging access, outage patterns, energy demand, and battery replacement | Use energy-aware operation and low-power components where appropriate | Extended functional availability | Device shutdown, battery degradation, or replacement burden | Energy-use, uptime, and replacement assessment | Constrains device and edge design |
Affordability | Initial price may conceal continuing and indirect costs | Acquisition, subscription, data, training, support, repair, replacement, and user time | Minimize avoidable costs and permit staged configurations | Context-specific cost profile | Exclusion, debt, discontinuation, or stranded equipment | Full-cost and continuation assessment | Defines a bounded affordability objective |
Cost transparency | Users may not understand the complete financial commitment | Pricing terms, service changes, connectivity costs, and maintenance responsibilities | Present all foreseeable cost categories in understandable form | Transparent cost statement | Hidden charges and underestimated operational burden | Cost verification and comprehension testing | Provides an accountability safeguard |
Incremental adoption | A complete system may require excessive initial commitment | Priority tasks, existing capacity, module independence, and upgrade conditions | Allow limited entry configurations and optional expansion | Staged adoption pathway | Early modules may provide insufficient value or create upgrade pressure | Utility and cost assessment at every stage | Supports gradual engagement without guaranteeing adoption |
Modularity | Monolithic systems are difficult to adapt, repair, or scale down | Functional dependencies, local priorities, and component availability | Separate functions through defined interfaces and replaceable modules | Core and optional platform modules | Hidden coupling or incompatible replacements | Isolation, integration, and replacement testing | Structures adaptable platform architecture |
Interoperability | Data and services may remain trapped in isolated components | Formats, identifiers, semantics, permissions, and external services | Use documented schemas and interfaces where feasible | Exchangeable data flows | Semantic mismatch, security exposure, or vendor dependence | Technical, semantic, and governance conformance testing | Connects platform components and external services |
Open interfaces where supported | Proprietary interfaces can restrict switching and local innovation | Licensing, security, governance, and implementation capacity | Provide documented exchange formats or controlled interfaces | Reduced integration and switching friction | Nominal openness or increased attack surface | Interface-access, security, and portability testing | Supports anti-lock-in objectives |
Local data storage where supported | Essential records may be unavailable during disconnection | Storage capacity, retention needs, device security, and backup options | Cache necessary records and queued actions locally | Local working dataset | Data loss, unauthorized access, or conflicting versions | Security, backup, storage, and recovery assessment | Enables selected offline functions |
SMS or lightweight messaging where supported | Smartphone applications may not reach all intended users | Basic-device use, messaging costs, literacy, and message length | Deliver concise alerts or service prompts through lightweight channels | Basic-device communication option | Oversimplification, delayed delivery, or message charges | Delivery, comprehension, privacy, and cost testing | Provides an optional access channel |
Voice interface where supported | Text dependence may exclude users with limited literacy | Language resources, acoustic conditions, privacy, and recognition accuracy | Offer spoken prompts, audio content, or assisted voice navigation | Voice-enabled interaction | Misrecognition, social discomfort, or confidentiality loss | Recognition, comprehension, privacy, and usability testing | Provides an optional accessibility mechanism |
Local language support | Dominant-language interfaces may misrepresent local concepts | Preferred languages, agricultural terminology, dialects, and advisory practices | Co-develop and validate localized terminology | Language-specific content and interface | Literal translation, ambiguity, or reduced trust | Farmer and adviser comprehension testing | Establishes linguistic accessibility |
Low-literacy interface support | Dense text and technical terminology may prevent task completion | Reading confidence, numeracy, icon familiarity, and support access | Use validated multimodal or assisted workflows | Reduced text-dependence | Ambiguous icons or concealed complexity | Task, error, and interpretation assessment | Addresses literacy-related exclusion |
Accessibility | Interfaces may exclude users with sensory, motor, or cognitive needs | User abilities, device constraints, and assistive practices | Provide readable, navigable, adaptable, and multimodal interaction | Accessibility specification | Exclusion of farmers with disabilities | Accessibility review and representative user testing | Integrates equity into interaction design |
Training and support | One-time onboarding may not sustain confident use | Existing skills, learning preferences, support actors, and recurring needs | Provide progressive guidance, documentation, and escalation routes | Training and continuing-support plan | Dependence on unavailable intermediaries | Skill retention, help use, and resolution assessment | Defines a non-technical implementation condition |
Maintenance | Hardware, software, and services may fail without assigned responsibility | Local skills, update procedures, funding, diagnostics, and service routes | Specify maintenance roles and fault-management processes | Maintenance plan | Extended downtime and platform abandonment | Service response, uptime, and update assessment | Supports operational continuity |
Repairability | Minor component failure may require whole-system replacement | Parts availability, documentation, tools, and local technical capacity | Use replaceable modules and documented diagnostic procedures | Repair pathway | Vendor dependency, waste, or prolonged service loss | Repair time, replacement success, and parts-access assessment | Supports maintainability and dependency reduction |
Farmer data control | Farmers may be unable to understand or manage collection and reuse | Data types, actors, purposes, permissions, and export needs | Provide understandable access, consent, correction, and export controls | Farmer-facing data-management functions | Nominal consent, surveillance, or loss of control | Control usability and governance audit | Establishes data-governance safeguards |
Inclusion boundary | Platform access may conceal exclusion among intended users | Gender, age, disability, income, language, social position, and device control | Conduct disaggregated access analysis and provide alternatives where feasible | Inclusion-risk profile | Structural exclusion despite technical access | Equity-focused and longitudinal evaluation | Prevents inclusion-by-availability claims |
Affordability boundary | Low-cost components may still produce an unaffordable service | Household, organizational, seasonal, and recurring cost evidence | Separate cost-reduction intentions from demonstrated affordability | Explicit affordability limitation | Unsupported affordability claims | Independent economic and continuation assessment | Limits interpretation of design intentions |
Scalability boundary | Modular architecture may not remain viable across sites or user volumes | Infrastructure, support, governance, service capacity, and contextual variation | Document scale assumptions, bottlenecks, and configuration limits | Scalability-condition statement | Service degradation or inappropriate transfer | Multi-site and organizational evaluation | Prevents modularity from being treated as proof of scale |
The first proposed principle is context-first platform design. Platform development should begin with a bounded account of the agricultural problem, intended users, farm diversity, infrastructure, institutions, knowledge networks, and supporting actors. The architecture should then reflect the data flows and decision functions required by this context. Smart farming data systems commonly connect sensing, storage, analytics, service providers, farm management, and decision support, making interoperability and clear actor responsibilities important. In low-resource settings, however, this general architecture must be reduced or reconfigured according to actual utility and capacity. Interoperability should therefore support exchange among justified modules without requiring every available technology, service, or dataset to be integrated [20].
The second principle is accessible modularity with incremental value. Each module should address a defined problem and remain understandable within the farmer’s or supporting organization’s workflow. Farm records, advisory communication, weather information, sensing, analytics, and market-related functions can be separated conceptually so that their costs, dependencies, and value can be evaluated independently. Data-management research involving smallholders demonstrates the importance of organizing fragmented records and information services around practical user needs. A modular platform may support this organization through shared identifiers, simple records, and bounded decision-support functions. Yet modules should not be added merely because they are technically connectable. Their inclusion must depend on contextual relevance, data availability, maintenance capacity, governance safeguards, and evidence that users can interpret the resulting output [21].
The third principle is farmer-controlled and governance-aware data use. A low-resource platform should make clear what data are collected, why they are required, who can access them, how long they are retained, whether they may be reused, and how farmers can obtain or transfer their records. Farmers’ reluctance to share data is not simply a communication problem; it can reflect uncertainty about ownership, control, contractual terms, commercial benefit, and legal protection. Design responses may include data minimization, understandable permissions, access logs, export functions, correction procedures, and differentiated controls for farmers, advisers, cooperatives, and service providers. These mechanisms may improve transparency, but they do not resolve all legal, economic, or bargaining asymmetries. Governance review must therefore accompany interface and architecture design [22].
The fourth principle is maintenance-aware, support-integrated, and feedback-enabled design. Platform transparency should extend beyond data terms to the provenance of advice, limits of automated outputs, responsibilities for maintenance, and procedures for reporting errors. Trust cannot be inferred from system availability or technical sophistication. It is influenced by whether users understand how information and data are handled, whether expected benefits are credible, and whether problems receive accountable responses. The combined principle set therefore links context-first and farmer-centered design with offline-first operation, low-bandwidth communication, affordability transparency, modularity, interoperability, local usability, advisory support, data governance, maintenance, and iterative evaluation. Figure 1 synthesises the design principles for low-resource smart farming platforms, linking context-first design, offline-first operation, affordability, modularity, local usability, advisory integration, data governance, maintenance, and feedback-enabled improvement [23].
Figure 1. Design Principles for Low-Resource Smart Farming Platforms
Alt-text description:
A conceptual design-principle map showing low-resource smart farming platform requirements such as smallholder context, connectivity constraints, affordability, modularity, offline operation, low-bandwidth communication, usability, advisory integration, data governance, maintenance, and farmer feedback.
The proposed framework begins with low-resource problem definition and contextual mapping. Designers first identify the practical problem, its consequences, and the users or institutions affected without assuming that a digital platform is the necessary solution. Smallholder context mapping then records relevant farm types, livelihoods, production systems, decision practices, languages, skills, device access, infrastructure, advisory relationships, and exclusion risks. Stakeholder mapping identifies farmers, advisers, extension services, cooperatives, platform operators, data stewards, local technicians, and public or private institutions. This contextual layer treats the platform as part of a digital innovation ecosystem in which technical modules, organizational arrangements, business relationships, and governance mechanisms influence one another. Its purpose is to ensure that artifact design remains connected to problem relevance and multi-actor implementation conditions [24].
The second component is constraint assessment and requirement definition. Connectivity and infrastructure assessment records network interruptions, bandwidth limitations, data costs, electricity dependencies, device conditions, hosting arrangements, and maintenance access. Affordability assessment identifies acquisition, recurring, training, repair, replacement, and user-time costs. Digital inclusion assessment considers language, literacy, disability, gender, age, device control, income, and reliance on intermediaries. These findings are converted into traceable design requirements. A reference-architecture approach can distinguish common components from context-dependent variation points, allowing core data, identity, synchronization, and governance functions to be separated from optional sensing, remote-sensing, advisory, marketplace, or analytics modules. This architectural logic supports adaptation, but it does not establish affordability, interoperability, or scalability until those properties are evaluated in the intended setting [25].
The third component is platform artifact design. The conceptual artifact combines modular architecture, offline-first operation, low-bandwidth communication, local usability, accessibility, advisory integration, data governance, and maintenance planning. Core tasks should be prioritized according to their relevance under disconnected conditions. Local storage and delayed synchronization may support essential records, while lightweight messaging or voice interaction may supplement application-based interfaces where locally appropriate. Advisory integration specifies when information can be used directly, when human interpretation is required, and how users can request clarification or report problems. The design must also identify which modules are unnecessary in a given setting. Evidence concerning digital tools for African smallholders remains heterogeneous, and attribution of farm-level outcomes is often incomplete. The framework therefore requires local validation rather than assuming that a function successful in one context will deliver similar value elsewhere [26].
The fourth component is governance, support, and implementation-condition review. Data collection should be limited to specified functions, and farmer-facing controls should make access, sharing, reuse, correction, retention, and export understandable. Privacy and security requirements should be proportionate to the data and risks involved, while platform dependency and vendor lock-in should be examined through portability, interface documentation, service continuity, and exit arrangements. Critical analysis of agricultural platformization shows that access to a digital platform can coexist with surveillance, data extractivism, unequal benefit distribution, and limited farmer control. Consequently, the framework does not equate digital participation with inclusion. Governance safeguards, local capacity, maintenance arrangements, training, adviser availability, and organizational accountability are required implementation conditions rather than automatic consequences of platform architecture [27].
The final component is artifact evaluation, feedback, iteration, and claim control. Evaluation is staged from conceptual coherence and architecture testing to usability, accessibility, synchronization, security, maintenance, affordability, governance, implementation, and field assessment. Farmer and intermediary feedback should be recorded as traceable evidence for revising context maps, requirements, modules, interfaces, and boundary statements. The design cycle remains open because infrastructure, service providers, costs, user practices, and institutional responsibilities can change. The framework explicitly retains no-affordability, no-inclusion, no-adoption, no-scalability, and no-deployment-readiness boundaries until appropriate evidence is generated. Table 2 presents the proposed design science framework for low-resource smart farming platforms.
Table 2. Proposed Design Science Framework for Low-Resource Smart Farming Platforms: Problem Definition, Smallholder Context Mapping, Connectivity Assessment, Affordability Assessment, Digital Inclusion, Modular Architecture, Offline-First and Low-Bandwidth Design, Local Usability, Advisory Integration, Data Governance, Maintenance Planning, Artifact Evaluation, Farmer Feedback, Iteration, and Claim Boundaries
Framework stage | Core purpose | Required input | Design science function | Potential output | Evaluation or assessment need | Failure risk | Feedback mechanism | Decision boundary |
Low-resource problem definition | Establish a consequential problem without presupposing a digital solution | Farmer, adviser, institutional, infrastructure, and production evidence | Define problem relevance | Bounded problem statement | Stakeholder validation of importance and scope | Technology-first problem construction | Revise the problem statement after contextual review | Do not proceed when problem relevance is unsubstantiated |
Smallholder context mapping | Represent heterogeneous farms, users, livelihoods, and practices | Farm systems, production goals, risk, assets, labour, markets, and local knowledge | Define contextual variables and variation points | Smallholder context profile | Assess representation across intended user groups | Treating smallholders as a uniform category | Add missing profiles and contextual distinctions | No universal smallholder-user assumption |
Stakeholder and user mapping | Identify affected users, intermediaries, maintainers, and decision-makers | Farmers, advisers, cooperatives, extension services, providers, technicians, and institutions | Define roles, relationships, and influence | Stakeholder and responsibility map | Representation and power assessment | Omitting less visible or less powerful groups | Periodically revise roles and participation pathways | Participation does not demonstrate equal influence |
Connectivity and infrastructure assessment | Determine which technical dependencies are feasible | Coverage, outages, bandwidth, electricity, devices, hosting, charging, and repair access | Constrain architecture and service assumptions | Infrastructure dependency profile | Measurement under realistic operating conditions | Designing for continuous services that do not exist | Feed observed failures into requirement revision | No continuous-connectivity assumption without evidence |
Affordability assessment | Identify the complete financial and operational burden | Acquisition, data, subscription, training, repair, replacement, and user-time costs | Define cost-related requirements and alternatives | Context-specific total-cost profile | Household, cooperative, provider, or institutional affordability analysis | Hidden, transferred, or underestimated costs | Reconfigure modules and support arrangements | Intended cost reduction does not prove affordability |
Digital inclusion assessment | Identify groups, capabilities, and circumstances associated with exclusion | Gender, age, disability, literacy, language, income, device control, and social position | Define accessibility and alternative-channel requirements | Inclusion-risk profile | Disaggregated access, task, and participation evaluation | Technical access concealing structural exclusion | Add validated access channels or support measures | Platform availability does not prove inclusion |
Platform requirement definition | Translate contextual evidence into testable functions and safeguards | Problem, context, infrastructure, affordability, inclusion, and governance findings | Specify functional and non-functional requirements | Traceable requirement register | Requirement-to-evidence and requirement-to-test audit | Vague, contradictory, or unsupported requirements | Controlled revision after evaluation | Unsupported requirements must be removed or identified as proposals |
Modular architecture design | Separate core services from optional or replaceable components | Functional dependencies, data flows, integration needs, and maintenance capacity | Structure the design artifact | Core modules, optional modules, and interface specification | Coupling, integration, replacement, and failure-isolation testing | Hidden dependencies and nominal modularity | Revise interfaces and module boundaries after testing | Modularity does not establish scalability |
Offline-first and low-bandwidth design | Preserve prioritized functions during disconnection or limited throughput | Task criticality, storage, synchronization, payload, and recovery requirements | Instantiate connectivity-resilience mechanisms | Offline workflows and low-data mode | Interruption, latency, conflict, and recovery testing | Data inconsistency, stale outputs, or incomplete advice | Use synchronization and task-failure logs | Offline capability does not prove utility or safety |
Local usability and accessibility design | Align interaction with language, literacy, devices, abilities, and work practices | User research, task analysis, accessibility needs, and local terminology | Instantiate farmer- and human-centered interaction | Localized and accessible prototype | Task completion, comprehension, error, burden, and accessibility testing | Superficial simplicity or unvalidated localization | Iterative farmer and support-actor feedback | No usability claim without representative evaluation |
Advisory integration design | Connect platform outputs with qualified interpretation and escalation | Advisory roles, institutional capacity, decision risk, and response pathways | Define hybrid digital–human service logic | Advisory referral, shared-record, and escalation workflow | Handoff, response, accountability, and workload assessment | Unclear responsibility or unmanageable adviser demand | Adviser and farmer review of cases and failures | Digital outputs must not be framed as autonomous advice without evidence |
Data governance and privacy review | Define justified collection, access, reuse, protection, and farmer control | Data inventory, purposes, actor roles, permissions, retention, and threats | Specify governance and protection mechanisms | Data-governance and security specification | Consent comprehension, access-control, privacy, security, and accountability assessment | Extractive practices, nominal consent, or unauthorized access | Complaint, incident, access, and correction review | No farmer-control or security claim without usable and tested mechanisms |
Maintenance and support planning | Establish how services remain operational | Skills, parts, funding, update processes, documentation, and support actors | Specify non-artifact implementation requirements | Maintenance, repair, training, and support plan | Uptime, serviceability, response, and capacity assessment | Abandonment after routine failures | Maintenance logs and support-user feedback | Architecture alone does not demonstrate operational sustainability |
Artifact evaluation planning | Match each design claim to appropriate evidence | Requirements, artifact maturity, risks, and intended use | Define staged evaluation | Claim-to-test evaluation protocol | Conceptual, technical, usability, governance, implementation, and field assessment | Premature claims based on inadequate measures | Revise the artifact and claim scope after results | Conceptual assessment cannot substitute for field validation |
Farmer feedback and iteration | Incorporate user experience into traceable revisions | Structured feedback, observed use, errors, non-use, and support requests | Operate the iterative design cycle | Revised requirements, interfaces, modules, and support arrangements | Representativeness and response-quality assessment | Extracting feedback without visible change or benefit | Maintain a transparent change log | Feedback collection does not prove farmer approval |
Implementation-condition review | Determine whether institutional and operational dependencies are available | Advisory, training, finance, governance, infrastructure, maintenance, and support evidence | Connect the artifact to its operating environment | Implementation-condition register | Multi-actor feasibility and continuity assessment | Attributing structural deficiencies to individual users | Periodic review of external dependencies | Do not recommend implementation when critical conditions are absent |
Framework updating | Revise principles and boundaries as evidence and conditions change | Evaluation findings, incidents, failures, contextual variation, and stakeholder feedback | Accumulate bounded design knowledge | Updated framework and applicability statement | Version, evidence, and unresolved-risk audit | Treating the framework as fixed or universal | Formal review and revision cycle | Updated principles remain provisional until evaluated |
No affordability-guarantee boundary | Prevent lower-cost design intentions from becoming empirical affordability claims | Independent cost, income, continuation, and burden evidence | Bound interpretation | Affordability caveat | Economic and sustained-use assessment | Unsupported “affordable platform” claims | Update cost assumptions and configurations | The framework cannot prove affordability |
No inclusion-guarantee boundary | Prevent accessible features from becoming proof of inclusion | Disaggregated access, benefit, exclusion, and control evidence | Bound interpretation | Inclusion caveat | Equity-focused and longitudinal evaluation | Invisible exclusion or unequal benefit | Revise channels, governance, and support | The platform cannot resolve structural inequality alone |
No adoption-guarantee boundary | Prevent usability or availability from becoming proof of sustained adoption | Longitudinal use, discontinuation, adaptation, and non-use evidence | Bound interpretation | Adoption caveat | Sustained-use and non-use assessment | Overclaiming from intentions or initial trials | Investigate and respond to non-use | Design principles cannot guarantee adoption |
No scalability-guarantee boundary | Prevent modularity from becoming proof of viable expansion | Multi-site infrastructure, support, governance, cost, and performance evidence | Bound interpretation | Scalability caveat | Cross-context and organizational-scale evaluation | Service failure or inappropriate replication | Update scale assumptions and bottlenecks | Scalability remains an empirical question |
No deployment-readiness boundary | Prevent conceptual coherence from being treated as operational readiness | Field performance, reliability, safety, governance, maintenance, and support evidence | Establish final maturity control | Deployment-readiness gap statement | Independent multi-domain readiness assessment | Premature operational use | Reassess after required evidence is generated | The proposed framework does not establish deployment readiness |
Figure 2 presents the proposed design science framework for low-resource smart farming platforms, integrating problem definition, smallholder context mapping, connectivity assessment, affordability assessment, platform requirements, modular architecture, local usability, governance, evaluation, farmer feedback, and framework updating.
Figure 2. Design Science Framework for Low-Resource Smart Farming Platforms
Alt-text description:
A conceptual design science framework showing stages from low-resource problem definition and smallholder context mapping through connectivity assessment, affordability and inclusion assessment, modular and offline-first platform design, usability, advisory integration, data governance, evaluation, farmer feedback, and framework updating.
For farmers, advisers, extension services, and cooperatives, the framework provides a structure for identifying which platform functions correspond to actual problems and what forms of support are necessary before implementation is considered. Farmer-centered evaluation should examine whether intended users can understand and complete core tasks, question platform outputs, manage permissions, recover from errors, and obtain assistance. Extension and cooperative actors should be evaluated as potential participants in hybrid advisory, training, maintenance, or shared-access arrangements only where their capacity, legitimacy, and resources support those roles. Participatory processes can help reveal local priorities and exclusion risks, but future studies should examine whose views are represented, how disagreements are handled, and whether farmer input results in traceable design changes [15].
For platform developers, technology providers, and data stewards, the framework emphasizes low-bandwidth usability testing, offline recovery, modularity verification, cost transparency, data portability, maintenance planning, and understandable governance controls. Future research should compare core and optional module configurations without assuming that more integration produces greater utility. It should investigate synchronization failures, device sharing, local-language comprehension, low-literacy interaction, accessibility, data-cost burden, repair pathways, and continuing support. Longitudinal research is particularly important because initial usability or adoption intention may not predict sustained use, adaptation, discontinuation, or dependence on intermediaries. Mobile availability should not be treated as a sufficient indicator of reach, inclusion, or service value [19].
For researchers, public institutions, and policymakers, the framework identifies evidence needs rather than prescribing a universal intervention, procurement model, subsidy, platform, or governance arrangement. Comparative studies are needed to examine affordability across different cost-bearing arrangements, interoperability across modules and providers, data-control usability, maintenance capacity, advisory workloads, and distributional effects. Research should also examine whether platform ecosystems create switching barriers, surveillance risks, asymmetric benefit sharing, or new forms of exclusion. These implications are conceptual research directions rather than agronomic advice, legal advice, policy instructions, donor-programme guidance, platform-selection recommendations, development-project plans, or deployment procedures. Local validation and accountable governance remain necessary before any context-specific operational decision is made [27].
This article developed a conceptual design science framework for low-resource smart farming platforms that connects smallholder context, connectivity and infrastructure constraints, affordability, modularity, interoperability, local usability, advisory integration, data governance, maintenance, evaluation, farmer feedback, and framework updating. Its central proposition is that low-resource agricultural platforms should be designed from contextual requirements rather than transferred directly from high-resource digital agriculture models. Offline-first operation, low-bandwidth communication, incremental adoption, accessible interfaces, modular architecture, farmer data control, and local support may contribute to more appropriate artifact designs, but none independently establishes affordability, inclusion, adoption, scalability, sustainability, or deployment readiness. These outcomes require staged and locally grounded assessment of utility, cost, accessibility, reliability, repairability, governance, institutional capacity, and sustained implementation. The framework therefore offers bounded design knowledge and an evaluation structure rather than a universal platform standard or operational prescription.
None
None
None
None
Open Access The author(s) retain copyright. This article is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. It may be shared and adapted for non-commercial purposes with appropriate attribution, an indication of changes, and distribution of adaptations under the same license. Third-party material may be subject to separate terms identified in its credit line. View the license at https://creativecommons.org/licenses/by-nc-sa/4.0/.
Agro Intelligence Research Press
