Ownership, handover & continuity

ReApptor can, of course, maintain and extend the solution. Any experienced .NET / React development team can also maintain it, once onboarded.

We can support this by providing:

• Architecture and data model documentation
• Onboarding sessions for third-party developers
• Formalised knowledge transfer packages, if desired

We also have references where an external development team has delivered and maintained a customer-specific solution on ReApptor, with ReApptor providing technical support and guidance as needed.

Because the customer receives a fully independent development and runtime environment (separate Jira workspace, Git/Bitbucket repositories, Terraform/IaC, and a dedicated AWS environment), the dependency level is comparable to any professional vendor delivering and supporting a tailored business system.

You will not be locked into an opaque “black box”:

• Your solution consists of readable standard code, documented data structures, and transparent configuration that can be understood and reused.
• If at some point you decide to involve additional developers or another delivery partner, this is both technically and organisationally feasible, because the solution is maintained in normal engineering tooling and repositories.

We make this explicit through:

• Clear IPR and ownership clauses
• Explicit documentation deliverables
• Optional source code escrow/continuity arrangements

The solution is designed to be portable by default because it is delivered as a standard codebase, not as logic locked inside a proprietary runtime.

Portability in practice

The solution can be run locally on a developer machine (macOS / Windows) without external dependencies beyond standard development tooling (and it can be operated without relying on any proprietary ReApptor runtime).

The cloud deployment is not AWS-locked: it can be moved to alternative cloud platforms (e.g., Azure or Google Cloud) without changing the application architecture or rewriting the code.

The handover includes not only the application code, but also the deployment automation (CI/CD), and integrations with monitoring/logging tooling (e.g., Site24x7 / Splunk) and development tooling (Jira / Bitbucket), depending on what is used in the target setup.

Freedom to keep, replace, or rewrite parts

Reusable services/components that are part of the delivered solution can be kept as-is, extended, or replaced with alternative implementations if required (they are not dependent on a closed platform engine).

Source code and delivery assets

From day one, the customer receives read-only repository access to customer-specific assets for auditability, including source code, CI/CD and deployment scripts. Owner-level access to transferred repositories and operational control are provided through the agreed exit and handover process.

Exit options and conditions

The solution is delivered as clean, human-readable code, scripts, and services aligned with modern engineering standards, enabling maintenance and further development by external teams if needed.

The customer owns customer-specific assets, including its application code, automation scripts and deployment assets. The ReApptor platform, Generic Components and third-party rights remain subject to the agreed terms and their applicable licences.

Exit follows the agreed terms, and all IPR and handover protections continue to apply. Termination assistance is available for up to three months after the end of cooperation. Basic handover is free, with optional paid transition services.

Yes.

Readable code

