Tons of ingredients arrived daily. Each input was typed into a spreadsheet and then cleaned before the number could be used. Underestimate and the kitchen runs out; overestimate and it goes in the bin. The team spent a large share of its time on the treatment step, not on the decision it was supposed to inform.
Weigh it once and the stock is right
A delivery kitchen company replaced spreadsheet rows typed by hand, a data-collection app that still left the treatment manual, and end-of-cycle number crunching with a stock system fed directly by the scale.
A delivery kitchen company that buys in weight and sells in units.
Tons of ingredients come in every day; each one is weighed, stored, prepped and turned into a bowl that has to ship the same day. Ingredients spoil, deliveries arrive short, a count is wrong by a crate.
Delivery kitchens, fresh food
2016Founded
2,000Salads a day, at the time of the case (2022)
160People on the team, at the time of the case
2022New venture round, to open more kitchens and the first sit-down restaurant
350,000+Salads delivered in the yearThe company's own published figure in the case header. The year is not stated in the text; the case was published in 2022. Company scale, not a result of the system.
2,000Salads a daySame source, same date. It describes the operation the system was built for, and nothing in the source attributes it to the system.
160People on the teamSame source, same date. Business press the same year reported close to 200, so the figure is treated here as approximate.
1Integration the whole stock flow rests on: the open API of the scaleThe published case's own description of the build: the scale has an open API, and that was enough to connect and automate the process end to end.
“When dealing with inventory, right and almost right are worlds apart. Products can spoil, and a shipment may not be delivered. Knowing the right numbers is what keeps the whole operation from going off the rails. For me, using Jestor and other software is exactly this: the difference between right and almost right.”
Diogo KudoProduction Planning and Control, in the 2022 published case
BeforeAfter
- A spreadsheet row typed for each delivery receivedThe scale sends the weight through its API and the system updates stock
- Manual cleaning and treatment of each numberThe system treats the incoming data before it lands in stock
- Extraction and import repeated for every reportStock per item per kitchen, with history, in one place
- Dashboards built from periodic dataViews built on the live stock number
- A collection-only app for stock outputA dedicated app for manual entries, with the entry triggering the automations that follow
- Physical counts written down and reconciled by handA daily counting app: list of items, phone entry, automatic theoretical-versus-real comparison
- Purchase estimates built from stale numbersEstimates built from current stock and history per kitchen
The scales stayed. The kitchens and the daily physical count stayed. The order channels and the courier fleet were not part of this build. The case describes the system as the center of the stock process, collecting and sending data to other software when needed; it does not claim to have replaced that other software.
The bottleneck was operational, not commercial
Olga Ri prepares and delivers salads and grain bowls from delivery-only kitchens, selling through its own app and website and through delivery marketplaces, with its own courier fleet. The company was founded in 2016, took its first venture round in 2019 from a leading Latin American fund, and at the time of this case published 2,000 salads a day, more than 350,000 in the year and 160 people on the team. In 2022 it raised a further round to open more kitchens and its first sit-down restaurant, which opened in 2023.
A fresh-food kitchen buys in weight and sells in units. Tons of ingredients come in every day; each one is weighed, stored, prepped and turned into a bowl that has to ship the same day. Ingredients spoil, deliveries arrive short, a count is wrong by a crate. The purchase plan for tomorrow is only as good as the stock number from today, and in produce the difference between "running low" and "out" is a few hours.
That is why the bottleneck was operational and not commercial. Demand was there and growing. What the team lacked was a stock number it could trust without spending the day building it. The weighing was already happening; the number just was not making it into the system on its own.
“Even when you are a startup, you get the impression that the only way forward is to build something from the ground up. Jestor gave us an alternative that not only felt more natural, it was also really the only way to get us quickly where we wanted to be.”
The physical event was instant and the data event was batch
“When dealing with inventory, right and almost right are worlds apart. Products can spoil, and a shipment may not be delivered. Knowing the right numbers is what keeps the whole operation from going off the rails. For me, using Jestor and other software is exactly this: the difference between right and almost right.”
Reports and dashboards were built from data that had already aged. The line between "are we running low on this" and "we are out" was blurrier than the team could afford.
The team had built a small app on a spreadsheet-backed builder to register stock output. It made writing the number down easier. Everything downstream, extraction, import, treatment, stayed as manual and as slow as before. A traditional ERP was considered and set aside: it would have imposed a framework without solving this specific problem.
The pattern: the physical event (a crate on a scale) was instant, the data event was batch, and a spreadsheet stood between them. Nothing was broken enough to stop the kitchen. Everything was slow enough to cap how far it could grow without adding people to type.
Item by item, what did each job before and what does it today
| What did this before | What does it today |
|---|---|
| A spreadsheet row typed for each delivery received | The scale sends the weight through its API; the system records it and updates stock |
| Manual cleaning and treatment of each number | The system treats the incoming data before it lands in stock |
| Extraction and import repeated for every report | Stock per item per kitchen, with history, in one place, read directly |
| Dashboards built from periodic data | Views built on the live stock number |
| A collection-only app for stock output | A dedicated app for manual entries, with the entry triggering the automations that follow |
| Physical counts written down and reconciled by hand | A daily counting app: list of items to count, phone entry, automatic comparison of theoretical versus real |
| Purchase estimates built from stale numbers | Estimates built from current stock and history per kitchen |
What was not replaced. The scales stayed. The kitchens and the daily physical count stayed. The order channels and courier fleet were not part of this build. The case describes the system as the center of the stock process, collecting and sending data to other software when needed; it does not claim to have replaced that other software. No finance or accounting system is named in the source, so nothing is claimed about one.
The chain, end to end
- 1A purchase arrives and goes on the scalePerson
It arrives at the kitchen and someone puts it on the scale.
- 2The scale sends the weight through its APIAutomated
The open API is the single integration the flow rests on.
- 3The system treats the reading and updates stockAutomated
For that item, in that kitchen, at the moment of weighing.
- 4The counting app hands over the listAutomated
The warehouse worker gets the list of items to count that day.
- 5The worker counts and enters the real quantitiesPerson
On a phone, on the spot, with no paper in between.
- 6The system compares theoretical against countedAutomated
It flags the difference, which tells the team something about efficiency and storage conditions.
- 7Planning sizes the next purchasePerson
Stock and history per kitchen are reviewed and the order is set.
- 8Suppliers deliver, and the crate goes back on the scaleExternal
Outside the system, on the schedule the suppliers already keep.
The hard links are 1 and 5. The system cannot know a crate exists until someone puts it on the scale, and it cannot know the theoretical number is wrong until someone counts. The design does not pretend otherwise. It makes both actions the cheapest possible version of themselves: weigh once, with nothing to write down; count from a list, on a phone, with the comparison done for you.
“Now, all we have to do is weigh a product, and our inventory is automatically updated. Not having to write each quantity down between measurements makes things ten times quicker, and leaves no margin for error.”
Every change, with the basis beside it
| Indicator | Result | Where it comes from |
|---|---|---|
| Stock update on receipt | From a typed and treated spreadsheet row to automatic update from the scale | Published case, "Before" and "After" sections |
| Data latency | From periodic data and past-facing dashboards to stock updated at the moment of weighing | Published case; no latency was measured |
| Reporting effort | From repeated extraction and import to reading stock and history per kitchen in one place | Published case |
| Physical count | From written counts reconciled by hand to a list, phone entry and automatic theoretical-versus-real comparison | Published case |
| Time on data treatment | Described by the team as time now spent on planning rather than bookkeeping | Published case; the inventory keeper's "ten times quicker" is his own estimate in a quote, not a measurement |
No measured time, cost or waste figure exists in the source. The case describes the replaced routines and quotes the team on the effect. It does not report hours per week before and after, waste rate, stockout frequency or purchase accuracy. The one numeric claim, "ten times quicker", comes from an interviewee describing his own routine and is reported here as such.
"Automatic" starts at the scale, not before it. The scale reading is automatic. Getting the crate onto the scale is a person. The accuracy of the system is exactly the discipline of the weighing step plus the daily count that catches what weighing missed.
The company-scale figures are not results. Salads per day, salads per year and team size describe the operation the system was built for. Nothing in the source attributes any of them to the system, and this case does not either.
What this case does not measure
Worth naming, because it is usually what gets inflated.
All before-and-after descriptions and all quotes come from the company's team as published. No process was observed or timed independently.
Hours per week on inventory, waste as a share of purchases, stockouts per month, purchase forecast error: none of these appear before or after. They are the numbers a buyer would want and they were not measured.
It describes one person's experience of one task, weighing without writing. It is not a measured throughput figure and is not used as one.
The case was published in April 2022. The company has since raised again, opened more kitchens and its first restaurant. Whether the system described here runs unchanged today is not known to us.
The case says 160 team members; business press the same year reported close to 200. The two were likely measured at different moments; neither is verified here.
The source says a traditional ERP was considered and not adopted for this problem. It does not say what the company uses for finance, so this case does not say either.
The founder's quote in the original case includes a general judgement about traditional ERPs and custom software houses. That sentence was removed; the parts describing the company's situation and its choice were kept.
Food service is the largest source of waste outside the home
| Indicator | Number | Source |
|---|---|---|
| Food wasted at retail, food service and household level, globally, 2022 | 1.05 billion tonnes, about 19% of food available to consumers | UNEP Food Waste Index Report 2024, published March 2024 |
| Share of that waste generated by food service | 28%, about 290 million tonnes | UNEP Food Waste Index Report 2024 |
| Share of food lost in the supply chain before retail, globally | About 13% | FAO, as cited alongside the UNEP 2024 report |
| Share of fruit and vegetables lost between harvest and retail, globally | 25.4% in 2023, the highest of any commodity group | FAO, SDG indicator 12.3.1 data portal, updated June 2026 |
More than a quarter of consumer-level food waste happens in food service. A kitchen whose main input is produce, the commodity group with the highest loss rate in the chain, is exposed on both ends: it can lose product before it cooks and after.
Buying against a stale count means either over-purchasing perishable inputs or running short and substituting. The system in this case does not touch cold chain or shelf life; it touches the number the purchase decision starts from. That is the part of waste that is informational rather than physical, and it is the part a software build can move.
"One third of all food is wasted" descends from a 2011 estimate that the FAO has since replaced with two separate measures: loss before retail (about 13%) and waste from retail onward (about 19%). The old headline still appears everywhere. A kitchen operator should use the food-service share of the current index, not the 2011 number.
The system is built to fit, and responsibility for it stays with us
Olga Ri had already tried the two obvious routes. A collection app moved the problem downstream. A traditional ERP would have solved it inside a framework the kitchen would then have to live in. The question a bespoke system has to answer is what happens in year two: a stock app nobody can change is the new spreadsheet in three years, with a login.
One builder owns each request from start to finish, and one is always in execution.
A new flow, a new automation or a new report comes in through the same channel, without becoming a new project.
If what was built is not right, it is rebuilt. Unlimited revisions within the subscription.
Seats are never the billing unit, which matters when planners, kitchen staff, warehouse keepers and buyers all touch the same operation.
People learn to use their app the way they learn any app, by opening it. Building, configuring and maintaining stays on our side.
Full export at any time, by CSV and API. SOC 2 compliant, no exit fee. Pause in one click and the systems keep running.
Methodology and sources
The before-and-after descriptions and all three quotes come from the case study Jestor published in April 2022, written from interviews with the company's team. They are the team's own account and were not audited. The founder's quote was shortened to remove a general judgement about other categories of software.
Salads per day, salads per year and team size come from the case header, undated in the text and treated as of publication. Founding year, first venture round, the 2022 round, kitchen count and the 2023 restaurant come from business press coverage of the company between 2020 and 2023.
UNEP Food Waste Index Report 2024 (March 2024); FAO SDG indicator 12.3.1 data portal (updated June 2026).
No time saved, waste reduced, stockouts avoided or purchase accuracy is claimed as a result, because none was measured in the source. The "ten times quicker" estimate appears only as a quote, labelled as an estimate.