The post has been translated automatically. Original language: Russian
The repository stores the history of the code. But the product story is usually much broader: it has founders, employees, contractors, external components, data, and solutions that once seemed obvious.
In the comments to the first article, we talked about the moment when the same question has to be collected from scratch for the second time — from people's memories, old chats and documents. The history of product creation consists of just such questions: how did it appear and on what basis does the company use everything from which it is assembled?
At first glance, the answer is simple: "We created it."
But the first version could have appeared before the company was registered. The interface was made by a contractor, and a separate module was made by another team. Inside there are open-source libraries, an external API, purchased images or fonts. The data for the first tests were collected separately. And some texts, designs, or code have already been created using AI tools.
As long as there are people around who remember all this, the story seems complete. Then someone leaves, the product changes architecture several times, documents remain in old folders, and before an investor, a large client, or entering a new market, the team has to deal with archeology.
For the first recovery, you do not need to immediately check the entire product and pick up every document for several years. We need a clear route.
First, determine what exactly we are restoring
The creation story is not a corporate chronicle or a list of everyone who has ever participated in a project. For a practical task, it is enough to link four things:
1. Product element — what exactly was created or obtained from the outside.
2. Source — who created it, transmitted it, or provided it.
3. The basis of use is an employment relationship, contract, license, terms of service, or other basis.
4. Next— the team can confirm this connection now.
It is better to start not with the entire code base, but with one critical contour: for example, a module without which the product does not work; an interface that the customer sees; a main database; a mobile application; a model or AI function.
This is how the work gets a boundary. Otherwise, one question quickly turns into an endless inventory of everything that has ever been opened on the team's laptops.
Step 1. Decompose the product into its elements
In the contract folder, the product often looks like a single object. In reality, it is assembled from different parts.:
- source code, individual modules and scripts;
- architecture, technical documentation and tests;
- interface, design system, illustrations, texts and fonts;
- databases and training sets;
- open-source libraries and other dependencies;
- external APIs, cloud services, and licensed software;
- models, prompta, settings and materials created using AI;
- domains, names, and other brand elements.
On the first pass, there is no need to argue which legal regime applies to each line. First, it is important to see the composition of the product. What is not on the map cannot be verified or consciously accepted as a risk.
Step 2. Build a timeline
It is more convenient to restore the history not by the current team structure, but by product versions.:
- a prototype before the company appeared;
- the first working version;
- connecting contractors;
- major redesign or migration to another architecture;
- launching the mobile app;
- adding data or an AI component;
- current version.
For each point, it is useful to ask: what appeared, who participated then, and in what capacity?
The last part is especially important. One person could first help the founder informally, then become a contractor, and later an employee. Today, the team perceives his contribution as a single whole, but the documents and grounds may have differed in different periods.
Step 3. Look not for one perfect document, but for a collection of traces.
Git really helps: it shows commits, dates, branches, and the development of individual parts of the code. But he won't tell the whole story. It is not always clear from the repository in what capacity the person worked, where the external fragment came from, what conditions the library had, or what was happening outside the code.
Therefore, different sources are useful.:
- repositories and revision history;
- tasks in Jira, Linear, Trello or another tracker;
- Figma and other version files;
- technical specifications and release descriptions;
- contracts, appendices, acts, invoices and correspondence;
- documents on hiring and changing roles;
- licenses and terms of external services;
- old demos, tests, and letters to clients.
None of these traces by itself is bound to provide a definitive answer. Their task is to help restore a continuous chain: element → person or source → conditions → current use.
Step 4. Do not confuse a lack of response with a violation
During such a parsing, it is very easy to turn every empty cell into a red flag. This prevents the team from honestly assembling the picture.
Four statuses are enough for the first pass:
- confirmed — the source, the basis and the evidence are clear;
- we need to verify — the answer is most likely known, but confirmation has not yet been found.;
- external component — you need to check the license, terms of use or restrictions;
- gap — it is unclear who created the element or why the company has the right to use it.
"We don't know" is not a legal conclusion. This is an honestly defined uncertainty that can already be dealt with.
The exact answer about the ownership of rights always depends on the jurisdiction, contracts and circumstances of creation. Therefore, such a card is not a substitute for a legal assessment. It gives it a factual basis — and does not allow you to waste time analyzing a product that exists only in general terms.
What to do if the required document is not available
Sometimes the necessary agreement, application, or act really does not exist. The most dangerous reaction here is to try to quickly make the past more accurate than it was.
First, you should save what is still available: repositories, task history, version files, correspondence, and a list of people who participated in the work. Then talk to them and record the reconstructed sequence of events, separately noting the confirmed facts, memories and places where the versions differ.
Such a record by itself will not replace the missing document and will not resolve the issue of rights. But it will not allow you to lose the last traces and will allow you to decide in detail what can be confirmed, what needs to be processed now, and where a separate legal assessment is needed. The document signed today should also not be perceived as a magic time machine: the way to close the previous period depends on the specific situation and the applicable law.
After that, it is useful to close the way for a repeat breakup. For example, you can agree that a new contractor does not start work until the result, the conditions of its use, and the place where the confirmations are stored are indicated in the card. Or that with each major release, the person in charge checks new dependencies, external materials, and AI tools.
Step 5. Set priorities
All gaps do not need to be closed at the same time. First, I would look at the elements that:
1. determine the main value of the product;
2. they appeared before the company was founded or when the legal entity was changed;
3. Created by contractors, former employees, or external teams;
4. contain third-party code, data, content or components with terms of use;
5. They are needed for the next event — a deal, an investment round, an enterprise client, or market entry.
AI tools are worth mentioning separately. Not because any use of them automatically creates a problem, but because after a few months, the team often no longer remembers exactly where they were used, what materials were loaded into them, and what conditions were in effect at that moment.
What does the minimum work card look like?
To get started, just one table with eight fields is enough.:
- product element;
- version or period of appearance;
- who created or provided;
- the role of this person or organization at that time moment;
- a document, license, or other basis;
- found confirmations;
- limitations and open questions;
- next action and responsible.
There is no need to immediately turn it into a complex system. The value appears at the moment when the team can open one line and see not only the name of the component, but also the entire logic of its appearance in the product.
The approach coincides with the basic logic of the WIPO IP audit: first identify the assets used, then check the grounds of ownership or use, third-party rights and gaps. But for a growing team, the first step may not be a large audit, but one critical product outline.
Fifteen-minute check
Take one element, without which the product will lose a significant part of its value, and try to respond in fifteen minutes.:
1. Who created it or where did it come from?
2. When did this happen?
3. What was the creator's relationship with the company then?
4. On what basis does the company use the element today?
5. Where is the confirmation?
6. What external conditions or restrictions are still in effect?
If the answers are found quickly and match the different team members, the story is already in good shape.
If you have to go to one person, search for an old chat and remember the file name, you have found the beginning of an archaeological dig. And it's better to hold them now, without a deadline from the investor or the client.
I'm wondering which source most often saves the product history of other teams: a repository, a task tracker, contracts — or a person who still remembers what it was like?
Репозиторий хранит историю кода. Но история продукта обычно гораздо шире: в ней есть фаундеры, сотрудники, подрядчики, внешние компоненты, данные и решения, которые когда-то казались очевидными.
В комментариях к первой статье мы говорили о моменте, когда один и тот же вопрос приходится второй раз собирать с нуля — из памяти людей, старых чатов и документов. История создания продукта как раз из таких вопросов: как он появился и на каком основании компания использует всё, из чего он собран?
На первый взгляд ответ простой: «Мы его создали».
Но первая версия могла появиться до регистрации компании. Интерфейс делал подрядчик, отдельный модуль — другая команда. Внутри есть open-source библиотеки, внешний API, купленные изображения или шрифты. Данные для первых тестов собирались отдельно. А какие-то тексты, дизайн или код уже создавались с помощью AI-инструментов.
Пока рядом люди, которые всё это помнят, история кажется цельной. Потом кто-то уходит, продукт несколько раз меняет архитектуру, документы остаются в старых папках — и перед инвестором, крупным клиентом или выходом на новый рынок команде приходится заниматься археологией.
Для первого восстановления не нужно сразу проверять весь продукт и поднимать каждый документ за несколько лет. Нужен понятный маршрут.
Сначала определить, что именно мы восстанавливаем
История создания — это не корпоративная летопись и не список всех, кто когда-либо участвовал в проекте. Для практической задачи достаточно связать четыре вещи:
1. Элемент продукта — что именно было создано или получено извне.
2. Источник — кто это создал, передал или предоставил.
3. Основание использования — трудовые отношения, договор, лицензия, условия сервиса или другое основание.
4. След — чем команда может подтвердить эту связь сейчас.
Начинать лучше не со всей кодовой базы, а с одного критичного контура: например, модуля, без которого продукт не работает; интерфейса, который видит клиент; основной базы данных; мобильного приложения; модели или AI-функции.
Так у работы появляется граница. Иначе один вопрос быстро превращается в бесконечную инвентаризацию всего, что когда-либо открывалось на ноутбуках команды.
Шаг 1. Разложить продукт на элементы
В договорной папке продукт часто выглядит как один объект. В реальности он собран из разных частей:
- исходный код, отдельные модули и скрипты;
- архитектура, техническая документация и тесты;
- интерфейс, дизайн-система, иллюстрации, тексты и шрифты;
- базы данных и обучающие наборы;
- open-source библиотеки и другие зависимости;
- внешние API, облачные сервисы и лицензируемое ПО;
- модели, промпты, настройки и материалы, созданные с помощью AI;
- домены, названия и другие элементы бренда.
На первом проходе не нужно спорить, какой правовой режим применим к каждой строке. Сначала важно увидеть состав продукта. То, чего нет на карте, невозможно проверить или осознанно принять как риск.
Шаг 2. Построить временную линию
Удобнее восстанавливать историю не по нынешней структуре команды, а по версиям продукта:
- прототип до появления компании;
- первая рабочая версия;
- подключение подрядчиков;
- крупная переработка или перенос на другую архитектуру;
- запуск мобильного приложения;
- добавление данных или AI-компонента;
- текущая версия.
Для каждой точки полезно спросить: что появилось, кто тогда участвовал и в каком качестве?
Последняя часть особенно важна. Один человек мог сначала помогать фаундеру неформально, затем стать подрядчиком, а позже — сотрудником. Сегодня команда воспринимает его вклад как единое целое, но документы и основания в разные периоды могли отличаться.
Шаг 3. Искать не один идеальный документ, а совокупность следов
Git действительно помогает: показывает коммиты, даты, ветки и развитие отдельных частей кода. Но он не расскажет всю историю. Из репозитория не всегда понятно, в каком качестве работал человек, откуда появился внешний фрагмент, какие условия были у библиотеки или что происходило за пределами кода.
Поэтому полезны разные источники:
- репозитории и история изменений;
- задачи в Jira, Linear, Trello или другом трекере;
- Figma и другие файлы с версиями;
- технические задания и описания релизов;
- договоры, приложения, акты, счета и переписка;
- документы о найме и изменении ролей;
- лицензии и условия внешних сервисов;
- старые демонстрации, тесты и письма клиентам.
Ни один из этих следов сам по себе не обязан дать окончательный ответ. Их задача — помочь восстановить непрерывную цепочку: элемент → человек или источник → условия → текущее использование.
Шаг 4. Не путать отсутствие ответа с нарушением
Во время такого разбора очень легко превратить каждую пустую ячейку в красный флаг. Это мешает команде честно собирать картину.
Для первого прохода достаточно четырёх статусов:
- подтверждено — источник, основание и доказательства понятны;
- нужно сверить — ответ, скорее всего, известен, но подтверждение ещё не найдено;
- внешний компонент — нужно проверить лицензию, условия использования или ограничения;
- разрыв — неясно, кто создал элемент или почему компания вправе его использовать.
«Не знаем» — это ещё не юридический вывод. Это честно обозначенная неопределённость, с которой уже можно работать.
Точный ответ о принадлежности прав всегда зависит от юрисдикции, договоров и обстоятельств создания. Поэтому такая карта не заменяет юридическую оценку. Она даёт ей фактическую основу — и не позволяет тратить время на анализ продукта, который существует только в общих словах.
Что делать, если нужного документа нет
Иногда нужного договора, приложения или акта действительно не существует. Самая опасная реакция здесь — попытаться быстро сделать прошлое аккуратнее, чем оно было.
Сначала стоит сохранить то, что ещё доступно: репозитории, историю задач, файлы с версиями, переписку и список людей, которые участвовали в работе. Затем поговорить с ними и записать восстановленную последовательность событий, отдельно отметив подтверждённые факты, воспоминания и места, где версии расходятся.
Такая запись сама по себе не заменит недостающий документ и не решит вопрос о правах. Зато она не даст потерять последние следы и позволит предметно решить, что можно подтвердить, что нужно оформить сейчас, а где понадобится отдельная юридическая оценка. Документ, подписанный сегодня, тоже не стоит воспринимать как волшебную машину времени: способ закрытия прошлого периода зависит от конкретной ситуации и применимого права.
После этого полезно закрыть путь для повторения разрыва. Например, договориться, что новый подрядчик не начинает работу, пока в карте не указаны результат, условия его использования и место хранения подтверждений. Или что при каждом крупном релизе ответственный проверяет новые зависимости, внешние материалы и AI-инструменты.
Шаг 5. Расставить приоритеты
Все разрывы не нужно закрывать одновременно. Сначала я бы смотрела на элементы, которые:
1. определяют основную ценность продукта;
2. появились до создания компании или при смене юридического лица;
3. создавались подрядчиками, бывшими сотрудниками или внешними командами;
4. содержат сторонний код, данные, контент или компоненты с условиями использования;
5. нужны для ближайшего события — сделки, инвестиционного раунда, enterprise-клиента или выхода на рынок.
Отдельно стоит отметить AI-инструменты. Не потому, что любое их использование автоматически создаёт проблему, а потому, что спустя несколько месяцев команда часто уже не помнит, где именно они применялись, какие материалы в них загружались и какие условия действовали в тот момент.
Как выглядит минимальная рабочая карта
Для начала достаточно одной таблицы с восемью полями:
- элемент продукта;
- версия или период появления;
- кто создал или предоставил;
- роль этого человека или организации на тот момент;
- документ, лицензия или иное основание;
- найденные подтверждения;
- ограничения и открытые вопросы;
- следующее действие и ответственный.
Не нужно сразу превращать её в сложную систему. Ценность появляется в тот момент, когда команда может открыть одну строку и увидеть не только название компонента, но и всю логику его появления в продукте.
Подход совпадает с базовой логикой IP-аудита WIPO: сначала определить используемые активы, затем проверить основания владения или использования, сторонние права и пробелы. Но для растущей команды первым шагом может быть не большой аудит, а один критичный контур продукта.
Проверка на пятнадцать минут
Возьмите один элемент, без которого продукт потеряет существенную часть своей ценности, и попробуйте за пятнадцать минут ответить:
1. Кто его создал или откуда он появился?
2. Когда это произошло?
3. В каких отношениях с компанией тогда находился создатель?
4. На каком основании компания использует элемент сегодня?
5. Где лежит подтверждение?
6. Какие внешние условия или ограничения продолжают действовать?
Если ответы находятся быстро и совпадают у разных участников команды — история уже в неплохом состоянии.
Если приходится идти к одному человеку, искать старый чат и вспоминать название файла, вы нашли начало археологических раскопок. И лучше провести их сейчас, без дедлайна от инвестора или клиента.
Мне интересно, какой источник чаще всего спасает историю продукта у других команд: репозиторий, трекер задач, договоры — или человек, который всё ещё помнит, как это было?
Share
