Everything We Never Wrote Down
What I learnt building a product from zero to one
The first prototypes our designers built with AI were unusable. Not ugly. Off-model. Components that did not exist in our design system, spacing that followed no rule any of us recognised, interaction patterns invented on the spot. Each screen looked reasonable on its own and wrong the moment you put it next to something we had already shipped.
The first reaction in the room was to question the tool. We had that conversation for about a day. Then it became obvious that we had told it nothing. Our design system lived partly in a Figma library, partly in the heads of a few people, and partly in a set of conventions nobody had ever written down, because everyone already knew them.
So we built a designer agent. There was nothing clever about it. It was mostly a container for rules we had never been forced to say out loud.
That was the first time I saw the shape of the thing we were building, and I saw it from the inside.
We did not start from AI
It would be convenient to tell this story backwards. Team spots the AI opportunity, team builds the context layer, market agrees. That is not what happened. The first ideas came at the beginning of 2024, and it was a long journey before the agentic era began.
We started from a much less exciting observation. Over several years of customer conversations, the same friction kept surfacing: onboarding was hard, adoption was slow, and the surface area people had to understand before getting value was too large. The goal we set was simplification.
The Context Catalog began as an answer to that, a way to make the platform legible for the people using it. A map of what exists, how it relates, and under which rules it operates.
The AI connection arrived later, and by accumulation rather than insight. If you build a structured, queryable model of everything an organisation runs, you have also built the thing a model needs in order to say anything useful about that organisation. Nobody announced this in a meeting. It emerged over months of conversations until it became the obvious next sentence.
Tacit context is a small team’s superpower, right up until it is not
A small team building something new runs almost entirely on tacit context. Everyone was in the room for the decision, so nobody has to be told about it. Few things are documented because few things need to be. Writing things down for people who already know them is kind of a waste of time.
That efficiency has exactly two breaking points.
The first is a new person joining. This one is familiar and survivable, because humans absorb context by proximity. Sit next to the team for a month, listen to enough conversations, and most of what was never written down transfers anyway.
The second breaking point is a machine joining. This one is not survivable the same way, because there is no osmosis. A model does not overhear anything. It does not build intuition over three sprints. It arrives with enormous capability and zero situational awareness, every single time, and it will confidently produce something plausible and wrong rather than admit it does not know the house rules.
The most useful frame I found is this: bringing AI into your development cycle is like hiring a brilliant colleague who is permanently on their first day. Everything we never wrote down is now a defect. This will improve over time, but only if you have the context to share with your agent.
Changing how the team worked, and why
Two things changed in how we built.
The designers stopped delivering mockups and started delivering prototypes in code. They took to this with more enthusiasm than I expected. What won them over was immediacy: being able to touch the thing, click through it, and check whether a flow actually worked instead of arguing about whether it would.
The engineers moved towards spec driven development, particularly on the frontend, taking the designers’ output as input rather than as a picture to reproduce.
This is where the resistance showed up. Some of the engineers did not enjoy this at all, and some of them still do not. When you work this way, the code itself carries less of your identity. The craft moves upstream, into the specification, into the framing of the problem, into judgement about what should exist. If your professional pride was built on writing the code well, that shift feels like a demotion even when the output is better. Coding can be a form of art, so it is like taking the brush away from Botticelli because a machine can paint too.
What I would add is that none of these changes were made to go faster. That was the assumption from the outside, and it was wrong.
A Figma file transmits intent to a human being who can interpret it. A prototype in code transmits intent to a human being and to a machine, without interpretation. A ticket describes a task. A specification describes the reasoning behind the task, which is the part that survives being handed to somebody, or something, that was not in the room.
Conviction first, evidence later
At a certain point, the conversations in the market became more concrete about AI integration. Governance and control of AI inside complex organisations went from being one topic among several to being the topic our customers actually wanted to talk about.
We cut everything that did not point in that direction. Not gently, and not all at once, but steadily over months.
The most expensive part was cutting architectural decisions and pieces of functionality that were already implemented and no longer needed. There is a particular flavour of frustration in discarding good work that solved a problem you no longer have.
The harder problem was competence. Governance and compliance is a domain, with its own vocabulary, its own regulatory pressure, and its own idea of what a good answer looks like. We did not have that expertise on the team. So we went and got it the slow way: reading the market, studying what competitors had understood before us, talking to people who lived inside the problem.
This is the part of a zero to one journey nobody puts on a slide. You commit before you have evidence, because at zero there is no evidence to have. Then the evidence arrives, in fragments, and most of what it tells you is where not to go. Changing direction under that pressure is not a failure of strategy. It is what strategy looks like when the information arrives one discovery at a time.
We were building the thing we needed in order to build it
Every problem we hit internally was a small version of the problem we were building a product to solve. The design system that existed but was not accessible to anything automated. Decisions that lived in people’s memory rather than in a system. Rules that everyone followed and nobody had stated. Each of those is a context problem, and each of them was blocking us in exactly the way we were telling customers it would block them.
If we could not make the platform work for our own team, in our own building, against our own mess, the argument for anyone else was theoretical.
Three things I would tell myself at the start
Not rules. Observations from one product, in one company, under one specific set of constraints.
The first job in a zero to one effort is not deciding what to build. It is making transferable what the team already knows.
Changing priorities felt like instability while it was happening and reads as responsiveness in hindsight. I still do not know how to tell the difference in the moment, and I am suspicious of anyone who claims they do.
The last one matters most to me. What counts is the destination, and knowing you gave the best you had based on what you learned along the way. The journey has to be the enjoyable part, because you are going to spend most of your time in it. Discovering what is needed, continuously, beats receiving a list of requirements at the start and never revisiting it. If the discovery is not the fun part, the whole shape of this work is going to be miserable.
Two years of learning to say out loud things we already knew. That is the unglamorous version, and it is also building a product.