Imagine a small team tracking its work. Its workspace groups projects, its Task tracker project holds the tasks and rules, and its frontend is the interface people use to view and update them.
Start with one workspace, one project, and the default frontend. You do not need to design a large hierarchy before building something useful.
A workspace gives related projects a shared place in the builder. For example, “Acme team” might contain a task tracker and a separate equipment directory.
Those projects remain separate. Putting them in the same workspace does not combine their records, accounts, or permissions. Current workspaces are owner-only; a workspace is not yet a collaborative team account or an invitation system.
Your personal Appify sign-in remains your own account, independent of workspace names.
The task tracker project defines its data, features, workflows, and access rules. A task's title and completion state belong to that project, rather than to the screen displaying them.
This distinction helps when an application grows: several interfaces can be designed around the same business purpose without treating every interface as a separate application backend.
A frontend identifies the intended screens and entry point for a particular interface. The task tracker starts with a default frontend. Later, a project might need distinct member and staff interfaces.
Current limit: frontend configuration is an early foundation. Selecting a frontend does not make design edits, data, or publishing independent. Current publishing still releases the existing project application. Independently published frontends, separate frontend domains, and shared sign-in across them are future work.
A frontend is also not a permission grant. Calling an interface “Staff” cannot give its visitors access to private tasks.