Platform · Data
An entire application, from one visual data model.
Define your entities and how they relate. Plant an App generates the database, the screens, the APIs, and the permissions, ready to use and ready to customize.
Define
Generated from one definition. Customized piece by piece.
Describe a record: its fields, their types, how it relates to others. Plant an App generates a working application around it. Then each part is yours to shape on its own: the form's layout and logic, the listing's columns and filters, the pages, the dashboard, the API.
EntityProgram
- NameTextrequired
- BudgetMoney
- Starts OnDate
EntityRequest
- ReferenceTextrequired
- Program→ Program
- AmountMoney
- Submitted OnDate & time
- Contact EmailEmail
- StatusTextfilterable
- Reviewers→ List of Reviewer
EntityReviewer
- NameTextrequired
- EmailEmail
- DepartmentText
Generated for every entity, then each one customizable
Database
- Table with keys and indexes
Screens
- List page
- Detail page
- Form
- Grid
- Dashboard
Logic & integration
- Create, view, edit, and delete buttons
- Entity actions for workflows
- Reusable data source
- REST endpoints
Own
A real database, not a black box.
Every entity is a standard SQL Server table. Your DBAs can read it, your reporting tools can query it, and none of it needs Plant an App to make sense.
CREATE TABLE app.Request (
Id int IDENTITY PRIMARY KEY,
Reference nvarchar(450) NOT NULL,
Program int REFERENCES app.Program (Id),
Amount decimal(19,4),
SubmittedOn datetime2(7),
ContactEmail nvarchar(320),
Status nvarchar(450),
-- CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate
);
CREATE INDEX … ON app.Request (Program);
CREATE INDEX … ON app.Request (Status);Money is a decimal. A date is a date.
Every field type maps to its proper SQL column type.
Relations are real.
References become foreign keys. Lists become join tables.
Deletes leave no orphans.
Dependent records follow the relation: removed if the reference is required, cleared if it's optional.
Every row remembers.
Who created each record, who changed it last, and when.
Your data. Your database.Readable with or without us.
Connect
Work with data where it lives.
Not every application needs another copy of your data. Plant an App uses it where it lives, and moves it only when the work requires it.
Your databases, in place.
Connect SQL Server directly, and other engines through ODBC, then use them from any screen, workflow, or API.
Services and files, too.
Use JSON services as data sources, and import records from CSV, Excel, or JSON when data needs to move.
Changes become events.
Database triggers start a process the moment a record is inserted, updated, or deleted.
Evolve
The model changes. The database keeps up.
Important systems never stop changing. Change the definition, and Plant an App updates the schema to match. No hand-written migration scripts.
- Add a required field
- The column is created, and existing records receive its default value.
- Rename a field
- The column is renamed, and its indexes follow.
- Mark a field filterable or sortable
- An index is created to support it, and maintained from then on.
- Relate two entities
- The foreign key or join table is created.
Protect
Security follows the data, not every screen.
Decide once what each role can do with each record. Every page built on that entity follows, so there's no screen where the rules were forgotten.
Set once, followed everywhere.
Permissions defined on the entity apply to every page generated from it. No second configuration to keep in sync.
Everyone sees their own.
A role can view or edit just the records its users created. It’s the rule most portals need, built in.
Down to a single cell.
Role-based conditions can show, hide, or lock one field, column, row, or cell.
Search knows the rules.
Search results respect the same roles.
| Role | View | Add | Edit | Delete |
|---|---|---|---|---|
| Applicant | Own | Yes | Own | None |
| Reviewer | All | No | All | None |
| Program manager | All | Yes | All | All |
Files follow the record, too.
Documents and images attach to the record they belong to, each record with its own folder. Storage is chosen per folder: public, secured behind the application, in the database, or synced with cloud object storage. Each folder has permissions for browsing, uploading, and deleting.
Query
Use the model. Drop to SQL when you need it.
The model handles the everyday work. When someone needs to ask the data something new, nothing stands between them and the tables.
Total requested per program this year, largest first
SELECT p.Name, SUM(r.Amount) AS Requested
FROM app.Request r
JOIN app.Program p ON p.Id = r.Program
WHERE YEAR(r.SubmittedOn) = YEAR(GETDATE())
GROUP BY p.Name
ORDER BY Requested DESC;The model does the daily work.
Each entity comes with a reusable data source that forms, listings, workflows, and APIs all share.
SQL is always there.
A built-in console with a schema explorer, saved queries, and export to Excel, CSV, or JSON. It’s off by default, and open only to the roles you choose.
Or just ask.
Describe the question in plain language. The AI assistant reads your actual tables and columns, then writes the SQL.
Scale
Built for production, not just prototypes.
In one production system, every reported financial transaction is a unit of work: its data stored, business rules applied, alerts raised, and a case opened for review when one is needed.
- 10M+
- reported financial transactions a month, in a single production system
- 30,000+
- users on that same system
Nothing half-written.
Every database script runs in a transaction. If one statement fails, the whole script rolls back.
No platform-imposed user cap.
Signed in or anonymous, users aren't limited by the platform. Capacity is a matter of infrastructure.
Add servers as you grow.
Runs active-active across several application servers behind a load balancer.
Related capabilities
Model the business once.Build the application around it.
Define the records, relationships, and access rules. Plant an App builds the foundation, and keeps every layer open to customize as requirements evolve.