The CloudWinks framework
CloudWinks is an application framework for business software. An application is described in data — its screens, its fields, its menus, its tables — and the framework builds the working product from that description. Every application it builds shares the same shell, the same identity layer and the same pipeline.
Definitions-driven · A shared .NET service API · PostgreSQL data layer · Flutter client on web and phone
What it is
Most software grows into a collection of separate products that each need their own login, their own interface and their own maintenance. CloudWinks was built the other way around: a single framework holds the shared parts, and each application contributes only the definitions that make it different.
The framework is the container. It registers the applications, holds their state, and serves their navigation. Applications are entries in that registry, which means one deployment can carry many products on one database server.
Every screen, field and menu is a row in the database, not a hand-coded page. The client asks the framework what to draw and renders it. Change the definition and the interface changes with it — for every user, everywhere.
Each application owns its schema inside a single PostgreSQL server, so data stays cleanly separated while operations, backups and reporting stay in one place. A shared identity base ties users and companies across every application.
Authentication is part of the framework, not an add-on. Sign-in goes through Firebase, with providers for Google, Facebook, LinkedIn and X configured at the framework level. Google is the one in daily use on the development environment today.
The platform applications carry the hard, unglamorous work: identity, files and media, notifications, reporting, messaging, integrations, workflow and scheduling. A new product starts from those definitions rather than from a blank page.
A Python build, import and seed pipeline materialises an application from its definitions: schema first, then screens, then data. Rebuilding a clean environment is a command, not a project.
How it works
An application is specified as numbered definition folders and an application_setup.json that declares its name, its category and the hostnames it answers on. The pipeline does the rest, in a fixed order.
Creates the schema, tables, functions, views and constraints for the application from its table definitions.
Registers the application, then imports its controls, fields and menus so the framework knows how to draw it.
Loads the starting data, including the rows that must be tied to the application's own identifier.
The shared client opens the application, in a browser and on a phone, behind the one sign-in the framework provides.
Three languages, each doing the job it is good at: Dart and Flutter for the client that runs in a browser and on Android, a shared .NET service API as the gateway to the data, and Python for the build pipeline. PostgreSQL is the single source of truth.
The expensive part of business software is rarely the first screen. It is the twentieth screen, the fifth customer's permission model, and the third year of maintenance. A framework that treats every screen as data changes that economics.
The platform layer
These are the shared services of the ecosystem — the parts every serious business product needs, modelled once so no application writes them twice.
The framework itself: the registry, the shell, the navigation and the shared interface components.
The identity and company base that every other application extends for its own users and organisations.
Authentication and access: credentials, sessions, roles and multi-factor sign-in, applied consistently wherever a person can reach.
Error logging, grouping and audit, with a client-side queue so an error survives a dropped connection. Built into the platform, not yet switched on in a running application.
Files, images and media, stored through the shared storage providers and served to any application.
Reporting and output, so applications produce documents and exports rather than reinventing them.
Messaging and conversation inside an application, using the same identity as everything else.
Background work and orchestration: jobs that run without a screen in front of them.
Maps and geospatial work: routes, pins, polygons and geofences, with location tracking for people who work away from a desk.
Connections to outside systems, with mappings verified as part of the build.
Shared business rules, kept in one place so applications behave consistently.
Development and deployment tooling that lives inside the platform rather than beside it.
See the full list of platform and industry application definitions →
Industry applications
Each one is modelled to the way that industry actually works, and each inherits the platform underneath it. Maturity varies widely between them, so read the catalogue as what the framework can describe, not as a shelf of finished products.
A table, a field, a screen and a menu are records in the database. Adding one does not mean writing or rebuilding a feature by hand.
Build, import and seed run in a fixed order from one orchestrator, so a clean environment can be produced again from the same definitions.
Applications extend a shared record of users and companies, which is why the same account works across everything the framework carries.
Where it stands
CloudWinks is a working development system, not a finished product. The framework, the database model, the build pipeline and the client shell are built and running in an active development environment, and application definitions exist that build and seed against it.
What that means in practice: if you want a product built on CloudWinks, you are getting a foundation that already exists, plus the work of turning the right definitions into the product you need. That is a very different conversation from starting at an empty repository — and a different one from buying finished software off a shelf.
We would rather tell you exactly where the edges are at the start than discover them together in month six.
We will tell you which parts of it CloudWinks already covers, which parts are a definition away, and which parts are genuinely new work.