Research, Model, Delivery
The hard part of software is the domain, and most teams meet it by accident. We research it first, model how it works and the capabilities it needs, and deliver the product from there. AI makes the building fast. It is not why the software is good.
Work
Working software is the studio's proof. One system at a time, taken into the lab and built end to end, so every claim on this page has a running thing behind it.
-
Covalentteam
A 1:1 rhythm for engineering managers. It installs on a GitHub organisation, says who is due a conversation, and reads their month of pull requests, reviews and issues as one picture before you open it. Nobody is given a number, and a month later it is gone.
covalentteam.com -
Pip
Planning poker, free, with an AI at the table. It reads the story before the cards go down, so the round is spent on the work and not on the number.
Coming soon
Case studies
The research output of the studio. We write up what we built: the design decisions, the threat models, the dead ends. Not advice from the sidelines. Each study ripens on a real system the studio shipped and is picked only when it is ready. Three are picked so far. Leave an address at the foot of the page and the next comes to you the day it is picked.
-
The blueprint comes first, and the world is a layer over it
How a system begins as one page naming what it holds and what it needs from the world, and how declaring each need as a shape with a default lets the real thing be swapped in by one line, so a feature ships before the world is ready for it.
Read the study -
State is a record of what happened
One table of things that happened, the words the people and the code share, and the work of drawing the lines between the aggregates before the store makes them permanent.
Read the study -
Every state is drawn, and the match is exhaustive
A screen cannot stand in a state it has not drawn. The kernel cuts the unions, a leaf renders each member, the wrapper is nothing but an exhaustive match, and an absence is a value rather than a null.
Read the study
About the studio
Green Guava Tree is an independent software studio that works like a research lab. A domain is a set of capabilities. Get those right and the product mostly designs itself; get them wrong and no pile of features will save it. That modeling is the part a lot of teams now skip, and it is the part the studio is built around. We take one hard system at a time into the lab, build it end to end on modern infrastructure, and write up how it went, so the field gets evidence rather than opinions.
The method leaves a trail. The capabilities are named on a page before there is code to name them. Every decision about shape is written down with the argument that could turn out to be wrong, titled as the sentence it decided, where the next person will find it. State is kept as a record of what happened and folded into the present on the way out, so nothing is ever overwritten. What a product promises the people inside it is built as a shape the code cannot take, never as a setting somebody could switch off. AI has a real job in all of this: it makes the modeling and the building fast, and it runs more reliably and at lower cost over a domain that was modeled well. But it is the tool, not the point.
The studio was founded by Vidal Vasconcelos, an engineer and product thinker who holds software that reads people to the same rigour as any distributed system: capabilities before code, typed effects, event sourcing, security by design, and decisions you can audit in writing.
The name is the method. A guava tree grows slowly, keeps its years in its rings, and fruits only when it is ready. The rings are the decisions. The fruit is picked ripe, and what it was read from is gone a month later, on purpose.
-
A letter about the work Now and then, on what we are building and what it has taught us.