Muktinath Krishi

Problem

Farmers needed a unified platform for agricultural guidance, crop-care content, e-commerce workflows, market price information, location-based dealer/shop discovery, notifications, community interaction, and crop disease support. The system brought multiple agriculture-related workflows into a mobile-first product experience backed by Laravel services.

Users

Farmers, agricultural customers, dealers/shops, community users, and internal/admin users depending on the module.

My Role

Prajesh worked on the Laravel backend and Flutter mobile client, contributing to backend modular architecture, API integration, mobile feature development, state management, real-time chat client integration, location workflows, notification integration, local caching, encrypted local storage, e-commerce flows, and Android release automation.

Architecture

The backend is a modular Laravel application organized around agriculture domains, using Repository and Action patterns, a custom Artisan scaffolding command to standardize CRUD module generation, and case-conversion middleware so the backend's PHP snake_case and the Flutter client's camelCase conventions coexist cleanly. MySQL is the database. The Flutter mobile client uses BLoC/Cubit for state management and Dio as its centralized REST client, consuming multiple backend service domains/subdomains. Community and expert interaction runs over a Socket.IO client with token-authenticated connections. Crop disease support works by submitting a photo to a remote prediction API rather than running any on-device model. Firebase Cloud Messaging and local notifications, Google Maps with geolocation and geocoding, SQLite/sqflite for local caching, and Salsa20-encrypted SharedPreferences round out the client. Android release builds are automated through a GitHub Actions workflow triggered by tags, using FVM for Flutter SDK version management.

Key Features

• Crop advisory and crop-care content
• Crop disease support through camera image submission to a remote prediction API
• Market price tracking and charts
• Weather and location-based services
• E-commerce catalog, cart, checkout, order, and order tracking flows
• Dealer/shop discovery through maps and location services
• Community/expert chat through Socket.IO client
• Firebase Cloud Messaging and local notifications
• Local district/reference-data caching
• Encrypted local session/preferences storage
• Reusable pagination and infinite scroll across list screens
• English/Nepali localization support where evidenced

Technical Decisions

• Used a modular Laravel backend structure to organize agriculture domains
• Used Repository and Action patterns to keep backend domain logic more maintainable
• Built a custom Artisan scaffolding command to standardize CRUD module generation
• Used case-conversion middleware so PHP snake_case and JavaScript/Flutter camelCase conventions could coexist cleanly
• Used BLoC/Cubit as the main Flutter state-management pattern across a large feature set
• Used Dio as the centralized mobile REST client
• Used Socket.IO client for chat rather than claiming backend real-time infrastructure ownership
• Used SQLite/sqflite for local reference-data caching
• Used encrypted SharedPreferences to protect local session/preferences data
• Used reusable pagination patterns across 10+ list-based screens

Tradeoffs

• The backend followed a modular monolith approach rather than splitting every agriculture domain into separate services
• The crop disease feature sends images to a remote prediction API; Prajesh did not build the ML model or on-device computer vision
• Payment method selection UI existed, but verified payment gateway SDK integration should not be claimed
• Mobile release automation existed for Android APK builds, but backend CI/CD was not evidenced
• Domain testing was limited, so comprehensive automated testing should not be claimed
• Some technologies appeared in configuration only and should not be presented as active production integrations

Security, Reliability & Testing

• Bearer token authorization attached to API requests
• Basic auth variant for miscellaneous service calls where evidenced
• Global 401 handling to redirect expired sessions to login/landing flow
• Device fingerprint metadata included in login/register requests
• Encrypted SharedPreferences using custom Salsa20 encryption service
• Socket.IO client used token-authenticated connections for chat
• Local SQLite/sqflite cache for district/reference data
• Backend validation caveat: some domain request validation/testing was limited
• Mobile test infrastructure existed, but active mobile tests were limited — an honest area for future hardening

Deployment

• Android/iOS native build systems were present
• FVM used for Flutter SDK version management
• GitHub Actions workflow triggered by tags for Android APK release builds
• Workflow built release APK and published it to GitHub Releases
• No Docker, Kubernetes, Fastlane, App Store deployment automation, or backend production CI/CD is claimed

Outcome / Current Status

Muktinath Krishi was delivered as a large agri-tech mobile product combining backend modules, mobile workflows, multi-service API integration, maps, notifications, chat, local caching, e-commerce flows, and crop disease support. The project demonstrates Prajesh's ability to contribute to complex domain software across Laravel backend architecture and Flutter mobile delivery.

What I'd Improve Next

• Add stronger automated test coverage for backend domain controllers and mobile workflows
• Harden request validation across domain modules
• Document API boundaries and service ownership more clearly
• Add stronger observability and error tracking
• Improve deployment documentation for backend and mobile release flows
• Clarify or complete payment gateway integration before claiming payment support
• Add architecture diagrams for the backend/mobile/multi-service integration
• Improve rollback and release verification documentation