G12 AGRO · 2026–2027 / PRODUCT DESIGN · MOBILE + WEB
ROLE
Product Designer & Product Builder
RESPONSIBILITIES
Product Strategy · Product Management · Information Architecture · UX/UI · Prototyping · Implementation
TIMELINE
August 2026 — January 2027
PLATFORMS
Mobile + Web
STATUS
In development
01 / THE PROBLEM
Consultants visit farms to assess crops, identify problems, document field conditions and provide technical recommendations.
The challenge wasn’t simply replacing a paper form with a mobile interface. The product needed to create a consistent structure connecting clients, properties, fields, crops, technical visits, findings and recommendations — while respecting the different responsibilities of administrators and consultants.
CLIENT
PROPERTY
FIELD
CROP / SEASON
TECHNICAL VISIT
FINDINGS
RECOMMENDATIONS
02 / PRODUCT STRUCTURE
One early product decision was separating configuration from execution. Administrators are responsible for maintaining the operational structure — clients, properties, fields, crops and assignments. Consultants shouldn’t recreate that information during every visit. Their job is to access the operation they are assigned to and perform the technical assessment.
ADMIN
Clients
Properties
Fields
Crops / Seasons
Assignments
SHARED PRODUCT STRUCTURE
A consistent operational model
CONSULTANT
Assigned Operations
Technical Visits
Field Assessments
Photos
Findings
Recommendations
03 / KEY PRODUCT DECISION
A technical visit can cover several fields within the same property. Treating an entire visit as one record would flatten important differences between fields — including different conditions, findings, photos and recommendations. The product therefore evolved from a single-record model into a multi-field visit architecture.
ONE TECHNICAL VISIT CAN CONTAIN MULTIPLE INDEPENDENT FIELD ASSESSMENTS.
TECHNICAL VISIT
PROPERTY: FAZENDA X
FIELD 01
COMPLETED
FIELD 02
IN PROGRESS
FIELD 03
NOT STARTED
04 / FIELD EXPERIENCE
Each field needed its own working context instead of behaving as another step in one large form. The consultant can move through fields while preserving the state of each assessment.
NOT STARTED
IN PROGRESS
COMPLETED
A completed assessment can be reopened when field work requires revision.
05 / ASSESSMENT MODEL
The experience was designed around agricultural work performed at field level. Different stages of the agricultural cycle can require different types of information.
PLANTING
MONITORING
HARVEST
Occurrences can contain their own information while remaining associated with the specific field and technical visit where they were observed.
06 / PRODUCT STATE
A consultant may begin an assessment, collect information, move to another field and return later. For that reason, states such as Not Started, In Progress and Completed represent operational reality rather than simply visual status.
NOT STARTED
No assessment has begun.
IN PROGRESS
Work can pause and resume.
COMPLETED
Assessment is ready to review.
REOPEN ASSESSMENT
07 / PRODUCT ECOSYSTEM
Centralization becomes valuable when information collected in the field can become usable operational visibility for the organization. The broader product therefore connects the consultant’s mobile workflow with an administrative web experience designed around centralized records, reporting and operational oversight.
08 / USER ROLES
CONSULTANT
EXECUTION
Mobile-first · Assigned properties · Multiple fields · Technical assessments · Photos · Findings · Recommendations · Visit progress
ADMIN
STRUCTURE & VISIBILITY
Clients · Properties · Fields · Crops / Seasons · Consultant assignments · Centralized records · Reports · Operational visibility
ONE SHARED PRODUCT SYSTEM
09 / DELIVERY
I worked across requirements, product definition, information architecture, UX/UI and implementation — allowing product decisions to be evaluated against the actual technical constraints of the system.
REACT NATIVE · EXPO · SUPABASE · GITHUB
Design first. Implementation-aware throughout.
10 / SYSTEM THINKING
The decision to support multiple fields within a technical visit affected more than the interface. The product structure also needed to preserve those relationships.
TECHNICAL VISIT
VISIT FIELDS
FIELD ASSESSMENT
OCCURRENCES
USER REALITY → UX DECISION → PRODUCT STRUCTURE
11 / CURRENT OUTCOME
The project evolved from an initial visit-recording MVP into a broader mobile and web product designed around the actual hierarchy of agricultural consulting operations. The mobile experience and underlying product architecture have gone through multiple iterations with stakeholders. The broader platform remains in development.
12 / WHAT I LEARNED
Once multiple fields, different user responsibilities and centralized information became part of the problem, the project stopped being a form and became a product system. Working across design and implementation helped me evaluate those decisions not only as interfaces, but as structures the product would actually need to support.
NEXT PROJECT
Clarifying a B2B ordering platform for restaurant owners.
LET’S WORK TOGETHER
I’m open to Product Design opportunities and selected projects worldwide.