Delivery & continuous development

ReApptor is funded through:

• Recurring customer revenues
• Project work for several long-term clients
• Selected public / R&D programmes

We are not dependent on a single investor or a single project.

Based on current customer commitments and pipeline, we have a multi-year operational horizon. We can share more precise figures under NDA if needed, but the core message is:

• We grow organically
• We reinvest profits into the platform
• We avoid taking commitments that we cannot support

We address key-person risk by:

• Having overlapping competencies in the team (no single-developer systems)
• Maintaining full documentation of architecture, deployments and operations
• Using standard technologies (so replacements can be hired on the market if needed)

For each major customer solution, we ensure that:

• At least two developers actively work on the project
• At least one additional developer is familiar with the codebase and ready to provide backup support
• Knowledge is retained in repositories and documentation, not only “in heads”

Most importantly, our solutions follow the same platform architecture, engineering standards, code style, naming conventions, tooling, and DevOps practices across customers. This means that even if a developer has not previously worked on a specific customer project, they can reliably step in because the solution is consistent with all other ReApptor-based projects. In practice, this significantly reduces operational risk compared to one-off, bespoke implementations where the knowledge often lives primarily in individuals rather than in a repeatable engineering system.

Finally, the majority of the underlying modules and architectural patterns are already proven in multiple production deployments, which strengthens code quality, security, and reliability over time.

If key developers leave, or funding conditions change, our priority is to:

• Honour SLAs
• Keep systems stable and secure
• Agree with each key customer on a continuity plan

This can include:

• Increased documentation and knowledge transfer
• Onboarding of your own or third-party developers
• Step-down plans if you decide to internalise development

ReApptor is primarily a customer-driven business. Our roadmap is shaped first and foremost by real customer needs and production use cases, because our strategy is to grow through long-term customer relationships and deep integration into core business workflows.

That said, there are always two additional inputs:

Platform-driven (foundational)

A stable share of roadmap capacity is reserved for platform fundamentals that benefit every customer (security updates, performance improvements, reliability, DevOps, and reusable components). This protects your solution long-term and reduces operational risk.

Investor-/programme-driven (selective)

When we participate in public R&D programmes, those initiatives are chosen to strengthen the platform in areas that customers already need (e.g., applied AI, document handling, analytics). They do not override customer delivery commitments.

Each customer's requirements have a direct and visible impact on prioritisation. We formalise this through a joint backlog and regular steering-level prioritisation so that you have real influence rather than “vendor promises”.

In our view, one of the biggest long-term risks for any business system is not a particular technology becoming obsolete, but the system itself stopping its evolution.

A solution that is not continuously improved will inevitably become technically and operationally outdated over time, even if it was modern and well-designed when originally implemented.

For this reason, continuous evolution is built into our commercial and technical model.

Normal technical updates required to keep the existing solution operational and current — including framework, API, protocol, security and other underlying technology changes — are part of the ongoing maintenance and SLA.

In addition, the platform licence includes three minor features or improvements per month after the active development phase. These are not only maintenance tasks; their purpose is to ensure that the solution continues to improve even during periods when there is no separate budget for active development.

This creates a continuous development path instead of a situation where the system remains unchanged for several years and then requires a large replacement or modernisation project.

Another important difference from traditional SaaS products is that each ReApptor solution is developed around the business processes of a specific customer. A traditional SaaS product must balance the requirements of many different customers and therefore inevitably operates through compromises. In our model, improvements can be prioritised specifically around the processes, users and operational needs of the customer.

New technologies, including advances in AI, can therefore be introduced gradually where they create real business value, rather than requiring the customer to launch a new development project every time the underlying technology landscape changes.

The solution is continuously maintained and evolved as the underlying technology changes.

Normal technical updates required to keep the existing solution operational and current — including framework, API, protocol, security and other technology updates — are part of the ongoing maintenance and SLA.

In addition, the platform licence includes three minor features or improvements per month after the active development phase. This ensures that the solution continues to evolve even when there is no separate active development project.

We believe this continuous evolution is becoming especially important because AI is no longer only an automation tool. It is increasingly becoming a practical instrument for business management, decision support, process optimisation, customer interaction and business development.

The opportunities created by current AI technologies are already significantly greater than was generally expected only a few years ago, and in many areas they provide a fundamentally different level of efficiency compared with traditional software and traditional ways of organising business processes.

This creates a particularly important opportunity for smaller and medium-sized companies. Large organisations often have much more difficulty changing their systems, processes and internal operating models quickly. Smaller and more agile companies can adopt new technologies faster, integrate them directly into everyday operations and continuously adjust the way they work.

For this reason, we expect that in the coming years many established players will increasingly lose ground to smaller but more flexible companies that are able and willing to adapt quickly to new technological capabilities.

Our objective is therefore not only to keep the solution technically compatible with new technologies, but to continuously evaluate how new AI capabilities can be used to improve the way the business itself is managed and developed.

