FieldSpark connects the records behind field work, stock movement, product application and harvest traceability.
Selected work - 01 / Agriculture
FieldSpark
Project overview
I built FieldSpark through Webtra Digital Solutions for agricultural operations. The work spans the data model, application workflows and interfaces that connect a field to the inputs used on it and the batches harvested from it.
Technologies used
PHP
Laravel
Vue.js
JavaScript
Tailwind CSS
MySQL( 01 ) - The system
The hard part is keeping related records connected as work moves from planning to the field and on to harvest.
FieldSpark models fields, crop types and varieties alongside storerooms, products, spray programs and harvest batches. A program references both the field and the inventory item; an application records what actually happened; a harvest batch can reference the applications associated with it. That structure makes the history of the work inspectable across modules.
The product also covers the surrounding work: field notes, growth stages, stock audits, training records, equipment calibration and reporting. The deep dive below focuses on the path that ties the core agricultural records together.
( 02 ) - Record path
From a field to a harvest batch.
These are the linked record types in the application. The path is a map of the data model, not a claim that every farm follows one identical process.
Field
A physical block with its crop type, variety, season and location.
Product & Stock
An item held in a storeroom, with quantity and product details.
Program
Planned work linking a field, product, timing and assignee.
Application
The recorded activity, amount used, applicator and conditions.
Harvest Batch
A batch linked back to its field and relevant application history.
( 03 ) - Inventory
Stock changes need an explicit reason and a reliable state change.
The inventory model tracks products in storerooms. Receipts add stock; transfers move it; applications consume it; physical counts can lead to an approved reconciliation. Rather than treating the quantity as a free-editing field, these workflows give each change its own record and decision point.
Receive
Goods receipts record stock entering a storeroom, including product, quantity and batch details.
Move
Transfers require approval. Completion updates both storerooms together inside a database transaction.
Count
A stock audit compares the physical count with the recorded quantity. Reconciliation follows approval.
Use
An application checks available stock before the system records consumption and the application together.
A transfer approval checks available source stock, updates both storerooms and records the approver within one transaction. A stock audit must be approved before its counted quantity can replace the recorded amount.
( 04 ) - Checks
Application records carry the constraints that make them useful.
FieldSpark separates a planned agrochemical program from an actual application. Program setup checks required product details; the application flow checks field location and stock, captures who applied the product and calculates timing dates. A separate rule engine evaluates further program constraints and returns pass, warning or blocking results for review.
Product Identity
Program creation checks for a label ID, formulation and concentration on the selected product.
Field Context
Application capture requires field location data and records the actual date, quantity and applicator.
Stock Availability
The requested amount is converted to inventory units and checked against stock that is not reserved.
Timing Rules
The application flow calculates pre-harvest and re-entry dates and records a validation result.
These checks support record quality and review. They are not a claim that the product itself holds a compliance certification.
( 05 ) - Traceability
The batch record can carry its history into a reviewable export.
A harvest batch stores its source field and can be linked to the application records relevant to that batch. The traceability view loads those relationships; its spreadsheet export separates batch details, linked spray applications and sales lots into sheets that can be inspected outside the app.
FieldSpark also has an audit pack export that gathers records such as applications, calibration, training, harvest, environmental tests and safety incidents. The design keeps operational data usable at the point of work and available later for review.
Batch Details
Source field, harvest date and batch identity.
Applications
Linked product use, timing and applicator details.
Sales Lots
Lot, dispatch and quantity information.
( 06 ) - Architecture
An operator-facing app with domain rules behind the screens.
Application
Laravel handles routes, persistence and domain services. Vue 3 and Inertia provide the operator-facing pages.
Team Context
Farm data is organised under teams, with role-based permissions and team-scoped queries throughout the workflows.
Rules
A dedicated rule engine evaluates program constraints such as product use, timing, training and protective equipment.
Reporting
Spreadsheet exports turn linked operational records into traceability reports and multi-sheet audit packs.
My contribution was building the application and its connected workflows. This case study describes implemented scope; it does not attach an unverified rollout figure, time saving or customer outcome to the work.