Platform & technical control

Our approach is code-first, low-code, rather than “black-box” low-code.

In the platform, there are two types of code: base code (reusable components and services) and auto-generated project code. Importantly, any code (base or generated) is originally written by engineers. A developer first implements a component/module/service according to our internal code style and industry standards, and it is then reviewed and tested. After that, the component is manually converted into a template suitable for the generator and for inclusion in an application template.

During the initial rollout (typically ~20–40 minutes) of a customer solution, the template code is adapted (refactored) by the generator to match the customer project (e.g., naming, prefixes, namespaces, copyright headers, etc.). As part of this process, a copy of the component/template is produced and stored in a separate, dedicated repository created for that specific customer and project. This refactored copy follows the same code standards and code style, and it is available for manual development and modifications after deployment.

Auto-generated code is available for debugging and extension (e.g., via partial classes and inheritance) and remains readable and standards-compliant.

Examples of auto-generated code (majority):

• Frontend TypeScript models generated from C# backend data models and interfaces
• Frontend localization helpers (translation variables) required for multilingual UI
• Base helper/mapping classes for common UI representations (strings, list items, etc.)

Examples of base (reusable) code:

• AuthService — authentication and authorisation
• NotificationService — notifications (email, SMS, push, in-app)
• FileService — file and image storage/management
• SyncService — reusable integration mechanisms for connecting to ERPs (incl. synchronization patterns)

Clarifications (risk reduction)

No runtime “magic”

Code generation happens during setup/implementation; the result is a normal codebase, not hidden logic running inside a proprietary engine.

Maintainability

The generated and refactored code follows a consistent code style and architecture conventions.

Safe extension points

We extend using standard mechanisms (partial classes, inheritance, separate extension files) so updates/regeneration do not overwrite customer-specific logic.

In our model, custom development starts immediately after the initial project rollout.

Once the customer is registered in the ReApptor Portal, we perform an initial deployment (typically ~20–40 minutes). During this rollout, we create a fully functional, isolated customer environment and a customer-specific application codebase:

• The code is created as a refactored copy of the selected templates/modules
• All required CI/CD and deployment scripts are included
• Everything is stored in a separate, dedicated repository created for this specific customer and project

From that point forward, development work happens as in a standard software project: our engineers connect to the newly created customer repository and pull the refactored project code. All further changes are implemented inside the customer project codebase and are managed through normal software development practices (version control, code review, CI/CD, releases).

In other words, after the rollout, we are no longer “configuring a black-box platform” — we are developing and evolving your solution in its own repository and environment.

The platform is optimised for transactional business workflows, including orders, tasks, inspections, documents, employees, etc.

It is not intended to be:

• A real-time 3D CAD engine
• A full-blown MES/PLC control system
• A heavy data-science / big-data analytics platform on its own

We integrate with such systems where needed (e.g. CAD, BI tools, ERP), but we do not aim to replace them.

A specialised system is a better fit when the requirement becomes:

• Millisecond-level real-time control of machines
• Extremely complex, low-level CAD manipulation inside the browser

For everything around order management, planning, work orders, digital quality checks, document handling and mobile operations, the complexity is well within the envelope of what the platform handles efficiently.

In our model, there is no hard functional “platform ceiling” in the classic low-code sense, because after rollout, the solution runs as a normal, independent codebase (copied services/components + customer repository). We are not operating inside a “platform runtime box”, so there is no functional “ceiling” where the platform stops being able to support complexity.

Practically, the question becomes: at what point does the solution stop being mainly accelerated by reusable modules/templates and become mainly custom engineering effort, while remaining fully supported, scalable and maintainable?

That point is reached only when requirements move from “business system complexity” (which we design for) into specialised R&D-grade constraints, for example:

Optimisation engine scope

If production planning evolves into a full constraint-solver with continuous auto-replanning and multi-objective optimisation (not just scheduling/visibility).

Extreme non-functional constraints

Very high concurrency and throughput with hard real-time UI updates and sub-second response requirements at very large scale.

Heavy CAD/visual computing pipelines

If you require server-side rendering, conversion, and processing of large CAD assets as a core capability (beyond storing/versioning/approving drawings).

Even in those cases, the answer is still “we can implement it” — but we treat it as a separate, explicitly scoped engineering package with clear acceptance criteria and performance testing, so it does not silently consume budget or timeline.

Requirements around orders, work tasks, planning views, delivery, inspections, integrations, file handling and scalable growth fall squarely into the category the platform was built for.

Technically, the solution is a standard cloud-native web application stack deployed as a dedicated customer environment:

Backend

