Home / Product / Data models

Shape your data

Shape the application once. Let the backend follow.

Describe the people, products, orders, projects, or content your application needs. Daptin turns that shared model into a backend your whole product can build on.

See what it changes Technical guide ↗

Data models in a product

Name the things your product knowsCustomers, projects, orders, content

Connect them the way the business worksA customer owns orders; a project has members

Use the model everywhereScreens, permissions, files, actions, and reports

One model becomes the shared backend context

01Start from your product languageDefine customers, projects, orders, content, and their relationships as one relational model.

02Keep relationships visibleConnected records stay understandable as the product grows.

03Change one source of truthApply deliberate field and relationship changes to the shared model, APIs, administration, and permissions.

Why it matters

Define each customer, project, order, and content concept once in the shared relational model.

A customer may appear in an API, an admin screen, a file bucket, a permission rule, and an automation. When each surface defines that customer separately, small changes become coordination projects.

Daptin starts with one description of the records your product cares about and how they relate. That model becomes the common context for data access, administration, files, actions, live updates, and connected services.

Generate APIs, administration, permissions, files, actions, and events from the relational model. It is a backend where new capabilities already understand the same customers, projects, ownership, and relationships.

Move from idea to usable structure

Create the relational model and let Daptin generate migrations, resource APIs, and administration views.

Keep product rules close to the data

Validation, relationships, defaults, and access begin with the model, so important rules are less likely to scatter.

Extend the model with explicit fields and relationships that remain visible in APIs and administration.

Stable public record identities and explicit relationships make the system easier to understand as clients and workflows multiply.

Start with familiar business language

Describe what the product keeps and how each item connects.

Name customers, products, orders, cases, and articles in the language your team already uses, then add their details, quality rules, ownership, and connections.

Diagram showing a choice of business information connected to its name, useful details, quality rules, connections, ownership, display order, and optional customer features. — **Describe the information your product keeps**Add useful details, quality rules, sharing, display order, customer languages, change history, progress stages, and allowance tracking where they belong.Open diagram for full-size view

Diagram showing categories, products, variants, customers, orders, and order lines connected through familiar business relationships. — **Connect categories, products, customers, and orders**Express direct, optional, collection, and flexible connections through an ordinary product catalog.Open diagram for full-size view

How it fits

Part of one connected backend.

Data models does more when it can reuse the records, people, access rules, and workflows already in your application.

Step 1Describe

Define records, fields, validation, and relationships in YAML or JSON.

Step 2Create

Daptin prepares the relational structure and gives records stable public identities.

Step 3Use

APIs and administration work from the same running model.

Step 4Extend

Attach permissions, files, actions, events, and services to the existing relational model.

What it enables

Use it in products people recognize.

Start from the experience you want to create; the backend capability supports the work behind it.

Customer portal

Customers, teams, subscriptions, requests, and documents share one model.

Operations system

Jobs, locations, equipment, checklists, and owners stay connected.

Content product

Authors, collections, articles, media, and publication state become one graph.

Connected by design

Generate APIs, administration, permissions, files, actions, events, and services from the shared model.

These capabilities share the same application context, so each one makes data models more useful.

Know the boundary

What Daptin leaves in your hands.

Use Daptin to run the model while your product team defines its domain terms, relationships, and constraints. Good names, relationships, validation, and migration choices still require deliberate product design.

Understand the operating responsibility →

Build from one foundation

Define a resource once; APIs, administration, permissions, files, actions, and events follow its model.

Run Daptin locally, explore the live administration surface, and follow one complete application path.

Get Daptin Explore all capabilities