Transparency · How the studio actually operates
We run on our own systems. Here is what that actually means.
Most studios that sell an operating model do not describe their own. We would rather be specific about the parts we can honestly stand behind than write a page that gestures at transparency without saying anything checkable. Where a claim on this page isn't something we can point to elsewhere on the site, we have left it out rather than invented it.
The operating rhythm
We batch. We do not run a constant stream.
This is principle twelve of the studio's own operating principles, and it is the one clients notice fastest once they are inside an engagement: the calendar is not evenly full. It is deliberately uneven.
Long calendars, quiet weeks - by design
We batch transformations rather than run a constant stream of them. There are weeks on the studio's own calendar with no client meetings at all, deliberately - that is when the frameworks that every engagement runs on actually improve. A studio that is always in a call is a studio that has stopped thinking, and we would rather be honest about that trade-off than hide it behind a booked-solid calendar.
A capped number of engagements, not an open pipeline
The founder and the team behind him cannot honestly serve an unlimited number of organisations in a year at the depth the work demands, so we cap it and say so. This is the same logic as batching: depth on fewer things, not shallow coverage of many.
Contained on purpose - no account-manager layer
We are a studio, not an agency or a platform. One founder, a focused team, and no layer of account management sitting between a client and the person doing the work. That is a ceiling we hold ourselves to, not a growth plan we are working around.
We do not exempt ourselves from our own doctrine
The rules we install are the rules we run on.
Sequence over speed, applied to our own build
Name, systematise, automate - in that order, without exception - is the rule we install in every engagement. We do not exempt our own tooling from it: MatterOS and LexOS were both built after years of running the underlying discipline by hand, first for the founder's own no-code builds, then formalised as products.
Fixed price where our own work can be priced flat
Hourly billing trains a practice to record time rather than manage it - our own stated reason for moving clients off it. We hold ourselves to the same model: engagement fees are fixed and quoted before work starts, not metered against our own hours.
Working artefacts by week two, or it isn't a transformation
Every engagement we run has to produce something real inside the organisation within the first two weeks. That standard exists because we watched too many 'transformations' stay slideware past month three - so it is the bar our own delivery process is built to clear, engagement after engagement.
What a client installs, and what adnah runs itself
Two different systems, kept deliberately separate.
What a client installs
Tools they own, not tools we hold hostage
Every engagement plugs in software chosen for the fit: our own MatterOS and LexOS where they fit best, custom-built tools where there is a real gap neither covers, or market-available software where that is the more seamless and sustainable choice. What we build runs on tools a client already has or comes to own outright - the repository, the database, the domain, the keys. There is no proprietary adnah platform holding a client's matters hostage, and if the relationship ends, the practice keeps running exactly as it did the day before.
What adnah runs itself
The studio's own delivery discipline
The founder's own path runs from no-code builds, through Notion-architected systems - the discipline LexOS eventually formalised - to agentic AI today, across more than two hundred delivered systems. That same discipline, named, systematised and then automated in that order, is how the studio plans, scopes and delivers its own engagements. We do not publish the specific internal software stack behind our own project tracking; what we do commit to is holding ourselves to the same sequence and the same fixed-price discipline we install for every client.
On model choice
Model selection, not model worship.
We treat large language models as interchangeable drafting engines behind the evidence-anchoring rule, not as oracles to trust by brand. In practice this has meant running the same task through more than one provider's models on a client's own documents and choosing by measured output quality on that specific document type, rather than by a general preference - the same evaluation habit we teach in AI for lawyers and apply inside our own build process. We do not name a single default vendor as a matter of policy, for the same reason the guide is deliberately vendor-neutral: the tools change quarterly, and the discipline underneath them does not.
What this page does not claim
We have not listed the specific software behind our own accounting, communications or day-to-day project tracking, because naming it accurately here would mean disclosing operational detail we have not otherwise made public and cannot verify will stay current. What is on this page - the batching rhythm, the fixed-price discipline, the client-owns-the-tools boundary, and the vendor-neutral model policy - are commitments we can point to elsewhere on this site and hold ourselves to. If you want more detail than this page gives you before an engagement starts, ask in the intake note. We answer plainly or we say we cannot.
Read the rest of the operating principles