Meta Platform

MetaPlatform

MetaPlatform Inspiration

Business applications are often expensive to build, difficult to customize, and tightly coupled to a specific database or vendor ecosystem. Even a simple internal system can require weeks of repetitive work: creating entities, forms, navigation, validation, permissions, storage, and reports.

MetaPlatform was inspired by platforms such as 1C, but the goal was not to copy an existing product. The goal was to rethink the same idea as a modern, independent, metadata-driven platform.

Instead of writing every screen and workflow manually, a developer describes the application structure once, and MetaPlatform generates the necessary runtime components.

MetaPlatform — from an idea to a business application in hours.

What MetaPlatform does

MetaPlatform is a low-code platform for creating desktop business applications.

It consists of two main parts:

Configurator — used to define metadata, entities, fields, forms, commands, roles, reports, and business logic. Client application — uses that metadata to render the final application for end users.

The platform currently supports and is being designed around familiar business entities such as:

catalogs and directories; documents; constants; enumerations; reports and data processors; information and accumulation registers; roles and permissions; forms, commands, layouts, and shared resources.

The long-term goal is to allow developers to build complete business systems without being tied to SQL schemas, manually designed windows, or repetitive CRUD code.

How we built it

MetaPlatform is written primarily in Python and uses Qt for its desktop interface.

The architecture is divided into several layers:

domain models for metadata and application entities; application services for creating, editing, validating, and deleting objects; ViewModels and controllers for UI coordination; Qt widgets for the Configurator and runtime client; a custom file-based database format called mpdb.

Metadata objects are stored as structured records with unique identifiers and payloads. The configuration tree is generated dynamically from this metadata.

For example, when a developer creates a catalog, MetaPlatform automatically prepares its system sections:

Catalog ├── Attributes ├── Forms ├── Commands ├── Layouts └── Rights

Forms are also metadata-driven. The form editor stores a JSON-compatible model describing controls, layout, bindings, and properties.

A simplified form model may look like this:

{ "layout": "grid", "grid_columns": 2, "elements": [ { "type": "text_box", "name": "Code", "binding": "Object.Code" }, { "type": "text_box", "name": "Name", "binding": "Object.Name" } ] }

The client application reads this model and renders the corresponding user interface.

We also created a form wizard that can:

select the type of form; select object attributes; choose the number of columns; generate an initial layout; assign the form as the default form for the object. The custom database

One of the more ambitious parts of the project is mpdb, a custom file-based database designed specifically for metadata-driven applications.

Instead of generating SQL tables for every configuration object, MetaPlatform stores configuration and runtime data using its own storage abstraction.

This gives us more control over:

schema evolution; metadata versioning; portability; transaction logs; recovery mechanisms; compression; page checksums.

The storage engine is still evolving. Planned improvements include WAL-based recovery, page-level CRC validation, compression, and crash-resistance tests.

Challenges we faced Keeping metadata and UI synchronized

The same object can be represented in several places:

the configuration tree; the properties editor; the form designer; the client application; the storage layer.

A modification must be reflected everywhere without creating duplicate state or hidden dependencies.

We addressed this by separating domain logic from Qt widgets and moving object operations into application services and ViewModels.

Building a flexible form designer

A form editor must support more than placing controls on a canvas. It also needs:

nested containers; vertical, horizontal, and grid layouts; drag and drop; resizing; data binding; control properties; generated previews; serialization.

The main challenge was designing a form model that is simple enough to save as metadata but flexible enough to generate real interfaces.

Supporting safe deletion

Metadata objects have dependencies. Deleting a catalog may also affect its forms, commands, fields, and generated resources.

We implemented cascading deletion rules and ownership relationships so that dependent objects can be removed consistently.

Avoiding tight coupling to Qt

Qt is currently the primary desktop UI technology, but business metadata should not depend on a specific UI framework.

For this reason, form models, metadata factories, and application services are kept independent from Qt wherever possible.

Internationalization

MetaPlatform is intended to support multiple interface and scripting languages.

The current project includes Ukrainian and English localization, with Ukrainian used as the default metadata syntax in relevant environments. This required us to separate technical identifiers from user-facing titles and translations.

What we learned

The most important lesson was that a low-code platform is not primarily a visual editor. It is a system of contracts between metadata, storage, runtime behavior, and user interfaces.

We learned that:

metadata must remain stable even when the UI changes; generated interfaces still need to be editable; ownership and dependency rules must be explicit; localization should be part of the architecture from the beginning; a custom storage engine requires careful recovery and validation design; a clear separation between domain logic and UI significantly reduces complexity.

We also learned that recreating familiar enterprise concepts is only useful when they are simplified and adapted to modern development practices.

Current state

The current prototype includes:

a working configuration tree; metadata creation and editing; object-specific system folders; catalog editing; form creation wizard; initial form designer; form preview; shared icon and image management; localized interface; custom file storage; a modern client UI concept.

Some features are still under active development, including advanced runtime data operations, permissions, reporting, form scripting, and storage recovery.

What is next

The next major milestones are:

complete the runtime form renderer; connect catalog forms to real stored data; implement documents and registers; add role-based access control; introduce a scripting runtime; improve the form designer with nested layouts and advanced controls; strengthen mpdb with WAL recovery and integrity checks; support packaging and deployment of generated applications. Vision

MetaPlatform aims to make business application development more accessible without hiding the underlying architecture.

Developers should be able to define a system visually, extend it with code when necessary, and deploy it as an independent application.

The project is built around one principle:

Describe the business model once. Let the platform generate the routine parts.