The full solution is delivered as a standard codebase (.NET/C# + React/TypeScript) in your customer repository (Git/Bitbucket). Business rules live in normal application code and configuration files, not in a proprietary scripting language.

Structured documentation (exit package)

The handover includes documentation, such as:

• Data model (entities, relationships, key enums/status flows)
• Workflow descriptions for agreed customer processes and order status flows
• Integration specs (the customer's ERP endpoints, sync directions, mapping)
• Environment/deployment runbooks (CI/CD, secrets, backups, monitoring)
• Release notes and backlog history (Jira)

Nothing is inherently locked to a proprietary runtime, because the delivered solution runs as an independent system. Practically, the “coupling” is limited to standard choices that any system has:

• Cloud primitives (relational DB + object storage + monitoring), which are replaceable (AWS ↔ Azure ↔ GCP) without changing the application architecture.
• Tooling choices (Jira/Bitbucket, monitoring stack) that can be swapped by reconfiguring pipelines and observability settings.
• Integration connectors (e.g., the customer's ERP sync) are normal code modules; they can be kept, modified, or replaced.

If you want an explicit statement in the agreed terms, we can define “platform-coupled components” as a list (and keep it intentionally minimal/empty unless you request otherwise).

It depends primarily on what “exit” means:

Exit to another vendor, keep the same solution (most common)

Another team takes over your repository, CI/CD, environments, and continues development.

Effort is mainly handover + onboarding, not redevelopment.

Move hosting from AWS to Azure/GCP (lift-and-shift)

Recreate infrastructure (IaC), migrate database, migrate files, update secrets/monitoring, and validate.

No need to rewrite the application.

Full rebuild on a different architecture/product (least common)

This is a true reimplementation, and the effort is driven by functional scope, not by “low-code lock-in”.

To make exit cost predictable, we can define a standard transition process: code + IaC handover, documentation pack, knowledge-transfer sessions, and a fixed transition window.

Transition effort may include:

• Handover work (documentation + knowledge transfer)
• Environment migration (if you change cloud/tooling)
• Validation/testing

Commercial exit cost can be made explicit and bounded:

• The customer owns the project deliverables (code, scripts, deployment assets) per the IPR terms.
• If you want continuity protection, we can include an optional transition clause (e.g., a defined support period at standard rates; optional escrow; no hidden “unlock” fees).

There is no separate minimum exit fee.

Optional transition support: 20–40 hours, or a fixed 60-hour full-support migration package, charged at the hourly rates of our price list. The customer may select either option or neither. Basic access and handover activities are free.

Actual effort depends on the incoming vendor's capability and preparedness.

We can also define the “exit package” explicitly (documentation set, deployment handover, environment export, and knowledge transfer sessions) so that the exit cost remains predictable and not open-ended.

Yes. At the customer’s request, a separate source code escrow arrangement can be established with a mutually agreed neutral escrow agent.

The escrow materials can be released if ReApptor becomes bankrupt or insolvent, permanently ceases business operations, enters liquidation, or materially breaches the agreed terms and fails to cure the breach within the agreed period.

The released materials may be used by the customer to operate, maintain and further develop its own solution. No ownership of ReApptor IPR or Generic Components transfers under the escrow arrangement.

Escrow agent and administration costs are not included in the recurring licence or maintenance fees and are normally borne by the customer.

The customer will still have full technical control to operate and evolve the solution, because:

Source code access and ownership

The customer owns customer-specific assets and has read-only repository access from day one. Owner-level repository access and operational control transfer through the agreed exit and handover process. The ReApptor platform, Generic Components and third-party rights retain their applicable ownership and licence terms.

No “black-box dependency”

The delivered solution is a standard codebase and deployment setup that can be maintained by another qualified team if needed.

Operational continuity option (additional safeguard)

ReApptor Oy has a partnership arrangement with WeAre Solutions, which has the capability and team capacity to support the ReApptor platform-based solutions if continuity support is required.

Continuity safeguards (can be agreed explicitly)

We are open to formalising continuity protections in the agreed terms, such as:

• Source code escrow with a neutral third party
• Expanded access and handover rights for the customer (exit package, documentation deliverables)
• Continuity clauses defining procedures and rights in the event of acquisition, business model change, or closure

Insurance and trust framework

• ReApptor has liability insurance covering up to €1,000,000.
• ReApptor is a member of the Reliable Partner programme (Vastuu Group), with verified compliance, insurance, and required legal/operational prerequisites for trustworthy delivery.

If ReApptor were to cease operations, the goal is that the customer retains:

• The full solution code
• The data and database schema
• The documentation

The customer also has the right and ability to:

• Run the solution
• Maintain it with internal staff or a third party
• Gradually move to another platform, if desired

Business logic and customer-specific solution code

Owned by the customer under the agreed IPR terms for project deliverables.

Configurations and workflow definitions created for the customer's solution

Owned by the customer under the agreed terms.

Business data

Owned by the customer. ReApptor processes it to deliver the service.

Access to source code, ownership of customer-specific deliverables and rights to use ReApptor IPR or Generic Components are specified separately in the agreed terms.

You can inspect the customer-specific source code from the start of the project: read-only repository access is available from day one, for transparency and auditability.

After exit and the agreed handover, you receive owner-level access to the transferred customer-specific repositories. Two named customer accounts for the project board and the repository are included.

Shared ownership is used only when it is expressly agreed for a specific module; it is never a default for your whole solution.

For such a module, ownership, decision-making, operating responsibilities and costs are agreed separately, and major changes to it are decided together.