Markdown version

The first step

Show us your working product.

No technical audit, prepared repository, or full documentation is needed to begin.

Tell us briefly about the product and the reason you are considering a migration. We then arrange a free meeting at which your team shows us the product, its main roles, and its real journeys.

At the first meeting you show Pikiner your product. It is not a Gabion presentation and not a commitment to start a project.

We need to understand the product, not to judge how tidy the old code is.

For a first message it is enough to describe

  • what the product does and for whom;
  • which stage it is at;
  • who already uses it;
  • which hypothesis is proven;
  • which limits prompted you to consider a migration;
  • which roles and main journeys can be demonstrated;
  • whether there are integrations that matter particularly;
  • whether there are requirements for data, security, or confidentiality.

Do not send through the first form

  • passwords, API keys, and other secrets;
  • production data;
  • personal data of your users;
  • an archive of the repository;
  • source code;
  • private links carrying tokens;
  • internal financial documents;
  • information that cannot be disclosed without an NDA.

If you know the current stack you can state it, but it is not a condition of a first enquiry.

Tell us about the product

This form is only for a first introduction. Do not attach source code, user data, secrets, or internal documentation.

Fields of a first enquiry

Used only to reply to this enquiry and for the agreed correspondence that follows.

Your role

Do not add logins, passwords, invitations, or private links carrying tokens.

Which stage is the product at?

This helps us understand the technical context, but it is not required for a first enquiry.

What would you like to do first?

Do not send source code, passwords, production data, or personal data of your users.

The next step depends on what you asked for.

  1. 1. We read the description

    We check whether a working product already exists and whether the enquiry is the kind of migration Pikiner does.

  2. 2. We ask only the questions that are necessary

    If the information is not sufficient, we ask about the stage of the product, its main journeys, its technical context, or its confidentiality requirements.

    The repository and the source code are usually not required for that.

  3. 3. We arrange a free demonstration of the product

    If the enquiry matches the work of Pikiner, we arrange a meeting with someone who can show the product and explain its main user and administrative journeys.

  4. 4. We check technical compatibility

    After the demonstration we determine whether we see technical limits to applying the Pikiner production pipeline, and which information is needed next.

  5. 5. We continue scoping at no charge

    If the project is technically compatible, we request only the materials required and continue studying it until a fixed proposal is prepared.

    There is no separate mandatory paid discovery between the first meeting and the proposal.

Submitting the form creates no obligation for the client or for Pikiner, and does not mean the project is automatically accepted.

We need someone who knows how the product behaves.

The whole team does not have to attend the first demonstration.

One or two participants are enough, provided they can:

  • walk through the main user journeys;
  • show the administrative functions;
  • explain the roles and access rights;
  • name the integrations that matter;
  • describe the current limitations;
  • tell existing behavior apart from future features;
  • answer product questions, or pass them to the right specialist afterwards.

Usually that is a founder, a CTO, a product lead, or a senior developer.

If the decision involves an investor, a corporate customer, or an external owner of the technology, their participation can be planned for the next stage.

The product first. Technical materials only where they are needed.

After the first demonstration, determining the scope may call for:

  • a further demonstration of particular journeys;
  • a description of the roles and access rights;
  • a list of the business rules;
  • the current technology stack;
  • the structure of the repository from its root directory;
  • the data schema;
  • a list of the services;
  • a description of the deployment process;
  • documentation on the integrations;
  • access to a test environment;
  • access to particular parts of the source code;
  • written answers from the client team.

We do not request the full repository automatically.

The extent of each request follows the specific question that has to be answered in order to check technical compatibility or to prepare a fixed proposal.

We report a limit as soon as it becomes apparent.

Pikiner may decline a project if its mandatory functions, data, integrations, or other technical requirements are incompatible with our production pipeline.

In that case we explain the specific technical limit of the method.

Being unable to determine the scope or the price quickly is not a reason to decline.

If a project is technically compatible, scoping continues until a fixed proposal is prepared, even where that calls for further demonstrations, documentation, study of particular parts of the code, or written questions to the client team.

Once we know the product, we can demonstrate Gabion separately.

The Gabion Live Showcase is a separate free meeting for a project that is initially suitable for the Pikiner method.

At it, the Pikiner team demonstrates:

  • how Gabion organizes the structure of a project;
  • how the architectural constraints are applied;
  • how the system verifies changes;
  • how real errors are handled;
  • how the AI works within defined boundaries;
  • what the client team receives in order to develop the product further.

The Showcase is not the first demonstration, a technical audit, or a trial migration.

The order of the meetings:

  1. The client shows Pikiner their working product.

  2. Pikiner checks whether the method is initially applicable.

  3. For a suitable project, the parties hold a separate Gabion Live Showcase.

  4. Pikiner requests the information required for a fixed proposal.

Show enough for an assessment, and no more.

The first demonstration does not require access to the production infrastructure or to user data.

You can show the product on a test system, or through screen sharing by a member of your team.

Before any closed material changes hands, the parties determine:

  • whether an NDA is required;
  • which information may be shown;
  • whether the conversation may be recorded;
  • who will have access to the later materials;
  • how documents and access will be provided;
  • how long the materials may be retained;
  • when temporary access has to be revoked.

A meeting must not be recorded without the explicit consent of the participants.

If this is not about a specific migration

For investors and funds

If you want to discuss a possible migration for a portfolio company, select the role "Investor or fund representative" in the form and describe the context without disclosing confidential data of the startup.

A substantive assessment still requires the team of the product itself and the chance to see a working system.

For partners

If you represent a studio, a consultancy, or an infrastructure or technology partner, select the option to discuss a partnership.

Questions about Gabion

Questions about the technology, its future availability, and using Gabion outside a Pikiner migration are better directed through the Gabion site.

Prefer email?

Write to us: contact@pikiner.com

Subject line:

  • for a migration — Product migration — [company name];
  • for a general question — Question for Pikiner — [subject].

Do not send source code, passwords, secrets, production data, or personal data of your users by ordinary email.