A system that stops evolving gradually becomes outdated. Our model is designed specifically to avoid that situation and to keep the solution moving forward together with both the technology and the customer’s business.

ReApptor is not a “sales-first” company. The majority of our revenue and growth comes from reliable delivery, continuous improvements, and long-term cooperation with existing customers. This means we do not prioritise short-term sales at the expense of current customer commitments.

In practical terms, we balance capacity through:

• A customer delivery lane (active projects, agreed milestones, SLA commitments)
• A platform lane (security, performance, reusable components), planned so it does not disrupt customer deliveries

To remain reliable during peaks, we also use a flexible resourcing model: we have arrangements with partner companies that can provide specialists when needed (Finland, Baltics, Poland, India). This increases delivery resilience and reduces the risk of “overpromising” during growth.

Customer influence is ensured through governance, not informal promises:

Joint backlog and prioritisation

We maintain a shared backlog where items are ordered by business priority together with you.

Regular steering checkpoints

Prioritisation is reviewed at agreed intervals (e.g., every 2 weeks), especially around go-live and scaling milestones.

Clear separation of layers

Customer-specific needs are delivered in your solution repository, while common improvements that benefit multiple customers are promoted into reusable components when applicable.

We treat your roadmap as strategically important and keep prioritisation transparent, documented, and decision-driven.

We actively avoid over-customisation and “one-off forks” by:

• Keeping the core data model and modules shared
• Implementing customer-specific logic via configurations, extensions, and isolated custom modules
• Documenting patterns that can be reused

For a customer, this means the solution is tailored to your process but does not become a completely isolated codebase that is hard to maintain.

Our delivery and support model is designed for scale: environments, CI/CD, monitoring, ticketing, and release workflows are standardised across customers. This allows us to support multiple solutions in parallel without creating “one-off” operational setups. When load increases, we can expand capacity via our partner network through existing partner arrangements.

We separate:

• Customer-specific functionality (implemented in the customer’s dedicated repository and backlog)
• Reusable components (promoted into shared modules only when a pattern is proven and broadly applicable)

This keeps each customer solution tailored where needed, while preventing a fragmented “snowflake” platform.

Key lessons (and how they are now built into the platform/process):

• Early ambiguity in data models creates later friction — we now enforce a stricter specification phase with concrete sample data and “thin-slice” prototypes early.
• Integrations fail at the edges (master data ownership, statuses, idempotency) — we standardised integration patterns: master data rules, audit logs, retries, reconciliation views, and explicit error queues.
• Operational excellence is not optional — we invested heavily in monitoring, CI/CD discipline, and controlled release/rollback to avoid “hero engineering” in production.

• Start early with real customer data (even small samples) and lock “ownership rules” (what is mastered in the customer's ERP vs in the app) before building breadth.
• Make acceptance criteria and performance expectations explicit from the start (lead times, file sizes, concurrency, reporting needs).
• Establish a migration and cutover plan as a first-class deliverable, not a late-stage activity.

Because it reduces the biggest long-term risks of custom software:

Lower delivery risk and faster time-to-value

The solution is built on a set of repeatedly proven, refined, “battle-tested” software modules (orders, tasks, inspections, mobile UI patterns, integrations, reporting). This avoids spending the first months debugging typical “from-scratch” foundation services, and allows the project to focus on the customer’s real workflows, data, and operational priorities from the start.

Capacity and scalability from day one (without redesign)

Initial capacity and headroom are sized against agreed usage assumptions and validated through load testing. Standard cloud-native patterns support later scaling, with any change in infrastructure scope or fees subject to the agreed commercial terms.

We validate this via load testing during onboarding and scale the AWS resources accordingly.

Operational maturity is already embedded

Monitoring, logging, CI/CD, controlled releases/rollbacks, and support tooling are already integrated and proven across existing customer environments. These mechanisms have gone through real production hardening and multiple improvement cycles (including security audit cycles), whereas a greenfield custom build typically has to mature these capabilities over years of real-life operation.

Net effect

The customer gets a system that can go live faster, operate reliably, and evolve predictably as the business scales—without the typical long tail of hidden operational costs that appear in many traditional one-off builds.

Commercial alignment and delivery incentives

Our business model is explicitly tied to successful adoption and long-term value for the customer. We are confident in the quality of our platform and our ability to drive measurable operational efficiency with the customer; therefore, we can offer:

• A subscription-based development model
• Instalment payments for fixed-scope modules
• Ongoing feature development under the licence (e.g., a defined number of minor improvements per month after active development)

Many vendors cannot credibly offer this structure because their delivery model is typically based on a fixed scope or hourly billing, where the primary incentive is to deliver the project itself — not to ensure the solution continues to improve and generate business value after go-live.

The customer makes the go-live decision. Before release, the core scope, deliverables, acceptance criteria, operational requirements and milestones are agreed, so both teams know what must be ready.

The payment schedule is agreed separately and in advance.