The problem
Agricultural software fragments by function. Field records live in one product, weed management in another, parcel data in a county portal, cattle in a notebook, grant paperwork in a folder, and input ordering over the phone. Every one of those is about the same acres, and none of them agree about the boundary of the field.
What we built
A platform designed as six modules on one shared spatial core rather than six products stitched together:
- FieldWize - field records and land intelligence
- WeedWize - weed inventory and treatment
- ParcelWize - parcel and ownership data
- CattleWize - livestock records
- GrantWize - grant tracking and documentation
- OrderWize - input ordering through the co-op
All six read and write through one Intelligence Platform API, so a field boundary is defined once and every module inherits it.
How it works
The right tool per module
The spatially heavy modules run on Python and FastAPI over PostGIS in Docker, where real geometry work belongs. The records-and-forms modules run on PHP and MySQL, which is faster to build and cheaper to host for what they actually do. Splitting by workload rather than standardizing on one stack keeps both the geometry correct and the cost sane.
Roles that match how the work happens
A grower works their own ground. An agronomist advises across many operations and links to the growers they serve. A co-op sells inputs and needs to see demand. The platform models those as distinct roles with their own dashboards, rather than one user type with permission flags.
A deliberate constraint. There is no shopping cart. Input orders require an agronomist to sign off before they move, because agronomic recommendations and product sales should not be the same frictionless click. The workflow encodes the professional judgment that the industry already expects.
Built to be linked
Growers link to their own agronomist and to the co-ops they belong to, by ID. The relationships are data, so an operation that changes advisors or joins another co-op does not need a migration.
What it changed
An early-stage company has an architecture it can build against for years instead of a prototype it will need to throw away, with the spatial core, the API surface, and the role model settled before the first module shipped.