.NET (C#) with a relational database (MySQL / Aurora).

Frontend

React / TypeScript (web + mobile-friendly UI).

Files (forms, orders, drawings/CAD and other attachments)

Stored in object storage (AWS S3) using streaming and signed URLs (no “files through the database”).

Deployment

Containerised services with horizontal scaling, load balancing, and production monitoring.

AI

A combination of internal and external AI services is used for document, voice, video, image, audit, drawing and other intelligent processing and automation tasks.

From a capacity perspective, our commercial model includes predefined infrastructure tiers (Standard / Medium / Extra) with a predictable monthly cost per application, depending on the tier.

For a typical initial scope and indicative capacity assumptions (single country, fewer than 1,000 active users and fewer than 1,000,000 orders per year), we recommend the Standard tier. If volumes grow, you can upgrade the tier without changing the application architecture. The price is fixed for the agreed term.

Yes. All environments are continuously monitored (infrastructure + application metrics), including resource utilisation, response times, database load, and file/storage usage. We can share benchmark snapshots and trend reports from comparable production systems (under NDA).

Production examples (Standard tier)

Healthcare ordering

~30% average resource utilisation; 494,496 order lines; 582 active users; 9,338 unique products; 96,809 assortments; 84,215 files; 330 customer locations (hospitals).

Ticketing and booking

~10% average resource utilisation; 1,517 bookings; 4,737 passengers; 5,112 active users.

Port service and task management

~3% average resource utilisation; 3,358 services; 363 active users; 6,451 documents.

Elevator panel manufacturing

34,774 orders; 953 product groups; 9,659 product assortments.

Technical debt is managed as in any professional software product:

• Shared platform modules are versioned, tested and refactored continuously
• Customer-specific logic lives in separate repositories with code review, automated tests and CI/CD
• Every change is traceable to a ticket (Jira) and documented

Low-code in our case does not mean “no code and no control”; it means we reduce duplication and centralise common patterns, so that debt is easier to see and manage.

All custom code is:

• Standard C# / .NET and React / TypeScript
• Organised in clean, layered architecture
• Maintained in a normal Git (Bitbucket) repository
• Documented at the code and solution level

There is no proprietary scripting language that only ReApptor understands.

Because any generated code is produced from templates that were originally written by engineers, it follows the same internal code style and engineering standards as hand-written code.

Platform functional or security updates are applied to a customer solution only through a controlled, manually approved release process: documented in Jira, reviewed/approved, tested in test and staging environments, regression testing and then released to production via a new deployment.

We follow a versioned, backwards-compatible release approach:

• Platform libraries are published as versioned packages (NuGet / npm).
• Breaking changes are avoided and, if ever needed, are introduced only in major versions.
• Customer solutions pin specific platform versions and are upgraded in a controlled manner.
• New functionality is typically opt-in via configuration and/or feature flags.

This allows us to continuously improve the platform while keeping customer-specific logic stable and predictable.

The platform is already in production for:

• Order- and task-driven operations
• Service and maintenance workflows
• Security reporting workflows
• Mobile field workers (e.g. logistics, construction, healthcare)

These solutions run with SLAs, monitoring and continuous updates.

Our largest use cases today include multi-year operational systems with:

• Thousands of end users over time
• Hundreds of thousands of orders and tasks
• Integrations to ERP and other core systems

One of our largest customer solutions is in healthcare and has been in production for multiple years. Production metrics with their dates can be reviewed under NDA.

We can share concrete customer references and anonymised metrics under NDA to give a more precise picture.

Technical scalability is achieved through:

• Horizontally scalable application nodes
• Separate databases per customer and application
• Separate cloud object storage per customer and application for files
• Background workers for long-running jobs

The architecture is designed so that if the customer’s volume grows (more orders, more workers, more customers), we can scale out infrastructure without redesigning the application.

The commercial scalability model is:

• A fixed monthly platform and infrastructure fee
• Transparent development options (fixed scope or subscription)
• Three minor improvements per month included in the licence after active development

As your usage grows, we do not introduce per-user or per-order penalties. If infrastructure costs materially increase (e.g. due to much higher volumes), this is handled via clear thresholds and discussions, not unilateral changes.

We ensure backward compatibility by:

• Versioning APIs and data structures
• Introducing new features as optional extensions
• Maintaining migration scripts for schema changes

For a customer, this means that over the coming years, we can:

• Add new modules
• Evolve existing screens
• Improve performance

All of this without forcing disruptive redesigns or long freezes.

In addition, the monthly licence includes three minor improvements/features per month after the active development phase, to ensure continuous, predictable expansion of the solution's functionality and business value.

We can provide production references and walkthroughs (under NDA where needed) across three areas that can be matched to the customer's requirements:

• Order and workflow-driven operations (orders, tasks, role-based UIs, approvals, reporting).
• Scheduling/planning and operational execution (work orders, task assignment, capacity visibility).
• Inspections/quality/service workflows (step-by-step checklists with photos/comments, mobile-first execution).

Examples include healthcare supply workflows, consumer order configurators and pricing calculators for moving services, and operational task and service management for port services — running in production on the same platform foundations.