The anatomy of a business application

Five layers, one model

Strip any internal business application down and the same five layers appear: a data model, screens over that data, logic that acts on it, APIs that connect it, and the operational machinery — schedules, permissions, environments — that keeps it running.

In hand-built apps these layers are five separate codebases with five places to drift apart. On Floyant they are five views over one app definition.

Data

Everything starts here. The data definitions — fields, types, relationships — are the vocabulary the rest of the app speaks. On Floyant, storage is created from these definitions and declared upgrades carry compatible changes, reviewed before applying.

Screens

Screens are layout definitions connected to data and queries. Because a screen is a document rather than code, it can be generated, reviewed as a change, previewed, and edited visually — all against the same definition.

Logic as automations

Business logic runs as automations: connected steps that validate, write, call out, and notify. Automations are inspectable and resumable, which matters most exactly when logic gets complicated.

APIs and operations

Documented API endpoints expose the same queries and automations over HTTP, so an external consumer and a screen button can share one definition. Schedules, scoped credentials, and environments are declared alongside the app — operations travel with the definition instead of living in a runbook.

Why one model matters

The practical payoff is consistency. Rename a field and the screens, automations, and endpoints that reference it are all reachable from one app definition — reviewable in one change, published in one release.