Case study

Winery OS: from 18 people to 10 after the move to Praxis

Winery OS is the winemaking platform of the group behind Praxis. After its development moved to Praxis in March 2026, the group's VP of Engineering reports a team of 10 on the same volume of work that took 18. Every change now traces back to a change request.

Published · Updated

Talk to us

01

Context

Winery OS is a platform for running a winery: vineyard, laboratory, and cellar work in one operational record. It runs at a working winery, which we do not name.

The product is owned by the group behind Praxis and built in-house by the group’s engineering team. Since March 2026, when Praxis was in early beta, its development has run on Praxis, the group’s open method and toolchain for delivering software.

02

Challenge

Any founder who has handed software between teams knows this picture. A decision is made in a meeting and not written down. Requirements are filled in on the fly. Nobody can say at which step a decision changed, and later the question “why is it built this way?” has no answer you can check.

Winery OS’s own first version shows what missing records cost. The MVP was delivered before Praxis, and no artifacts of that delivery survive, so the decisions taken then cannot be checked today.

03

Method

On Praxis, a change to Winery OS moves through three steps, and each step ends in a human gate, where a person approves the result before the next step starts.

Flow diagram, top to bottom. A change request from the client or the product side goes to analysis, where the business analyst turns it into work packages; a model drafts each requirement and a person checks it. The work package then goes to architecture, where the architect adds design and architecture and is the last to edit it, and then to development, where the developer works only from the agreed work package. A human gate stands at the exit of each of these three steps. The code is then accepted through two lenses: technical quality against the team’s standards, and a business check that the code implements the tasks of the work package. A person owns the merge. Every line of code links to a requirement, and every requirement links to the change request.

A change moves from request to merge, and a person approves each step. Every line of code traces back to a change request.

  • Analysis: The business analyst turns a change request from the client or the product side into work packages. A work package is a decomposed list of tasks. A model drafts each requirement in it, and a person checks it.
  • Architecture: The architect adds design and architecture to the work package and is the last to edit it.
  • Development: The developer works only from the agreed work package.

The code is then accepted through two lenses, and the merge stays with a person:

  • Technical: Code quality is checked against standards that the team configures. The whole change is analyzed, and quality comments are left on it.
  • Business: An AI reviewer takes the work package and checks that the code implements its tasks.

The result is a chain from request to code. Every line of code links to a requirement, and every requirement links to a change request. Any change can be traced back to where it came from, and a new team member or a later owner gets the decisions behind the code, not only the current requirements.

Two periods of Winery OS development, top to bottom. Until March 2026, before Praxis: no records of the MVP delivery survive, so the decisions of that time cannot be checked, and the team had 18 people. In March 2026, in the early beta of Praxis, development moved to Praxis. From March 2026, on Praxis: every change traces back to a change request, and the team has 10 people on the same volume of work. Team size is as reported by the group’s VP of Engineering.

Before and after the move to Praxis. Team size as reported by the group’s VP of Engineering.

04

Result

18 people
Before Praxis, until March 2026
10 people
On Praxis, same volume of work

Both figures are an internal count by the group’s VP of Engineering.

05

Limits

  1. This is not a controlled comparison. “Before” is development until March 2026, and “after” is development on Praxis from March 2026. Other factors, such as the maturity of the product and its stage, are not separated out, so we cannot say how much of the change comes from Praxis.
  2. The figures count people, not work. There is no breakdown by role and no published measure of the volume of work. Delivery measures such as time from task to release are not available for both periods.
  3. This is the group’s own team on the group’s own product. A different team on a different product may see a different result.

Your own project

If you want your team to deliver with a written record behind every change, talk to us. Bring the product you are building, the size of your team today, and the decisions you cannot afford to lose.

Talk to us