We Built a Farm For That Grows Where You Dine
We Built a Farm For That Grows Where You Dine
There's a particular kind of problem that looks simple until you're standing in the middle of it. A hospitality client came to us with a vision: grow fresh produce on-site, inside their space. Not a greenhouse out back. Inside. Where guests eat, where staff work, where every surface needs to look intentional and every system needs to run silently. The brief was clean. The reality, as it always is, was not.
What followed was one of the most layered projects we've taken on not because of the technology, but because of what the technology had to disappear into.
The Real Constraint Wasn't Technical
Before we wrote a line of code or specced a single component, we sat with the problem. What does it actually mean to put a living system inside a professional space?
Living systems are messy. They need water, nutrients, specific temperatures, specific light cycles. They fail quietly a plant doesn't throw an error, it just stops growing. And the people responsible for keeping it alive aren't farmers. They're baristas, chefs, front-of-house staff with a hundred other things to think about.
The real constraint wasn't bandwidth or compute or even budget. It was attention. The system had to work without demanding any.
That single insight shaped every decision we made after it.
A Farm That Looks Like a Tree
Early in the design process, we kept returning to one question: what should this thing actually look like?
Hydroponic systems, especially automated ones, tend to look like what they are, a tangle of tubes, reservoirs, pumps, and wiring held together with brackets and optimism. That wasn't going to work here. This was going into a space where aesthetic wasn't an afterthought. It was the point.
We started thinking about the form of the system while working on the function. And somewhere in that process, a metaphor surfaced that changed how we approached everything: a tree.
A tree has one trunk. Everything flows through it water, nutrients, structural support. The branches extend outward, each one carrying what it needs from the centre. The leaves sit at the ends, doing the actual work of growth, of photosynthesis, of life. The whole system is elegant because it's hierarchical. One source. Many endpoints. Nothing redundant, nothing wasted.
We built the farm the same way.
A single central column carries all the infrastructure water supply, nutrient delivery, power, and data. The grow trays extend outward from it like branches. Each tray is self-contained but fed from the centre. When you look at it without knowing what it is, it reads as a designed object, something architectural. When you look closer when you trace the lines and understand the logic you see the tree.
The Metaphor Goes All the Way Down
What surprised us, as the project evolved, was how far the tree metaphor held.
In hardware, it was obvious. One central nervous system talking to distributed endpoints. The main compute unit acts as the trunk it holds the state, runs the schedules, makes the decisions. The real-time controller sits below it, handling the physical world: pumps, valves, sensors. Precise, fast, deterministic. The dashboard sits above, a window into the system for whoever needs to look.
In software, the same logic applied. We designed for one clear source of truth. All commands flow through a single channel no competing instructions, no race conditions, no two parts of the system trying to do contradictory things at the same time. When you have living hardware pumps that move real water, valves that open and close you can't afford ambiguity. The tree doesn't send water in two directions at once.
The dosing logic followed the same thinking. Rather than trying to calculate exactly how much nutrient to add which depends on water volume, which changes constantly we designed a process that mirrors how a careful human would do it. Add a little. Wait. Check. Add a little more if needed. Step by step, sensing and adjusting, rather than computing and committing. It's slower. It's also reliable in the way that matters.
The Discipline of Not Overbuilding
Autonomous systems have a particular failure mode that has nothing to do with hardware or sensors. It's architectural. The moment a system needs to make decisions act on sensor data, respond to conditions, trigger actions without a human in the loop the temptation is to reach for complexity. More abstraction. More services. More surface area. It feels like engineering. It's usually the opposite.
We caught ourselves early. The system we were building was, at its core, simple: read the environment, compare it to what it should be, take action if needed. That loop didn't need to be complicated. It needed to be reliable.
So we made a deliberate choice to build lean not because of budget, but because of discipline. The entire stack: sensor orchestration, automation engine, command handling, dashboard, database all of it runs on bare metal hardware with under 256MB of RAM. No containers, no cloud agents, no unnecessary layers between the code and the machine.
This mattered more than it might sound. We're in the middle of what people in hardware circles are calling RAMpocalypse a global memory shortage driven by the AI industry's insatiable appetite for high-bandwidth memory. RAM is expensive, constrained, and increasingly something you design around rather than throw at a problem. Building lean wasn't just good engineering. It was the right call for the world we're building in.
The result: the full stack runs comfortably within its constraints we had enough RAM left over to play DOM. The entire system fits in under 20MB of disk. That's not a typo. Twenty megabytes which means the remaining storage can hold sensor readings logged every ten seconds for over a hundred years without running out of space.
We didn't shrink it to hit a number. We shrunk it because every unnecessary megabyte is a decision you'll eventually regret.
Designing for Failure Before Designing for Features
At some point early on, we made a deliberate choice that shaped the entire architecture: we decided the system would work without the internet before we decided what features it would have.
This sounds obvious. It isn't. Most connected systems are designed optimistically they assume connectivity, then add fallbacks later. We flipped that. Offline operation was the baseline. Everything had to work on the device, locally, with no dependency on any external service.
The reason was simple: a dead plant in a client's dining room is a disaster. A slow dashboard is an inconvenience. We designed to avoid the disaster first.
That meant local storage. Local control logic. Local dashboards accessible on the same network without touching the internet. When remote access is needed for support, for monitoring, for updates it happens through a layer that doesn't compromise the core. The system doesn't need it to function. It just enables it when it's useful.
Data doesn't disappear when connectivity does. Analytics accumulate locally and surface whenever they're needed. The farm doesn't stop thinking just because it's offline.
This is the kind of decision that's invisible when everything goes well. It's everything when something goes wrong at 2am in a restaurant kitchen.
Where We Fell Short
We're proud of what we delivered. And we want to be honest about where we didn't go far enough.
Climate control managing the temperature and airflow around the grow environment was part of the brief. We built it. It works. But it works at a level of performance that we know isn't the ceiling.
The honest reason: We underestimated the tuning. The gap between a system that controls climate and a system that controls it well with the right response curves, the right sensor placement, the right interplay between airflow and humidity and temperature that gap is wider than we anticipated, and we didn't have the time to close it fully.
What we shipped is stable and functional. What we wanted to ship was something that managed the grow environment with the same precision and intelligence as the nutrient delivery. We'll get there. But we weren't there on this project, and it would be dishonest to pretend otherwise.
That shortfall is something we're carrying into the next iteration.
What the Project Actually Was
Looking back, this wasn't really a technology project. It was a design problem that happened to require a lot of technology to solve.
The technology the sensors, the controllers, the software layers none of that is the point. The point is a space where fresh food grows reliably, invisibly, in a way that adds something to the environment rather than demanding attention from it. The point is a system that a chef can walk past every day without thinking about, and still have fresh herbs when they need them.
We got most of the way there. The tree stands. The branches are feeding. The leaves are growing. The next version will breathe better.
The identity centered around a clean typographic structure paired with soft organic forms. We explored color palettes that echoed natural tea tones and packaging textures that invited touch. Every element was created to reflect the quiet confidence of the brand.
We Built a Farm For That Grows Where You Dine
We Built a Farm For That Grows Where You Dine
There's a particular kind of problem that looks simple until you're standing in the middle of it. A hospitality client came to us with a vision: grow fresh produce on-site, inside their space. Not a greenhouse out back. Inside. Where guests eat, where staff work, where every surface needs to look intentional and every system needs to run silently. The brief was clean. The reality, as it always is, was not.
What followed was one of the most layered projects we've taken on not because of the technology, but because of what the technology had to disappear into.
The Real Constraint Wasn't Technical
Before we wrote a line of code or specced a single component, we sat with the problem. What does it actually mean to put a living system inside a professional space?
Living systems are messy. They need water, nutrients, specific temperatures, specific light cycles. They fail quietly a plant doesn't throw an error, it just stops growing. And the people responsible for keeping it alive aren't farmers. They're baristas, chefs, front-of-house staff with a hundred other things to think about.
The real constraint wasn't bandwidth or compute or even budget. It was attention. The system had to work without demanding any.
That single insight shaped every decision we made after it.
A Farm That Looks Like a Tree
Early in the design process, we kept returning to one question: what should this thing actually look like?
Hydroponic systems, especially automated ones, tend to look like what they are, a tangle of tubes, reservoirs, pumps, and wiring held together with brackets and optimism. That wasn't going to work here. This was going into a space where aesthetic wasn't an afterthought. It was the point.
We started thinking about the form of the system while working on the function. And somewhere in that process, a metaphor surfaced that changed how we approached everything: a tree.
A tree has one trunk. Everything flows through it water, nutrients, structural support. The branches extend outward, each one carrying what it needs from the centre. The leaves sit at the ends, doing the actual work of growth, of photosynthesis, of life. The whole system is elegant because it's hierarchical. One source. Many endpoints. Nothing redundant, nothing wasted.
We built the farm the same way.
A single central column carries all the infrastructure water supply, nutrient delivery, power, and data. The grow trays extend outward from it like branches. Each tray is self-contained but fed from the centre. When you look at it without knowing what it is, it reads as a designed object, something architectural. When you look closer when you trace the lines and understand the logic you see the tree.
The Metaphor Goes All the Way Down
What surprised us, as the project evolved, was how far the tree metaphor held.
In hardware, it was obvious. One central nervous system talking to distributed endpoints. The main compute unit acts as the trunk it holds the state, runs the schedules, makes the decisions. The real-time controller sits below it, handling the physical world: pumps, valves, sensors. Precise, fast, deterministic. The dashboard sits above, a window into the system for whoever needs to look.
In software, the same logic applied. We designed for one clear source of truth. All commands flow through a single channel no competing instructions, no race conditions, no two parts of the system trying to do contradictory things at the same time. When you have living hardware pumps that move real water, valves that open and close you can't afford ambiguity. The tree doesn't send water in two directions at once.
The dosing logic followed the same thinking. Rather than trying to calculate exactly how much nutrient to add which depends on water volume, which changes constantly we designed a process that mirrors how a careful human would do it. Add a little. Wait. Check. Add a little more if needed. Step by step, sensing and adjusting, rather than computing and committing. It's slower. It's also reliable in the way that matters.
The Discipline of Not Overbuilding
Autonomous systems have a particular failure mode that has nothing to do with hardware or sensors. It's architectural. The moment a system needs to make decisions act on sensor data, respond to conditions, trigger actions without a human in the loop the temptation is to reach for complexity. More abstraction. More services. More surface area. It feels like engineering. It's usually the opposite.
We caught ourselves early. The system we were building was, at its core, simple: read the environment, compare it to what it should be, take action if needed. That loop didn't need to be complicated. It needed to be reliable.
So we made a deliberate choice to build lean not because of budget, but because of discipline. The entire stack: sensor orchestration, automation engine, command handling, dashboard, database all of it runs on bare metal hardware with under 256MB of RAM. No containers, no cloud agents, no unnecessary layers between the code and the machine.
This mattered more than it might sound. We're in the middle of what people in hardware circles are calling RAMpocalypse a global memory shortage driven by the AI industry's insatiable appetite for high-bandwidth memory. RAM is expensive, constrained, and increasingly something you design around rather than throw at a problem. Building lean wasn't just good engineering. It was the right call for the world we're building in.
The result: the full stack runs comfortably within its constraints we had enough RAM left over to play DOM. The entire system fits in under 20MB of disk. That's not a typo. Twenty megabytes which means the remaining storage can hold sensor readings logged every ten seconds for over a hundred years without running out of space.
We didn't shrink it to hit a number. We shrunk it because every unnecessary megabyte is a decision you'll eventually regret.
Designing for Failure Before Designing for Features
At some point early on, we made a deliberate choice that shaped the entire architecture: we decided the system would work without the internet before we decided what features it would have.
This sounds obvious. It isn't. Most connected systems are designed optimistically they assume connectivity, then add fallbacks later. We flipped that. Offline operation was the baseline. Everything had to work on the device, locally, with no dependency on any external service.
The reason was simple: a dead plant in a client's dining room is a disaster. A slow dashboard is an inconvenience. We designed to avoid the disaster first.
That meant local storage. Local control logic. Local dashboards accessible on the same network without touching the internet. When remote access is needed for support, for monitoring, for updates it happens through a layer that doesn't compromise the core. The system doesn't need it to function. It just enables it when it's useful.
Data doesn't disappear when connectivity does. Analytics accumulate locally and surface whenever they're needed. The farm doesn't stop thinking just because it's offline.
This is the kind of decision that's invisible when everything goes well. It's everything when something goes wrong at 2am in a restaurant kitchen.
Where We Fell Short
We're proud of what we delivered. And we want to be honest about where we didn't go far enough.
Climate control managing the temperature and airflow around the grow environment was part of the brief. We built it. It works. But it works at a level of performance that we know isn't the ceiling.
The honest reason: We underestimated the tuning. The gap between a system that controls climate and a system that controls it well with the right response curves, the right sensor placement, the right interplay between airflow and humidity and temperature that gap is wider than we anticipated, and we didn't have the time to close it fully.
What we shipped is stable and functional. What we wanted to ship was something that managed the grow environment with the same precision and intelligence as the nutrient delivery. We'll get there. But we weren't there on this project, and it would be dishonest to pretend otherwise.
That shortfall is something we're carrying into the next iteration.
What the Project Actually Was
Looking back, this wasn't really a technology project. It was a design problem that happened to require a lot of technology to solve.
The technology the sensors, the controllers, the software layers none of that is the point. The point is a space where fresh food grows reliably, invisibly, in a way that adds something to the environment rather than demanding attention from it. The point is a system that a chef can walk past every day without thinking about, and still have fresh herbs when they need them.
We got most of the way there. The tree stands. The branches are feeding. The leaves are growing. The next version will breathe better.
The identity centered around a clean typographic structure paired with soft organic forms. We explored color palettes that echoed natural tea tones and packaging textures that invited touch. Every element was created to reflect the quiet confidence of the brand.
We Built a Farm For That Grows Where You Dine
We Built a Farm For That Grows Where You Dine
There's a particular kind of problem that looks simple until you're standing in the middle of it. A hospitality client came to us with a vision: grow fresh produce on-site, inside their space. Not a greenhouse out back. Inside. Where guests eat, where staff work, where every surface needs to look intentional and every system needs to run silently. The brief was clean. The reality, as it always is, was not.
What followed was one of the most layered projects we've taken on not because of the technology, but because of what the technology had to disappear into.
The Real Constraint Wasn't Technical
Before we wrote a line of code or specced a single component, we sat with the problem. What does it actually mean to put a living system inside a professional space?
Living systems are messy. They need water, nutrients, specific temperatures, specific light cycles. They fail quietly a plant doesn't throw an error, it just stops growing. And the people responsible for keeping it alive aren't farmers. They're baristas, chefs, front-of-house staff with a hundred other things to think about.
The real constraint wasn't bandwidth or compute or even budget. It was attention. The system had to work without demanding any.
That single insight shaped every decision we made after it.
A Farm That Looks Like a Tree
Early in the design process, we kept returning to one question: what should this thing actually look like?
Hydroponic systems, especially automated ones, tend to look like what they are, a tangle of tubes, reservoirs, pumps, and wiring held together with brackets and optimism. That wasn't going to work here. This was going into a space where aesthetic wasn't an afterthought. It was the point.
We started thinking about the form of the system while working on the function. And somewhere in that process, a metaphor surfaced that changed how we approached everything: a tree.
A tree has one trunk. Everything flows through it water, nutrients, structural support. The branches extend outward, each one carrying what it needs from the centre. The leaves sit at the ends, doing the actual work of growth, of photosynthesis, of life. The whole system is elegant because it's hierarchical. One source. Many endpoints. Nothing redundant, nothing wasted.
We built the farm the same way.
A single central column carries all the infrastructure water supply, nutrient delivery, power, and data. The grow trays extend outward from it like branches. Each tray is self-contained but fed from the centre. When you look at it without knowing what it is, it reads as a designed object, something architectural. When you look closer when you trace the lines and understand the logic you see the tree.
The Metaphor Goes All the Way Down
What surprised us, as the project evolved, was how far the tree metaphor held.
In hardware, it was obvious. One central nervous system talking to distributed endpoints. The main compute unit acts as the trunk it holds the state, runs the schedules, makes the decisions. The real-time controller sits below it, handling the physical world: pumps, valves, sensors. Precise, fast, deterministic. The dashboard sits above, a window into the system for whoever needs to look.
In software, the same logic applied. We designed for one clear source of truth. All commands flow through a single channel no competing instructions, no race conditions, no two parts of the system trying to do contradictory things at the same time. When you have living hardware pumps that move real water, valves that open and close you can't afford ambiguity. The tree doesn't send water in two directions at once.
The dosing logic followed the same thinking. Rather than trying to calculate exactly how much nutrient to add which depends on water volume, which changes constantly we designed a process that mirrors how a careful human would do it. Add a little. Wait. Check. Add a little more if needed. Step by step, sensing and adjusting, rather than computing and committing. It's slower. It's also reliable in the way that matters.
The Discipline of Not Overbuilding
Autonomous systems have a particular failure mode that has nothing to do with hardware or sensors. It's architectural. The moment a system needs to make decisions act on sensor data, respond to conditions, trigger actions without a human in the loop the temptation is to reach for complexity. More abstraction. More services. More surface area. It feels like engineering. It's usually the opposite.
We caught ourselves early. The system we were building was, at its core, simple: read the environment, compare it to what it should be, take action if needed. That loop didn't need to be complicated. It needed to be reliable.
So we made a deliberate choice to build lean not because of budget, but because of discipline. The entire stack: sensor orchestration, automation engine, command handling, dashboard, database all of it runs on bare metal hardware with under 256MB of RAM. No containers, no cloud agents, no unnecessary layers between the code and the machine.
This mattered more than it might sound. We're in the middle of what people in hardware circles are calling RAMpocalypse a global memory shortage driven by the AI industry's insatiable appetite for high-bandwidth memory. RAM is expensive, constrained, and increasingly something you design around rather than throw at a problem. Building lean wasn't just good engineering. It was the right call for the world we're building in.
The result: the full stack runs comfortably within its constraints we had enough RAM left over to play DOM. The entire system fits in under 20MB of disk. That's not a typo. Twenty megabytes which means the remaining storage can hold sensor readings logged every ten seconds for over a hundred years without running out of space.
We didn't shrink it to hit a number. We shrunk it because every unnecessary megabyte is a decision you'll eventually regret.
Designing for Failure Before Designing for Features
At some point early on, we made a deliberate choice that shaped the entire architecture: we decided the system would work without the internet before we decided what features it would have.
This sounds obvious. It isn't. Most connected systems are designed optimistically they assume connectivity, then add fallbacks later. We flipped that. Offline operation was the baseline. Everything had to work on the device, locally, with no dependency on any external service.
The reason was simple: a dead plant in a client's dining room is a disaster. A slow dashboard is an inconvenience. We designed to avoid the disaster first.
That meant local storage. Local control logic. Local dashboards accessible on the same network without touching the internet. When remote access is needed for support, for monitoring, for updates it happens through a layer that doesn't compromise the core. The system doesn't need it to function. It just enables it when it's useful.
Data doesn't disappear when connectivity does. Analytics accumulate locally and surface whenever they're needed. The farm doesn't stop thinking just because it's offline.
This is the kind of decision that's invisible when everything goes well. It's everything when something goes wrong at 2am in a restaurant kitchen.
Where We Fell Short
We're proud of what we delivered. And we want to be honest about where we didn't go far enough.
Climate control managing the temperature and airflow around the grow environment was part of the brief. We built it. It works. But it works at a level of performance that we know isn't the ceiling.
The honest reason: We underestimated the tuning. The gap between a system that controls climate and a system that controls it well with the right response curves, the right sensor placement, the right interplay between airflow and humidity and temperature that gap is wider than we anticipated, and we didn't have the time to close it fully.
What we shipped is stable and functional. What we wanted to ship was something that managed the grow environment with the same precision and intelligence as the nutrient delivery. We'll get there. But we weren't there on this project, and it would be dishonest to pretend otherwise.
That shortfall is something we're carrying into the next iteration.
What the Project Actually Was
Looking back, this wasn't really a technology project. It was a design problem that happened to require a lot of technology to solve.
The technology the sensors, the controllers, the software layers none of that is the point. The point is a space where fresh food grows reliably, invisibly, in a way that adds something to the environment rather than demanding attention from it. The point is a system that a chef can walk past every day without thinking about, and still have fresh herbs when they need them.
We got most of the way there. The tree stands. The branches are feeding. The leaves are growing. The next version will breathe better.
The identity centered around a clean typographic structure paired with soft organic forms. We explored color palettes that echoed natural tea tones and packaging textures that invited touch. Every element was created to reflect the quiet confidence of the brand.
We Built a Farm For That Grows Where You Dine
We Built a Farm For That Grows Where You Dine
There's a particular kind of problem that looks simple until you're standing in the middle of it. A hospitality client came to us with a vision: grow fresh produce on-site, inside their space. Not a greenhouse out back. Inside. Where guests eat, where staff work, where every surface needs to look intentional and every system needs to run silently. The brief was clean. The reality, as it always is, was not.
What followed was one of the most layered projects we've taken on not because of the technology, but because of what the technology had to disappear into.
The Real Constraint Wasn't Technical
Before we wrote a line of code or specced a single component, we sat with the problem. What does it actually mean to put a living system inside a professional space?
Living systems are messy. They need water, nutrients, specific temperatures, specific light cycles. They fail quietly a plant doesn't throw an error, it just stops growing. And the people responsible for keeping it alive aren't farmers. They're baristas, chefs, front-of-house staff with a hundred other things to think about.
The real constraint wasn't bandwidth or compute or even budget. It was attention. The system had to work without demanding any.
That single insight shaped every decision we made after it.
A Farm That Looks Like a Tree
Early in the design process, we kept returning to one question: what should this thing actually look like?
Hydroponic systems, especially automated ones, tend to look like what they are, a tangle of tubes, reservoirs, pumps, and wiring held together with brackets and optimism. That wasn't going to work here. This was going into a space where aesthetic wasn't an afterthought. It was the point.
We started thinking about the form of the system while working on the function. And somewhere in that process, a metaphor surfaced that changed how we approached everything: a tree.
A tree has one trunk. Everything flows through it water, nutrients, structural support. The branches extend outward, each one carrying what it needs from the centre. The leaves sit at the ends, doing the actual work of growth, of photosynthesis, of life. The whole system is elegant because it's hierarchical. One source. Many endpoints. Nothing redundant, nothing wasted.
We built the farm the same way.
A single central column carries all the infrastructure water supply, nutrient delivery, power, and data. The grow trays extend outward from it like branches. Each tray is self-contained but fed from the centre. When you look at it without knowing what it is, it reads as a designed object, something architectural. When you look closer when you trace the lines and understand the logic you see the tree.
The Metaphor Goes All the Way Down
What surprised us, as the project evolved, was how far the tree metaphor held.
In hardware, it was obvious. One central nervous system talking to distributed endpoints. The main compute unit acts as the trunk it holds the state, runs the schedules, makes the decisions. The real-time controller sits below it, handling the physical world: pumps, valves, sensors. Precise, fast, deterministic. The dashboard sits above, a window into the system for whoever needs to look.
In software, the same logic applied. We designed for one clear source of truth. All commands flow through a single channel no competing instructions, no race conditions, no two parts of the system trying to do contradictory things at the same time. When you have living hardware pumps that move real water, valves that open and close you can't afford ambiguity. The tree doesn't send water in two directions at once.
The dosing logic followed the same thinking. Rather than trying to calculate exactly how much nutrient to add which depends on water volume, which changes constantly we designed a process that mirrors how a careful human would do it. Add a little. Wait. Check. Add a little more if needed. Step by step, sensing and adjusting, rather than computing and committing. It's slower. It's also reliable in the way that matters.
The Discipline of Not Overbuilding
Autonomous systems have a particular failure mode that has nothing to do with hardware or sensors. It's architectural. The moment a system needs to make decisions act on sensor data, respond to conditions, trigger actions without a human in the loop the temptation is to reach for complexity. More abstraction. More services. More surface area. It feels like engineering. It's usually the opposite.
We caught ourselves early. The system we were building was, at its core, simple: read the environment, compare it to what it should be, take action if needed. That loop didn't need to be complicated. It needed to be reliable.
So we made a deliberate choice to build lean not because of budget, but because of discipline. The entire stack: sensor orchestration, automation engine, command handling, dashboard, database all of it runs on bare metal hardware with under 256MB of RAM. No containers, no cloud agents, no unnecessary layers between the code and the machine.
This mattered more than it might sound. We're in the middle of what people in hardware circles are calling RAMpocalypse a global memory shortage driven by the AI industry's insatiable appetite for high-bandwidth memory. RAM is expensive, constrained, and increasingly something you design around rather than throw at a problem. Building lean wasn't just good engineering. It was the right call for the world we're building in.
The result: the full stack runs comfortably within its constraints we had enough RAM left over to play DOM. The entire system fits in under 20MB of disk. That's not a typo. Twenty megabytes which means the remaining storage can hold sensor readings logged every ten seconds for over a hundred years without running out of space.
We didn't shrink it to hit a number. We shrunk it because every unnecessary megabyte is a decision you'll eventually regret.
Designing for Failure Before Designing for Features
At some point early on, we made a deliberate choice that shaped the entire architecture: we decided the system would work without the internet before we decided what features it would have.
This sounds obvious. It isn't. Most connected systems are designed optimistically they assume connectivity, then add fallbacks later. We flipped that. Offline operation was the baseline. Everything had to work on the device, locally, with no dependency on any external service.
The reason was simple: a dead plant in a client's dining room is a disaster. A slow dashboard is an inconvenience. We designed to avoid the disaster first.
That meant local storage. Local control logic. Local dashboards accessible on the same network without touching the internet. When remote access is needed for support, for monitoring, for updates it happens through a layer that doesn't compromise the core. The system doesn't need it to function. It just enables it when it's useful.
Data doesn't disappear when connectivity does. Analytics accumulate locally and surface whenever they're needed. The farm doesn't stop thinking just because it's offline.
This is the kind of decision that's invisible when everything goes well. It's everything when something goes wrong at 2am in a restaurant kitchen.
Where We Fell Short
We're proud of what we delivered. And we want to be honest about where we didn't go far enough.
Climate control managing the temperature and airflow around the grow environment was part of the brief. We built it. It works. But it works at a level of performance that we know isn't the ceiling.
The honest reason: We underestimated the tuning. The gap between a system that controls climate and a system that controls it well with the right response curves, the right sensor placement, the right interplay between airflow and humidity and temperature that gap is wider than we anticipated, and we didn't have the time to close it fully.
What we shipped is stable and functional. What we wanted to ship was something that managed the grow environment with the same precision and intelligence as the nutrient delivery. We'll get there. But we weren't there on this project, and it would be dishonest to pretend otherwise.
That shortfall is something we're carrying into the next iteration.
What the Project Actually Was
Looking back, this wasn't really a technology project. It was a design problem that happened to require a lot of technology to solve.
The technology the sensors, the controllers, the software layers none of that is the point. The point is a space where fresh food grows reliably, invisibly, in a way that adds something to the environment rather than demanding attention from it. The point is a system that a chef can walk past every day without thinking about, and still have fresh herbs when they need them.
We got most of the way there. The tree stands. The branches are feeding. The leaves are growing. The next version will breathe better.
The identity centered around a clean typographic structure paired with soft organic forms. We explored color palettes that echoed natural tea tones and packaging textures that invited touch. Every element was created to reflect the quiet confidence of the brand.