About the company
Pikiner migrates working digital products from a prototype technical foundation to a production stack, without the need to replace the team that knows the product.
For that we developed Gabion: an environment for human and AI to work together, which sets the architecture, provides verified components, and controls the critical decisions of development.
Modern tools let a small team build an MVP quickly, test a hypothesis, and reach its first users. That changed how fast new products appear, but it did not remove the requirements that arise once the idea is proven.
When a system becomes part of a real business, it has to work predictably with users and data, withstand growth, separate access securely, and stay comprehensible under constant change.
At that point a company often faces an unwelcome choice: keep building the product on top of the first implementation, or change the stack together with the developers. The second option means losing the product context, a long knowledge transfer, and new risk for the business.
Pikiner exists to remove that choice. We replace the technical foundation of the product and keep the people who understand why it is built the way it is.
Our task is to carry the product to its next stage without making the company start again with a new team.
AI assistants sharply increased the volume of code a developer can produce. At the same time, the nature of engineering risk changed.
An error made by an AI does not always look like broken code that fails to compile. The result often looks tidy, passes a surface review, and matches the stated requirement, but rests on a misunderstanding of a library, an architectural pattern, or a security constraint that was not obvious.
Such code became harder to review: seeing the correct result on an ordinary journey is no longer enough for a reviewer. The premises of the decision have to be reconstructed, and each technology inside a growing stack has to be confirmed as correctly used.
Gabion was originally built to take exactly that load off the CTO. It set a consistent architecture and verified decisions at the points where a plausible error is most dangerous.
Gabion gradually brought together the stack, the architectural constraints, the critical components already built, the deterministic checks, and an interface for AI assistants and agents.
That made it usable not only for controlling individual changes, but for systematically migrating a working product to a new technical foundation.
The transition of a working product cannot be resolved by choosing a new framework. It requires understanding the business value of the existing functions, the behavior of current models, and the constraints of a production system, all at once.
The Pikiner team combines these three areas:
Determining which result the company needs, how to record the boundaries of the project, and how to make the transition economically predictable.
Understanding the capabilities and the limits of models, the quality of their output, work with data, and the classes of error that arise in AI-assisted development.
Building the system on a production stack, turning repeatable decisions into a production pipeline, and handing the result to the existing team.
Gabion emerged at the intersection of these competencies. The Pikiner service became a way to apply them to a product that already runs.
The Pikiner team combines commercial accountability, AI expertise, and the development of production systems.
These competencies are used as a single process: from the first acquaintance with a product to the architecture of the new implementation, the acceptance, and the handover of the project to the existing team.
CEO
Responsible for the development of Pikiner, relationships with clients, and the commercial side of projects. Has experience with financial and accounting processes, and develops in TypeScript and Next.js.
Polina connects the business objectives of the client with the production process of Pikiner: from the first enquiry and the demonstration of the working product through to the contract structure, the acceptance, and the handover of the project.
Technical experience in TypeScript and Next.js lets her discuss not only the commercial terms but also the behavior of the product for its users, the frontend, the integrations, and the working process of the team.
CTO
AI expert in 3D deep learning and digital geometry processing. Works with machine learning, computer vision, signal processing, Python, C++, LLMs, and blockchain technologies.
Alexandra is responsible for the technical strategy of Pikiner, the application of AI, and the assessment of models. She helps turn complex engineering questions into verifiable project requirements.
Her experience covers deep learning, computer vision, acoustic signal processing, autonomous systems, robotics, and the development of technology products.
Alexandra has developed neural network methods for matching 2D and 3D data for the navigation of autonomous vehicles, networks for classifying three-dimensional objects, and algorithms for face protection and recognition in C++. Earlier she took part in developing medical algorithms and preparing data for submission to the FDA.
She holds an M.Sc. in autonomous systems and robotics, a B.Sc. in electrical engineering, and a B.Sc. in biomedical engineering, and completed the entrepreneurship MBA program at the Technion. Her doctoral research is in 3D deep learning and digital geometry processing.
Head of Engineering
Full-stack developer and architect with experience in Java, JavaScript, TypeScript, React, Angular, Next.js, PostgreSQL, Oracle, and cloud platforms. Responsible for the production method of Pikiner and the development of Gabion.
Nikolai designs and builds information and web systems, including high-load applications on Java EE and Oracle, AI-oriented products on Next.js and AWS, cloud infrastructure, and development tools.
An engineering approach to the recurring problems of AI-assisted development led to Gabion — a production pipeline in which the stack, the architectural boundaries, the modules, and the critical checks are agreed in advance for a human and an AI to work together.
At Pikiner, Nikolai is responsible for the design of the production method, the architecture of the products being migrated, the development of Gabion Runtime, and the internal module system.
gabion.manifest.json;Polina is responsible for the commercial and organizational boundary of a project.
Alexandra is responsible for AI, the models, the algorithms, and the technical assessment of requirements.
Nikolai is responsible for the architecture, the production pipeline, and the engineering implementation.
Together these roles let Pikiner:
The obligations are taken on by Pikiner Inc., not by an individual member of the team.
The company is accountable for:
The presence of these specialists on this page does not mean that, after the migration, the client receives:
New work after the handover is possible only under a separate SOW.
Pikiner combines business, AI, and engineering implementation in one production process. The company is accountable for the result.
We use the running system as the executable specification and preserve its agreed behavior, not the technical accidents of the previous implementation.
If the scope cannot be determined reliably, or the product does not fit the production method, we say so before the contract.
The people who built the product hold the knowledge of its users and its business logic. Changing the stack must not destroy that context.
Recommendations in documentation are not enough if an AI or a developer can bypass them unnoticed. Critical constraints have to be verified by a tool.
Gabion helps build the system, but the application handed over has to run independently of any further access to it.
The price, the date, the responsibilities of each party, and the criteria for the result are fixed after the working product has been assessed, and changes are recorded separately.
Pikiner uses Gabion to build and hand over new implementations of working products.
The relationship between them must not blur the accountability of the company, the rights of the client, and the ownership of the internal technology.
Pikiner is the company that provides the service of migrating a working product.
Pikiner is responsible for:
The contract is concluded with Pikiner Inc.
Gabion is the closed production technology of Pikiner for development by a human and an AI together.
Gabion comprises:
gabion.manifest.json;Gabion is developed by the engineering team of Pikiner, led by Nikolai Orobets.
A separate application directory is created for the client.
It contains:
The entire content of the directory handed over belongs to the client under the terms of the contract.
The project is not an internal Gabion directory and does not require the Runtime to operate in production.
The anonymized source module templates are held in the internal storage of Pikiner.
If an agreed project requires a new module:
The code and configuration that entered the directory of the project handed over belong to the client together with the project.
| Object | What it is responsible for | Who owns it |
|---|---|---|
| The migration service | A defined result, the price, the date, and the handover | An obligation of Pikiner Inc. |
| The project of the client | The specific application, its logic, data, and configuration | The client |
| Gabion Runtime | The development tools, MCP, and the checks | Pikiner |
| The internal storage | The anonymized module templates | Pikiner |
| The project license | The right to use Gabion for the project handed over | Granted to the client for a term |
| The production application | The operation of the product and the user journeys | Runs under the client's control |
Gabion takes part in creating and changing the project.
The production application must not:
Before handover, the project goes through a clean build without the Runtime, the token, and the internal storage.
The client receives the project edition of Gabion for the first year, under a separate license.
It is intended for continuing the development of the specific product handed over.
The license does not automatically grant:
After the first year, the client can renew Gabion or continue development without it.
A separate site for Gabion does not mean the technology is already sold as a standalone product available to everyone.
At present, Gabion is provided to clients together with a Pikiner migration.
As yet there is no:
Future arrangements may be considered separately, but dates, prices, and functions are not published before they are approved.
At the first free meeting, the client demonstrates their working product to the Pikiner team.
If the project is initially suitable, Pikiner may separately offer the CTO or the technical team a Gabion Live Showcase.
At the Showcase, the Pikiner team demonstrates:
Deeper questions that require additional technical verification receive a written answer after the meeting.
Pikiner is accountable for the migration. Gabion provides the production pipeline. The client owns the project handed over.
How the Migration Works Contract, IP, and Independence Gabion Technology
The client contract is concluded with Pikiner Inc. The engineering team works remotely and combines experience in development, AI, algorithms, cloud infrastructure, and business processes.
We do not substitute geography for the substance of the work: the proposal and the contract state the legal party, the division of responsibility, and the terms of the project explicitly.
At the first free meeting, you demonstrate the existing system to the Pikiner team.
What we need to see:
For a first conversation, it is not necessary to:
First, Pikiner checks the mandatory properties of the product for compatibility with the production pipeline.
If a technical incompatibility is detected, we report it as soon as it becomes apparent and explain the specific technical limit.
A project may be declined because the method is incompatible with a mandatory requirement of the product, never because Pikiner was unable to determine the scope or the price.
If the product is compatible, Pikiner continues gathering the necessary information at no charge, up to a fixed proposal.
Later on, this may call for:
A separate paid discovery before the proposal is not sold. The client does not receive a standalone audit or an architectural assessment of the old system.
Before the work begins, the following are fixed:
The first meeting is held by members of the Pikiner team able to discuss the product, its technical context, and the migration requirements.
If a question requires additional verification of how Gabion Runtime, the modules, or the internal processes are built, the team records it and comes back with a written technical answer.
If the project is initially suitable, Pikiner may offer the CTO or the technical team a second free meeting.
At the Gabion Live Showcase, the Pikiner team demonstrates:
This is not the first meeting, not a trial, and not a transfer of access to Gabion.
First you demonstrate your product to us. Then we may separately demonstrate Gabion to your technical team.
How the Migration Works Contract, IP, and Independence Frequently Asked Questions