The standard we ask of others, applied to ourselves

Every review we do starts with the same question: who really controls this business's technology? Who holds the code, the cloud accounts, the domains and the data, and what happens to them if one person or one contractor walks away. It is the first of the six layers we read in every company, and it is often where the most expensive findings sit.

Before we asked that question of anyone else, we had to answer it for ourselves. This note is about how we did, what we hold ourselves to, and why we do not publish the blueprint.

The standard we ask of others

In a review we look at six layers, read from the ground up: ownership and IP, infrastructure and cost, data and privacy, code and architecture, security and access, and the team and its knowledge. In each one we ask for evidence rather than assurance. A founder saying the code is theirs is a statement. A repository in the company's own account, with contractor assignments on file, is evidence.

The findings that hurt a deal most are rarely exotic. A cloud account registered to a former contractor. A booking tool, a CRM or a document store rented on a founder's personal card. Customer conversations that live in a service nobody at the company can export. Each of these is ordinary on the day it is set up and expensive on the day a buyer asks about it. Our note on ownership gaps in a software acquisition describes how they reach the price.

The same questions, answered for ourselves

A firm that reads other companies for these gaps cannot carry them itself. So from the first day we set one rule for our own technology: the systems The Structure runs on are built for it and held by it, not rented from someone who can change the terms or read the contents.

That rule decided more than the website. The calendar where owners book a first conversation is our own. So is the console where inquiries arrive. The next two systems, an internal CRM and a data room of our own, follow the same rule. Each of them holds information that is confidential from the first minute: who is thinking about selling, who is looking to buy, which documents changed hands. That information should sit only in systems we control.

It also changes how we talk to clients. When an owner asks where their name, their numbers and their documents will live while we work together, the answer is not a list of third-party services. It is our own system, run by people we know.

What sits underneath, in general terms

Seen from the outside, our site is a few dozen calm pages. Underneath them is a set of connected systems, each with its own rules: the public site and its search, the console where articles and inquiries live, the calendar with its own rules for availability and confidentiality, a record of which search engines and AI systems read us, and a glossary and a calendar of deadlines that are checked against official sources and kept up to date on a schedule. They stand on one foundation and follow one set of standards, and every change passes its checks before it reaches a reader. When the site moved to a new foundation in its first days online, every public page was compared byte for byte before and after, and the switch went live only when all 47 checks had passed.

None of this was improvised for us. It rests on more than ten years of PERETZ building and running systems for its clients and for itself, and on the habits those years leave: record every request before anything else happens, try every change on a copy before the original, keep a way back for every move. The look of such a system can be copied in a week. The rules underneath it, and the judgement that decided each one, cannot be copied that way.

Why we do not publish how it is built

We write a great deal about how other companies should build and run their technology. We do not describe how ours is built, and that is deliberate.

A firm that handles confidential deal information has no reason to publish a map of the systems that hold it. Which components we use, how they are connected, where they run and who can reach what: that is exactly the kind of detail we would advise any client not to post on its website. The same discipline we recommend in the technical section of a data room applies here: share what a counterparty needs, under the right terms, and nothing more.

When a client needs to know more, for their own security review or their counsel's questions, we answer in a conversation under a mutual NDA. That is how it should work for any business that holds other people's secrets.

Who builds it

Our systems are designed, built and run by PERETZ, our engineering partner under common ownership, the studio The Structure grew out of. We say that plainly, because a firm that values disclosure should practise it.

The link runs through people as well as systems. Yevhen Borovoi founded both firms, and at PERETZ he also advises owners on technical debt. We do not pretend the link is not there, because a review is judged by its rules, not by the absence of connections. A person can hold two roles; a review cannot serve two interests. So the rules are about the work. We take one side per deal, hold no stake in the companies we review and take no success fee. Our conflict check covers the work of PERETZ, including any advice a company has had from its people. If PERETZ has worked on a company, we say so before we start and decline when it could affect our view. Work done by PERETZ is never checked by the people who did it. And a fix is never priced or sold inside a review: it is a separate contract with any team the client chooses. The full rules are on our page about what independence means in practice, and the PERETZ story of how The Structure was launched explains why review and repair stay separate.

For the team at PERETZ we are a client like any other, with our own brief and the final word on every decision. Two pieces of their work are public as their own case studies: our website and our brand identity.

From my side

My work is reading companies the way the other side of the table will, and asking the uncomfortable technical questions. I do not praise easily, and I do not like advertising anyone. So when I was asked how the work with the PERETZ team looks from my side, I answered the way I would about any contractor, in Russian, and this is my answer in English:

"I am grateful to PERETZ and to Yevhen for their direct involvement and for the speed at which the team works. I do not want to campaign for PERETZ or advertise it openly, I simply do not like doing that, so I will say it softly: these are professionals in their field whose eyes still light up after ten years in the same work. And I see a boutique attitude, and not only because Yevhen asked them to treat us that way. You feel it on calls with the team, in the depth of their questions and in the wish to develop an idea and propose a solution better than the one I had worked out. The calendar and the data room are examples."

The last line is the one I value most. Both systems began as my request, with my own calculation behind it. In both cases the team came back with questions first and a better solution after. That is what we want from anyone who builds for us, and it is what we try to give to the owners and buyers who work with us.

What this means for our clients

• Your information stays with us. What you share while booking, in a call or in documents is held in systems The Structure controls, not spread across rented tools.
• We hold ourselves to our own six layers. If we would flag it in your company, we do not accept it in ours.
• Details are available when you need them. If your security review or counsel needs to understand how we handle your data, we explain it under NDA.
• The rules are fixed. If PERETZ, or anyone from it, has worked on your company or your target, you hear it from us before we start, and that work is checked only by people who took no part in it.

If you are preparing a sale and want to see your company the way a buyer will, our exit readiness work starts with the same first layer: who really owns what.

Questions