Farm-Well is an AgriTech MVP designed by Softech around three connected layers: a digital model of farms, crops and certificates; a mobile application with progression mechanics; and an incentive economy based on XP, rewards, fatigue and events. A certificate acts as a digital domain object that can reference a farm, crop and production cycle. The gameplay layer represents selected agricultural actions and events through an engaging consumer interface. The project remains classified as an MVP. Its architecture leaves room for future tokenization, but P1-I deliberately separates that option from the implemented scope and does not present blockchain, a financial token, retention growth or farm financing as verified outcomes.
Business context and the situation before implementation
Consumer products around agriculture need to translate physical processes into understandable digital interactions without losing the connection to real-world context. Farm-Well explores a model where a user does more than read about crops: they have a digital reference object in the form of a certificate and participate in a designed activity loop.
- Agriculture operates on long cycles while a mobile application needs more frequent interaction points.
- A digital certificate needs a clear relationship to a farm, crop and cycle independently of tokenization technology.
- Game mechanics need to create engagement without pretending that the user directly controls real agronomic processes.
- The game economy needs coherent sources of rewards, activity costs and progression.
- The MVP should allow the product model to be tested before adding an expensive blockchain or token-economics layer.
Before state
The starting point was not an existing system to reimplement, but a concept that required the agricultural domain, digital certificate and game mechanics to be organized into one coherent MVP model. Without that product layer, it would have been easy to build three disconnected modules without a shared lifecycle.
- No shared model for farm, crop, cycle and certificate.
- No defined user-activity loop between longer stages of a crop cycle.
- No explicit progression, reward, fatigue and event rules.
- An undefined boundary between a digital certificate and future tokenization.
- Risk of confusing gamification with a claim of direct agronomic impact.
Goals, success criteria and constraints
Discovery focused on separating domain facts from mechanics designed to engage the user. The key decision was to treat the certificate as a digital application object and design the game economy independently from any potential future tokenization.
Product goals
- Build one domain model connecting farm, crop, cycle and digital certificate.
- Translate long agricultural cycles into understandable mobile progression mechanics.
- Design an incentive economy covering XP, rewards, activity costs and fatigue.
- Separate deterministic product state from random events and system reactions.
- Deliver a mobile and backend MVP without making blockchain a prerequisite.
- Leave a technical path for future tokenization without describing it as an active feature.
- Keep the model extensible for additional crop types, farms and mechanics.
Success criteria
- A certificate can be explicitly associated with farm, crop and cycle records in the application model.
- User game state is persistent and separated from presentation.
- Progression, XP, rewards and fatigue follow explicit domain rules.
- Events can be handled without rewriting the entire game lifecycle.
- The mobile app and backend use shared data contracts.
- The MVP works without an active blockchain or economic token.
- Future tokenization can be analysed as an extension rather than a migration of the entire certificate model.
Long agricultural cycle
Crop processes do not match typical mobile-game frequency, so the digital layer needs its own interaction points without pretending to accelerate real biology.
Real-world versus game boundary
A symbolic user action cannot be described as directly controlling a real crop when project materials do not support that claim.
Economy balancing
XP, rewards, fatigue and event frequency affect user behaviour and require a shared model rather than independent point systems.
MVP scope
The project required excluding capabilities that were not necessary to test the core mobile + certificates + game-logic model.
Web3 as an option
Architectural readiness is not equivalent to an implemented blockchain, issued token or active financial economy.
Analysis and product decisions
- Mapping farm, crop, cycle, certificate and user entities.
- Separating real agricultural context from symbolic game state.
- Designing activity, progression and reward loops.
- Defining activity costs, fatigue and recovery.
- Designing random events and how they affect game state.
- Defining the minimum certificate scope required for the MVP.
- Establishing the boundary between a digital certificate and future tokenization/Web3.
Solution architecture
The architecture separates the mobile application, API, persistent domain model and event-based game logic. Farms, crops and certificates remain domain data, while progression, XP, fatigue and events form a separate game-state layer. This means a future certificate extension does not require blockchain to be mixed into the core product lifecycle.
- 01L1 · Experience
Mobile application
React Native / Expo presents farms, certificates, progression and user interactions in a mobile-first experience.
React NativeExpoTypeScript - 02L2 · API
Application backend
Node.js / NestJS handles API contracts, authorization, application logic and state-change coordination.
Node.jsNestJSTypeScript - 03L3 · Domain
Farms, crops and certificates
PostgreSQL and Prisma maintain the persistent farm, crop, cycle, certificate and user model.
PostgreSQLPrisma ORM - 04L4 · Game state
Progression and incentive economy
XP, reward, fatigue and activity rules form game state separated from agricultural domain data.
Game Logic EngineTypeScript - 05L5 · Events
Events and reactions
An event-based architecture supports random events and system reactions without coupling every mechanic to one screen.
Event-based Architecture - 06L6 · Assets
Media and assets
S3 / Blob Storage stores visual assets required by the application and product content.
S3Blob Storage
Problems, decisions and implemented capabilities
Certificates and agriculture could remain loosely connected concepts.
Build an explicit certificate → farm → crop → cycle relationship model.
A digital certificate has domain context without requiring a blockchain token.
The model can evolve independently from future tokenization technology.
A long crop cycle provides too few natural interactions for a mobile product.
Add progression and activity mechanics between cycle stages.
XP, rewards, fatigue and activities create a more frequent product rhythm.
The MVP has a designed engagement loop without claiming measured retention growth.
Random events can lead to chaotic conditional logic.
Separate events from the core state model.
An event-based architecture handles bonuses, risks and reactions as separate events.
New event types can be designed without rewriting the entire mobile application.
The game economy could have been reduced to a single points counter.
Connect reward sources with activity costs, fatigue and progression.
The model covers XP, rewards, fatigue and rules for further progression.
Mechanics form an incentive system that can be balanced as a whole.
Adding blockchain too early would increase MVP complexity before the need is validated.
Keep the certificate as an application object and leave tokenization as a later option.
The core lifecycle works without blockchain while the certificate model can be extended later.
The MVP tests the core product proposition without the cost and dependency of additional Web3 infrastructure.
The real-world layer could be presented as undocumented financial or agronomic impact.
Describe the supported data model and interpretation boundaries rather than promise farm outcomes.
A certificate can store a relationship to a farm, crop and cycle as product data.
The case study presents real-world agriculture as domain context rather than an unverified economic outcome.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| React Native + Expo | Mobile application | One product codebase supports a mobile-first experience and fast MVP iteration. | Advanced native capabilities still require deliberate management of Expo and platform boundaries. |
| Node.js / NestJS | API and application logic | A modular backend separates the certificate domain from game mechanics and integrations. | Requires explicit module boundaries so game logic does not leak into API controllers. |
| PostgreSQL + Prisma | Persistent domain model | A relational model fits relationships among farms, crops, cycles, certificates, users and game state. | Model changes require controlled migrations as mechanics evolve. |
| Event-based architecture | Game events and reactions | Separates an event from all of its effects and supports modular mechanics. | Debugging flows requires good logs and explicit event contracts. |
| S3 / Blob Storage | Visual assets and media | Separates product assets from relational data and allows independent file lifecycle management. | Requires access, cleanup and asset-versioning policies. |
| TypeScript | Domain and mechanics contracts | Explicit types reduce ambiguity around certificate, progression and event states. | Strict contracts require updates whenever the domain model changes. |
Integrations and data flows
Farm and crop data
data source → Farm-Well backendAssociate certificates with farm, crop and cycle records in the product model.
Coverage and ingestion depend on the source; the case study does not assume automatic farm-system integration unless documented.
Mobile application ↔ API
bidirectionalSynchronize certificates, profile, progression and game state.
API contracts and state validation reduce inconsistencies between the mobile client and backend.
Object storage
backend → storage → applicationHandle images, media and content assets required by the mobile experience.
Asset access is separated from domain data; lifecycle and access-control rules are required.
AI, security and reliability
User authorization
JWT / Cookie Auth separates user state and protects operations that require authentication.
Game-state validation
The backend should remain the source of truth for activity costs, progression and resulting state changes rather than trusting only the mobile client.
Event idempotency
Events and rewards need safeguards so replaying the same operation does not apply the effect multiple times.
Persistence
Persistent certificate and game-state storage allows the current state to be restored after the application restarts.
Web3 boundary
No active blockchain in the MVP avoids additional key, smart-contract and irreversible-operation risks at the current stage.
Implementation, testing and release
- 101 · Discovery and domain
Define the agricultural product model and MVP boundary
- Farm / crop / cycle / certificate entity map
- User and digital-certificate model
- Digital certificate vs future tokenization boundary
Result: A domain core independent from gamification and blockchain was established.
- 202 · Mechanics and economy
Design the engagement loop and incentive system
- Progression and XP
- Rewards, activities and fatigue
- Random events and reaction rules
Result: Mechanics were combined into one game-state model rather than a collection of independent counters.
- 303 · Mobile + API MVP
Deliver the core user experience and persistent backend
- React Native / Expo application
- Node.js / NestJS backend
- PostgreSQL / Prisma persistence
Result: The MVP can handle certificates, user state and game state without additional Web3 infrastructure.
- 404 · Event model
Separate events and reactions from the core lifecycle
- Event contracts
- Random bonuses and risks
- Effect handling in game state
Result: Additional events can be developed modularly without extending every mobile flow.
- 505 · Stabilization and roadmap
Prepare the MVP for product testing and further expansion
- Validation of key states
- MVP-boundary documentation
- Roadmap for future tokenization and extensions
Result: The product retains a Web3 evolution path without presenting that layer as an implemented part of the MVP.
Certificate-state tests
Tests cover certificate relationships with farm, crop and cycle records and behaviour when key domain fields change.
Progression tests
Scenarios cover XP, rewards, activity costs and fatigue and how those values affect later actions.
Events and replay
The event-based workflow is checked for event replay, missing data and correct effect application.
Mobile / backend synchronization
Tests cover application refresh, state re-fetch and avoiding local values as the only source of truth.
Product-communication boundaries
Content review separates the MVP, digital certificates and future Web3 so blockchain, financial tokens or KPIs are not published without evidence.
What confirms the project description
The repository contained earlier values for retention, session duration, repeat gameplay and churn, but did not include a baseline, measurement period or approved analytics source. P1-I removes those KPIs from public presentation. The documented outcome is the verified MVP scope and architecture model, while behavioural, farm or economic impact requires a separate data set.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| Farm-Well uses a separated architecture for the mobile application, backend, agricultural domain and game state. | architecture diagram | FW-01 · diagram based on the project scope | Confirmed in the product | The diagram shows logical responsibility boundaries; it is not a performance measurement or production-scale claim. |
| A digital certificate is modelled as an application object associated with a farm, crop and cycle. | domain model | FW-02 · certificate relationship model | Confirmed in the product | The relationship model does not prove automatic integration with a specific farm system or active blockchain tokenization. |
| The gameplay layer includes activities, XP, rewards, fatigue, progression and events. | mechanics diagram | FW-03 · activity and game-state loop | Confirmed in the product | The mechanics confirm functional scope but do not prove earlier percentage retention-growth claims. |
| Farm-Well designs its incentive economy as a system of reward sources, activity costs, limits and progression. | product-economy model | FW-04 · incentive-economy diagram | Confirmed in the product | This is an in-product incentive economy, not evidence of issuing or trading a financial token. |
| Events in the game logic are treated as a separate reaction layer above domain state. | event-based architecture diagram | FW-05 · event and reaction model | Confirmed in the product | The diagram documents logical architecture rather than concrete event-system throughput. |
| The documented MVP works without an active blockchain layer, while Web3 is treated as a future architectural option. | scope boundary | FW-06 · MVP versus future Web3 diagram | Confirmed | Extension readiness does not mean an implemented smart contract, issued token or live on-chain economy. |
How to read this information
- No public baseline supports attributing percentage retention growth to Farm-Well.
- No complete analytics data set supports publishing a session-duration multiplier.
- A farm relationship model is not by itself evidence of farm financing or improved farm outcomes.
- A digital certificate in the MVP is not automatically a blockchain token.
- Web3-ready means an architectural extension path, not evidence of a live smart contract or token.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Agricultural model | Farm, crop and certificate concepts without one shared application structure. | An explicit farm → crop → cycle → digital-certificate model. | The domain can evolve and integrate independently from game mechanics. |
| Engagement | A long agricultural cycle with few natural interaction points. | A designed activity loop based on progression, XP, rewards and fatigue. | The MVP has a mechanism for more frequent interaction without claiming unverified retention growth. |
| Events | Risk of complex conditional logic embedded in screens. | An event-based model separating an event from its reactions and game state. | New events can be designed more modularly. |
| Certificate | An unclear relationship between a digital certificate and tokenization. | The certificate operates as a domain object; Web3 is a future extension option. | The MVP is not dependent on additional blockchain infrastructure. |
| Game economy | Points and rewards could operate as independent counters. | XP, rewards, activity costs, fatigue and progression are designed as one system. | Mechanics can be balanced as an incentive economy rather than a feature list. |
| Product communication | Risk of mixing the MVP, real-world impact and future Web3 in one claim. | Each layer has a separate status and evidence boundary. | The case study can show innovation without overstating technological or business outcomes. |
Digital certificate without active blockchain
- Alternative
- Build tokenization and smart contracts in the MVP.
- Trade-off
- Less Web3 in the first version, but lower complexity and faster validation of the core model.
- Rationale
- MVP value comes from the domain, mobile experience and mechanics rather than the blockchain ledger itself.
Incentive economy instead of a simple points counter
- Alternative
- One points counter and linear progression.
- Trade-off
- More balancing rules and tests for dependencies among mechanics.
- Rationale
- Rewards, activity costs and fatigue become meaningful as one behavioural system.
Event-based game logic
- Alternative
- Handle every event directly in screens and endpoints.
- Trade-off
- Greater need for observability and event-flow tracing.
- Rationale
- Modular events better support new mechanics and randomness.
Symbolic gamification instead of claims of farm control
- Alternative
- Present every game action as a direct action on a real crop.
- Trade-off
- Less spectacular marketing, but alignment with the documented scope and lower risk of misleading claims.
- Rationale
- Digital mechanics should describe what the system actually controls.
Key lessons learned
- A digital economy starts with incentive and cost rules rather than issuing a token.
- A digital certificate can have domain value without blockchain.
- Real-world agriculture and gamification require an explicit boundary between physical context and symbolic interaction.
- Long domain cycles need additional activity points when the product is designed as a mobile experience.
- Event-based architecture simplifies random-event evolution but requires observability.
- An MVP should test the core user–certificate–mechanics relationship before expanding infrastructure.
- Web3-ready should not be used as a synonym for implemented tokenization.
Which organisations this model is relevant for
AgriTech and FoodTech
Products connecting farm, crop or production data with a digital user experience.
Gamified consumer platforms
Applications that need progression, rewards, activity costs and events rather than a single points system.
Digital certificate products
Systems building a digital object linked to real domain context independently of blockchain technology.
Digital economies and incentive systems
Products where user behaviour is shaped by rewards, costs, limits and progression.
MVPs with a later Web3 option
Teams that want to validate product value first and decide on tokenization or blockchain later.
Related expertise and services
Mobile app development
Design and development of mobile applications for products with custom domain logic.
Web application development
Backends, portals and platforms supporting complex product workflows.
MVP and product development
Scope definition, discovery and iterative development of new digital products.
Token engineering and digital economies
Economy, incentive and tokenization design when the product model actually requires it.
React Native
Cross-platform mobile development for interaction-rich applications.
Node.js
Backend and logic for event-driven systems and mobile applications.
KILOGRAM — AgriTech marketplace
A production agricultural marketplace showing a different model of AgriTech digitization.
Farm-Well — gamified AgriTech article
A deeper explanation of product decisions around gamification, certificates and the mobile experience.
Designing a product where incentives matter?
We can help define the domain, activity loops, game economy and boundaries for future tokenization before expensive infrastructure starts dictating the product model.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
Softech designed Farm-Well as an AgriTech MVP combining a mobile application, digital certificates and gamification mechanics.
- 2
Farm-Well uses a domain model covering farms, crops, production cycles and digital certificates.
- 3
The digital certificate in the documented MVP is not presented as an active blockchain token.
- 4
Farm-Well's architecture leaves room for future tokenization without making Web3 a prerequisite for the core product.
- 5
The gamification layer includes progression, XP, rewards, fatigue and random events.
- 6
Farm-Well uses React Native / Expo for the mobile application and Node.js / NestJS for the backend.
- 7
PostgreSQL and Prisma maintain persistent domain data and state.
- 8
The project uses an event-based architecture to separate events from reactions in the game logic.
- 9
Farm-Well remains classified by Softech as an MVP rather than a live-production system.
- 10
P1-I does not publish earlier percentage retention, churn or session-duration KPIs without a baseline and analytics source.
- 11
The case study does not present the farm and crop data model as evidence of financing or improved outcomes for specific farms.
- 12
Farm-Well's economy is described as a product incentive system: XP, rewards, activity costs, fatigue and progression.
- 13
Future Web3 is treated as an architectural option rather than an implemented smart contract or issued token.
- 14
Farm-Well demonstrates how Softech can design a digital economy before any potential tokenization layer is added.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
What is Farm-Well?
Farm-Well is an AgriTech MVP combining a mobile application, digital crop certificates, a farm and production-cycle model, and gamification mechanics.
Are Farm-Well certificates blockchain tokens?
Not in the scope documented by this case study. A certificate is a digital application-domain object. The architecture leaves room for future tokenization, but an active blockchain layer is not presented as part of the implemented MVP.
How does the game economy work?
The model includes progression, XP, rewards, fatigue and random events. These mechanics are designed to create understandable activity loops and consequences for user decisions.
How does Farm-Well connect to real-world agriculture?
The domain model can associate a digital certificate with a farm, crop and production cycle. Public materials are not used as proof of independently measured financing or operational outcomes for a specific farm.
Is Farm-Well a live production product?
No. Softech currently presents the project as an MVP, so the case study does not attribute production scale or undocumented performance KPIs to it.
Can the architecture be extended?
Yes. Separating the domain model, game logic, persistence and events allows additional mechanics, certificate types and future integrations without making blockchain a prerequisite for the core MVP.
