QMX Solutions builds a Qt-based low-code platform used for real production systems: internal business software, multi-tenant SaaS, mobile apps, WebAssembly clients, and industrial interfaces. It shortens delivery time without giving up C++ control over workflows, data models, integrations, or deployment.
QMX is a delivery platform for teams building operational software, not a template marketplace.
The platform combines low-code development with a full C++ codebase. It is used to build ERP and line-of-business systems, multi-tenant SaaS products, mobile clients, WebAssembly applications, and industrial HMI software.
It exists because many business systems are too complex for no-code tools and too repetitive to justify starting from zero each time. QMX packages the repeatable parts, but leaves the architecture open where the real complexity lives.
Teams use it when they need faster delivery but still care about data modeling, performance, tenant boundaries, integrations, and long-term maintainability.
These are production cases that show how the platform is used in different operating models.
Admin panel and internal business system for Leosmak. The scope centers on product and catalog management plus structured back-office workflows that are close to ERP operations.
This kind of system stresses data consistency, permission boundaries, and change-heavy business logic. It is a good proof point for a platform that needs fast delivery without reducing the application to a fixed admin template.
Loyalty platform for MyBon built as a multi-tenant SaaS product. The system supports loyalty programs, customer engagement flows, and a backend shared across multiple tenants.
The technical value is in the tenancy model, not just the interface. Tenant isolation, shared platform services, and scalable backend behavior are part of the core architecture instead of being added later.
A single system for AB delivered to both mobile and web clients. The same product logic and application structure are reused across platforms instead of being maintained twice.
This matters when teams want one release process, one domain model, and consistent behavior across devices. Qt client delivery and WebAssembly support make that reuse practical rather than theoretical.
The architecture is designed for systems that need scale, tenant isolation, and multiple client targets.
The backend is stateless and exposed through HTTPS APIs. Application state stays in the database and the clients, which simplifies load balancing, recovery, and horizontal scaling.
PostgreSQL is used with a multi-tenant approach that keeps tenant boundaries explicit. The shared platform layer stays reusable while tenant-specific data and configuration remain manageable.
Client-side applications run on desktop, mobile, and web. Qt and QML provide the UI layer, and the same HTTPS APIs serve all client targets, including WebAssembly builds in the browser.
The point is not to remove engineering. The point is to stop rebuilding the same foundation on every project.
Teams start each product by choosing or assembling the stack again. UI patterns, data access, admin tooling, tenancy concerns, and deployment plumbing are rebuilt before the real business logic is stable.
Reuse happens late and unevenly. Speed drops as the codebase grows, and control often depends on framework choices made at the start of the project.
The repeatable parts are already structured: workflow scaffolding, tenant-aware backend patterns, cross-platform clients, and reusable UI foundations. Delivery starts closer to the business problem.
Control stays with the team because the system remains ordinary C++, Qt, QML, SQL, and HTTPS APIs. That means reuse without vendor lock-in.
The delivery model can match the operating model of the customer.
Systems can run in the cloud, in private infrastructure, or on-premise. The stateless backend makes environment changes an operational decision, not a redesign.
The resulting system belongs to the customer. There is no vendor-controlled runtime, no required hosting model, and no forced dependency on a closed platform.