The situation
Fullwood was after more than a redesign. Three parts had to grow together: a simulator of the robot, the data layer, and the farmer's view of both.
Fullwood builds M²erlin robotic milking systems. A farmer who buys one isn't buying a gadget. They're running a precision operation: 90 cows or 300, one robot or a fleet, with daily decisions about animal health, feed economics, reproduction timing and machine utilisation.
Fullwood wanted the software to match that level of precision, and the ambition reached through the whole stack.
At the surface, FullSense had grown feature by feature, and the next step was about priority. A farmer at 5:30am needs to see the one alert that matters before the 79 that can wait. Errors and info notices needed clearly different weights, and the cow card needed to tell a cow's story, not just list her settings.
Underneath sat the Data API, which had served the product well for years. The new screens asked more of it: data it didn't expose yet, leaner responses and a fully documented contract.
The hardest part was testing. Farm software only shows its real behaviour over a day: milkings build up, robots fill and empty, cows arrive late, separations fire. You can't put a barn in a CI pipeline, and you can't wait twelve hours to check a dashboard. Without realistic robot behaviour on demand, changes to the API or the frontend could only be checked against fixed test data.
Improving any single layer on its own wouldn't have been enough. A new frontend would be limited by what the API could deliver. A better API with no realistic data would go unproven. So Fullwood chose to develop the simulator, the data and the product together.
How we embedded
We ran three tracks inside Fullwood. All three worked from the same domain rules: lactation stages, separation priority, alert severity, and the difference between a first-lactation heifer and a fifth-lactation cow.
The simulator Mino built a virtual robot. This wasn't a mock that returns canned responses. It's a simulation of how an M²erlin behaves (cow visits, milkings, feed dispensing, separation decisions) writing into a real farm stack on a clock that can be fast-forwarded. A four-hour window runs in minutes, so every demo, test and design review can start from a barn that has actually lived through a morning.
The API track renewed the contract between robot and farmer. Inside Fullwood's .NET backend, legacy operations moved to a documented REST contract. New endpoints were added where the product needed data that didn't exist yet. Realtime robot status was pushed through ASP.NET Core SignalR instead of being polled by every screen. Every gap the frontend found went into a written log with measurements and steps to reproduce, and was then either fixed or recorded as a decision.
The FullSense Mino built the next FullSense. Its design follows the farm day: a status check at 5:30am, triage mid-morning, lifecycle work in the afternoon, review in the evening. It built against the real Data API from the first sprint, never a fictional backend.
The tracks fed each other. The simulator gave the API realistic traffic and gave the frontend a barn worth looking at. The frontend told the API what farmers actually need, and the API gave both a contract they could rely on.
What we built and why
A robot simulator, so the whole stack can be proven over time. Farm software fails slowly. A KPI drifts, an alert fires at hour six, a separation lands on the wrong cow after the third visit. Running the robot hour by hour turns those slow failures into something a team can reproduce in minutes. That's why the simulator got its own team and its own product, rather than being treated as test scaffolding.
An API contract that is written down, not assumed. The frontend wasn't allowed to quietly work around the API. Every operation the product uses is logged with its status: live, mocked with a stated reason, or not yet wired. Missing data went back to the backend as concrete requests, not guesses. Where it mattered, the contract itself changed: REST endpoints for the new screens and a realtime hub for robot status. The API now reflects what the product actually uses.
A new FullSense built on that foundation, not a reskin. Every screen opens with one dominant status signal. Every entity (cow, robot, KPI, farm) follows the same three-state grammar: OK, Watch, Act. A farm with 300 healthy cows and two sick ones shows two things, not 302. A cow is presented as an individual with a history, not a data row, and every metric comes with its trend and a reference point.
We said no to building any track in isolation. The easy path was three separate projects: a frontend agency, an API backlog and a test harness, each with its own roadmap. We kept them one product. A screen isn't done until it works against the real API, and an endpoint isn't proven until the simulator has driven realistic traffic through it.
The evidence
A barn day on demand. The simulator compresses hours of robot behaviour into minutes, with milkings, feedings and separations landing as the virtual clock moves. Demos, design reviews and API changes are checked against a farm that has actually run, not a dataset someone typed in.
One contract from robot to screen. The simulator, the .NET API and the frontend run against the same farm stack. Any gap found at the top of the stack has a written path to a fix at the bottom.
Three seconds, built into the layout. Each screen has one dominant signal at the top, and threshold colours mean the same thing on a robot tile as on a cow card. If the farmer has to scroll to know whether to worry, the screen has failed.
What we're building together
We haven't left. All three tracks are still embedded.
The simulator Mino is deepening the robot model so more of the barn can be reproduced, inspected and tested. The API track keeps closing the distance between what the robot records and what the farmer needs, including realtime status across the whole farm. The FullSense Mino is moving the remaining prototype screens onto live data, one workflow at a time.
What matters most is how the work now gets done: shared domain rules, written decisions, and a stack where each layer is proven by the others. Fullwood's software is growing alongside Fullwood's machines.