Markdown version

From a working MVP to a production system

Change your stack. Keep your team.

Pikiner migrates working digital products from prototype implementations to a production stack: Java, Spring, PostgreSQL, and TypeScript.

Your team retains its product knowledge and continues to develop the product with AI through Gabion — without hiring a separate team of Java developers.

Before work begins, we record what is migrated, what it costs, and when the new system will be ready.

Show Us Your Product How the Transition Works
  • A working product instead of an abstract specification
  • Fixed scope, price, and date
  • The new system is built alongside the one you are running
  • Your existing team stays with the product

Once the hypothesis is proven, the responsibilities of the system change.

An MVP exists to answer one question as fast as possible: does the market want this product? At that stage, proving the hypothesis quickly matters more than the longevity of the system.

A prototype stack can be the correct engineering decision at that stage. Choosing one is not a mistake, and it does not reflect on the competence of the team that built the first version.

Once the hypothesis holds, the task of the product changes. The system now has to operate with real users and real data, withstand growth, ship changes predictably, and remain maintainable as the business logic grows more complex.

Sometimes the limits come from the stack. Sometimes they come from the architecture, the data model, the dependencies, the deployment model, or a combination of several decisions.

The need for migration is therefore determined not by the name of a technology, but by the gap between what a working product is now responsible for and what its current implementation can support.

The best time to discuss a transition is before an outage forces it: the hypothesis is proven, the product is running and serves as an exact record of its own behavior, and the team can still plan a change of technical foundation without constant incident response in production.

What Changes in the Transition

AI works on the stack. Your team works on the product.

Changing stacks used to mean finding another team, almost without exception. New developers had to learn the business logic, and the original team had to hand over its product knowledge to people who had not participated in building it.

Gabion changes that division of labor.

Your team defines the product

Your team retains the context: the users, the business rules, the exceptions, and the reasons behind past decisions. It sets the tasks, reviews the results, and directs the development of the product.

AI works on the stack

An AI assistant writes and changes the Java, Spring, PostgreSQL, and TypeScript code. A developer does not have to master the full set of production-stack libraries before the work can begin.

Gabion holds the architecture

Gabion sets one consistent way to build the system, provides the critical components ready-built, and verifies decisions at the points where convincing-looking AI code most often turns out to be wrong.

Product knowledge stays inside the team you already have, and moving to another stack is not about people replacement.

Gabion is used for development; it is not a condition of the application's operation. The delivered product builds, deploys, and runs independently of it.

How Gabion Works

We migrate what the product does, not the architecture it does it with.

A running product shows what actually has to be preserved more accurately than any document: roles, business rules, user journeys, data, integrations, and how the system responds.

Therefore, the existing version becomes an executable specification.

Pikiner does not translate the old code line by line, and does not reproduce technical decisions simply because they are in the old repository. We build a new implementation of the agreed behavior on the Gabion production pipeline.

  1. 1. You show us your product

    During the first free meeting, it is the client who demonstrates the working product to the Pikiner team:

    • the main user roles;
    • the key user journeys;
    • the administrative functions;
    • the business rules;
    • important states;
    • data at the level necessary to understand the product;
    • the main integrations;
    • known limitations;
    • the main reason for migrating.

    If the current stack and deployment method are known, it is useful to briefly describe them, but this is not a requirement for the first meeting.

    For the first meeting, it is not necessary to:

    • hand over the repository;
    • provide production access;
    • prepare a technical audit;
    • tidy up the code;
    • write full documentation;
    • prepare a repository tree in advance;
    • disclose secrets;
    • share production data.

    During the first meeting, the client demonstrates the product to the Pikiner team. Gabion is demonstrated separately, later.

  2. 2. We check technical compatibility

    First, Pikiner establishes whether the required features, data, integrations, and operational requirements of the product are compatible with our production pipeline.

    The current stack itself does not determine compatibility: the new system is in any case created on the Pikiner architecture (Gabion).

    A technical incompatibility may be caused by a mandatory requirement that the new system must maintain, but which Pikiner's production pipeline is not able to implement or support.

    For example:

    • a mandatory runtime environment the target platform cannot host;
    • a contractual ban on the use of the necessary technology;
    • a mandatory architectural boundary incompatible with Gabion;
    • a technical requirement for data or integration that cannot be met in the target system;
    • any other specific mandatory property of the product that falls outside the Pikiner method.

    The absence of a ready-made internal module is not an automatic reason for rejection. If the required component can be implemented within the Gabion architectural rules, creating it is part of the Pikiner team's own work.

    If a technical incompatibility becomes apparent, we report it immediately and explain the specific method limitation.

    The rejection is not explained by Pikiner's failure to determine the scope, price, or internal method of implementation.

  3. 3. For a compatible project, we scope the work at no charge

    If the product is compatible, Pikiner gathers what a fixed proposal requires at its own expense.

    Later on, this may call for:

    • further demonstrations;
    • a description of the current stack;
    • a directory tree from the repository root;
    • documentation;
    • a conversation with the team;
    • a description of the integrations;
    • limited access to the code under an NDA.

    We do not sell a separate paid discovery before the proposal.

    The client does not receive a standalone audit, a report on the old architecture, or a plan for repairing it. What this pre-sales work produces is the Pikiner proposal.

  4. 4. We record the result

    Before development starts, the parties agree on:

    • the baseline of the working product;
    • the behavior being migrated;
    • the exclusions;
    • the responsibilities of each party;
    • the acceptance criteria;
    • the handover contents;
    • the price;
    • the date;
    • data and infrastructure;
    • the terms of the project edition of Gabion.

    These terms are fixed in the contract and the SOW.

  5. 5. We build the new implementation

    Pikiner builds a separate project in Java, Spring, PostgreSQL, and TypeScript.

    The existing system continues to serve its users.

    The new version is built alongside it and is available to the client for review.

  6. 6. The client verifies the result

    The client receives a release candidate and verifies the agreed scenarios within a set period.

    If the new system does not reproduce behavior covered by the SOW, Pikiner corrects the discrepancy within the project.

    Acceptance is not used to add new features.

  7. 7. We migrate the data and switch users over

    If migrating production data is part of the SOW, the parties define in advance:

    • the sources;
    • the volume;
    • the transformation;
    • the cleanup;
    • a trial migration;
    • the completeness check;
    • acceptable downtime;
    • cutover;
    • rollback.

    Actual infrastructure, production deployment, and the switchover are included only when explicitly specified in the SOW.

  8. 8. We hand over a self-contained project

    The client receives:

    • the application source code;
    • the business logic;
    • the data structure;
    • the migrations;
    • the tests;
    • the configuration;
    • the documentation;
    • a deployment-ready result;
    • the project edition of Gabion for the first year.

    The production application runs without an active connection to Gabion.

