A Farm Management Platform for Broiler Operations
From field research to production: building a better way to manage broiler farm operations.
Overview
Pietiq.app↗ turns scattered broiler-farm records into a structured, role-based platform for daily reporting, performance monitoring, finance, and AI-assisted decision support.
The most important part of the project was not the number of screens I designed. It was learning when to change the product direction, turning field observations into system rules, and making sure those decisions survived from research to production.
The Decision That Shaped the Product
Pietiq originally started as an advanced IoT concept. I imagined a modern farm system connecting environmental sensors, automated weighing, CCTV, equipment controls, and a real-time monitoring dashboard.
It was the more ambitious idea.
But after observing daily operations on actual farms, I found a more fundamental problem: farms already generated critical information every day, but that information was scattered across handwritten logs, spreadsheets, WhatsApp messages, and people’s memory.
The immediate need was not more hardware. It was a reliable operational foundation. So I changed the product direction.
Instead of starting with sensors, Pietiq would first organize how data was captured, connected to responsibilities, interpreted against performance standards, and turned into action.
IoT remains part of the long-term vision, but it now sits on top of a stronger platform.
Key decision: Build the operational foundation before adding automation.
📖 Related writing:
Field Research Changed My Mind About IoT↗
IoT-first approach vs Operational foundation-first
The Problem
Broiler farming moves quickly.
A mortality spike, declining feed efficiency, or body weight falling behind target may require action within hours. But owners often depended on manual recaps or phone calls to understand what was happening inside each house.
The field research↗ revealed four connected problems:
- Daily records were fragmented and difficult to trust.
- Raw numbers lacked context from breed standards and production targets.
- Different team members needed different information and permissions.
- Operational finance and owner-side settlement finance were being treated as one system.
The design challenge became:
How might I turn daily farm records into a trusted workflow that helps each role understand the farm’s condition and take the right action?
The problem
Research: Understanding the Operating Reality
I did not begin with a feature list.
I observed farm operations directly and spoke with owners, supervisors, and field workers across multiple production cycles. I mapped how information moved, where decisions were made, and where records became unreliable.
Two findings shaped the product architecture.
Five Roles, Not One Generic User
A farm is operated by people with very different responsibilities:
- Owner: monitors performance, controls private finance, and makes business decisions.
- Supervisor: coordinates workers, monitors records, handles corrections, and responds to anomalies.
- Field Worker: enters mortality, feed usage, body-weight samples, and field observations.
- Finance Admin: records farm operating income and expenses.
- PPL or External Advisor: reviews production performance without access to private financial information.
This meant Pietiq could not use one universal dashboard. Each role needed a different starting point, different actions, and different access boundaries.
Role map
The Partnership Model Splits the Money
In Indonesia’s core-plasma model, the partner company supplies inputs such as DOC, feed, medicine, and harvest logistics. The owner receives a settlement after the production cycle based on contract prices, deductions, bonuses, and performance.
Partnership business model
This created two financial contexts:
- Finance Ops - operational transactions managed by the farm team.
- Finance Owner contract pricing, projected revenue, settlement, and private financial results.
These were not two views of the same ledger. They needed to be structurally separated.
📖 Related writing: I Started With IoT. Farmers Showed Me a Simpler Problem.↗
How I Made Design Decisions
I used the same process throughout the project:
1. Start from Operating Reality
Every important decision began with something observed in the field: how people worked, where data failed, or which information was sensitive.
2. Write the Rule Before Designing the Screen
Before opening Figma, I documented the business rules, role permissions, lifecycle states, and data dependencies.
A polished interface cannot fix an incorrect underlying model.
3. Design the Flow Around the Rule
The rules were translated into user flows, service blueprints, wireframes, states, warnings, and role-specific navigation.
4. Test the Decision, Not Only the Interface
Prototypes were used to test whether the information appeared in the right order, whether actions were visible, and whether warnings helped without interrupting the work.
5. Preserve the Decision Through Implementation
The same rules were written into PRDs, acceptance criteria, RBAC documentation, and non-goals so they would survive implementation.
Design decisions
📖 Related writing: Before I Designed a Single Screen, I Built a Design Foundation↗
Four Decisions That Made Pietiq Work
1. Remaining Population Is Always Calculated
Remaining birds affect performance, feed, harvest planning, and financial estimates. Instead of storing the number manually, Pietiq calculates it from the source data:
Remaining population = Initial DOC − Cumulative mortality − Cumulative harvested birds
Why This Mattered
The interface does not ask users to maintain the same information in multiple places. When a mortality or harvest record changes, the population updates automatically.
Design Impact
- Remaining population is read-only.
- Harvest forms show the system-expected population.
- Mismatches trigger a clear warning with the calculation behind the number.
- Missing or incorrect source records can be traced.
Remaining population
2. Daily Records Go from Draft to Saved, Without an Approval Gate
An early assumption was that supervisors should approve every daily record before it affected the dashboard.
Field observation showed that this would create a morning bottleneck.
Once an ABK saves a valid record:
- the population updates,
- KPIs recalculate,
- anomaly checks run,
- and the Owner dashboard receives the latest condition.
The Supervisor monitors the result and requests a correction only when something looks wrong.
Why This Mattered
Real-time visibility was more valuable than waiting for routine approval.
Trade-off
The platform trusts field input earlier, but protects accuracy through:
- validation,
- anomaly warnings,
- correction requests,
- edit history,
- and audit attribution.
3. Finance Ops and Finance Owner Are Separate
Finance Admins need to record electricity, salaries, maintenance, fuel, and other farm expenses. They do not need access to contract prices, partner settlement, or the Owner’s private financial position.
So the product separates:
Finance Ops
Operational income and expenses
Finance Owner
Projected revenue, contract deductions, settlement, and private financial results
Why This Mattered
This was not only a permission setting. It reflected two different financial workflows. The separation allows the Owner to delegate operational finance without exposing private business data.
Finance Ops and Finance Owner
4. AI Supports Decisions but Does Not Make Them
The Smart Farm Assistant appears at the top of the Owner dashboard and shows the overall farm condition:
- On Track
- Watch
- Risk
- Analyzing
- No Data
Selecting the widget opens a detailed summary, where houses are ranked by severity.
For each issue, the AI can show:
- the detected signal,
- supporting evidence,
- possible causes,
- recommended checks,
- missing information,
- and escalation options.
It does not prescribe medicine, change SOPs, or override human judgment.
Why This Mattered
In a high-impact operation, a confident recommendation without evidence creates risk rather than trust. The AI was designed as a co-pilot: useful enough to surface patterns, but restrained enough to keep the final decision with the farm team, PPL, or veterinarian.
The Smart Farm Assistant
Designing for the Field
The visual system started from operational constraints, not a mood board.
The product needed to work:
- on a mobile phone,
- during morning rounds,
- with one hand,
- and in changing light conditions.
This led to a few clear rules:
- 390px mobile baseline
- Minimum 44px touch targets
- WCAG AA contrast
- Noto Sans for readable typography
- Semantic colors for operational status
- No decorative element without an information purpose
The status system became the main visual language:
- ON TRACK - performance within target
- WATCH - needs closer monitoring
- RISK - immediate attention required
Designing for the Field
The Most Iterated Component: KPI Card
The KPI component went through three versions.
Version 1 - Table
It contained enough information but felt too dense on a mobile screen.
Version 2 - Value-only cards
It was easier to scan but lacked context. A number such as FCR 1.62 means little without a target.
Version 3 - Value, gap, standard, and status
The final card shows the current value together with how far it is from the configured standard.
The Owner can now understand both:
- what the value is,
- and whether the house is performing within target.
The same structure is repeated across houses to make comparison faster.
The KPI Component Itteration
📖 Related writing:
Before I Designed a Single Screen, I Built a Design Foundation↗
How I Turned a Research Document into Wireframes for Every Role↗
What Changed During Prototyping
Prototyping was used to challenge the interaction, not just demonstrate it.
Four changes came from testing:
- The Smart Farm Assistant changed from showing too much analysis immediately to a concise dashboard summary with detail one tap away.
- Harvest warning actions changed from generic labels to Investigate and Confirm Anyway.
- Submitted records added the person’s name and submission time instead of showing only a check icon.
The Smart Farm Assistant was the most important change.
Displaying too much AI content before the KPIs interrupted the Owner’s reading flow. The final design keeps the dashboard focused on farm status and allows deeper analysis when the Owner chooses to open it.
Changes Based on Testing Results
From Design Decisions to a Working Product
Before implementation, I wrote PRDs covering key features and flows to prepare for Vibe Code, and I built each document using AI based on the design process:
- goals and non-goals,
- business rules,
- state transitions,
- permissions,
- data models,
- and acceptance criteria.
The non-goals were especially important when working with AI coding tools.
For example:
Do not create a stored remainingPopulation field. Calculate it from DOC, mortality, and harvest records.
That sentence protected a product decision from becoming an incorrect database implementation.
I then built the responsive web application using Next.js and a Flutter mobile experience for field workers, supported by Codex, Claude Code, and GitHub Copilot.
AI accelerated scaffolding and repetitive implementation. I retained responsibility for product logic, architecture, security review, and the production gate.
Outcome and Feedback
Pietiq reached more than 1000 users organically, without a dedicated marketing campaign.
The first users came from the same farming context that informed the research. The strongest usage pattern came from the daily reporting workflow, especially for ABK workers who needed a fast way to complete their morning records.
Real usage also revealed new design problems.
One recurring question was why the system population did not match the physical count. The calculation itself was correct, but the explanation was not visible enough.
I improved the warning to show the source of the number:
System population: Initial DOC − Recorded mortality − Recorded harvest
This turned a confusing result into something users could verify and correct.
That feedback reinforced an important lesson: a system can be technically correct and still fail if the interface does not explain how it reached the answer.
What I Learned
Research Changed the Product, Not Just the Interface
The biggest research outcome was the decision not to build the original IoT concept first.
Product Design Includes System Rules
Role permissions, state transitions, financial boundaries, and derived data were as important as screen layout.
Good AI Design Requires Restraint
Trust came from evidence, boundaries, and escalation—not from making the AI appear more autonomous.
A Design Decision Must Survive Implementation
Documenting rules before screens and code helped keep the product aligned with the research through production.
Final Reflection
Pietiq demonstrates how I approach product design:
Observe the real operation
- identify the structural constraint
- write the rule
- design the workflow
- test the decision
- preserve it through implementation
- learn from real usage
The interface was only one part of the work.
The deeper challenge was turning a complex, role-based farm operation into a system people could understand, trust, and use every day.