A separate Gabion Live Showcase

For a suitable project, Pikiner may offer the CTO or the technical team a second free meeting.

In it, the Pikiner team demonstrates:

  • a prepared project;
  • Gabion Runtime;
  • interaction with the AI;
  • a real architectural error;
  • the diagnosis;
  • the correction;
  • the re-check;
  • an independent build.

The Gabion Live Showcase:

  • is not the first meeting;
  • does not replace the demonstration of the client's product;
  • is not a trial;
  • does not provide a token or standalone access.

First, the client demonstrates their product to Pikiner. Then Pikiner may demonstrate Gabion to the technical team, separately.

The Migration Process in Detail Contract, IP, and Product Independence

For a product that has already proven it should exist.

Pikiner does not build an MVP from an idea, and does not repair isolated pieces of old code. Our method is intended for the next stage — when the product already exists and its technical foundation has to be replaced while preserving proven behavior.

We should talk if:

  • your product runs and you can demonstrate it;
  • the hypothesis is confirmed by users, pilots, revenue, or funding;
  • the system already holds coherent business logic that has to be preserved;
  • your team is preparing for growth, or already sees the limits of the first implementation;
  • your company has the authority to change the product's architecture and stack;
  • the task is to migrate working behavior, not to invent core functionality from scratch.

Our method is probably not suitable if:

  • the product so far exists only as requirements, mockups, or unfinished modules;
  • the main task is to develop and validate new features;
  • specific bugs in the existing code need fixing urgently, with no change of technical foundation;
  • a mandatory stack is set by an external client, a partner, or a contract;
  • the behavior of the system cannot be demonstrated or recorded unambiguously.

A first conversation does not oblige you to start a project. Its purpose is to determine whether our migration method applies to your system, and whether the outcome can be defined before the work begins.

Frequently Asked Questions

Show us your working product.

The first step is a free meeting where you demonstrate your existing system to the Pikiner team.

We need to see the product as your users and your team see it.

What to show

For a first conversation, it is enough to:

  • walk through the main user journey;
  • show the administrative functions;
  • explain roles and permissions;
  • name the important integrations;
  • describe the data briefly;
  • show the important states and exceptions;
  • explain the main limitation, or the reason for migrating.

If the current stack, the structure of the system, and the deployment method are known, it is useful to briefly describe them. There is no need to prepare these materials specially for the first meeting.

What you do not need to prepare

There is no need for:

  • a full audit;
  • a tidied-up repository;
  • a complete tree, if you do not have one at hand;
  • production access;
  • production data;
  • an archive of the source code;
  • architecture documentation;
  • your own estimate of the rewrite;
  • secrets and API keys.

If a directory tree can be shown without extra preparation, it helps us understand the structure of the current project. Handing over code for the first meeting is not necessary.

What happens next

First, the Pikiner team checks the technical compatibility of the product with the production pipeline.

If an incompatibility is detected, we report it immediately and explain the specific technical limit.

If the product is compatible, we continue scoping at no charge, up to a proposal that fixes:

  • the result;
  • the price;
  • the date;
  • the acceptance criteria;
  • the handover contents;
  • the Gabion terms.

We do not sell a separate paid discovery before the proposal.

Confidentiality

A first conversation does not require you to disclose anything that cannot be demonstrated without an NDA.

If the substantive assessment requires confidential materials, the parties will first agree on an NDA and a secure method of delivery.

Do not send through the first form:

  • source code;
  • production data;
  • personal data of your users;
  • passwords;
  • tokens;
  • API keys;
  • private keys.

Gabion Live Showcase

The Showcase is not booked through the first form.

If a project is initially suitable, Pikiner may offer a free meeting to the technical team, where the Pikiner team will demonstrate Gabion.

The first meeting is about your product. Gabion is demonstrated separately, later.

Show Us Your Product

The first meeting and the scoping of a compatible project are free.

The Migration Process Frequently Asked Questions Contract, IP, and Independence