Desktop application starters · project planning pack

Desktop application starters · project planning pack

Choose a foundation for Desktop application starters with a platform brief, repository comparison, proposed tasks, acceptance criteria and the relevant Orqestria specialists.

This planning pack creates a project containing documents and assigns the recommended agents with their existing skills. It contains no external application code or installer and does not start an application. The task lists are proposals in files; no board tasks are created automatically.

Plan a desktop application around the operating systems, native capabilities and packaging model it actually needs. Compare Electron, Tauri, Wails and Avalonia approaches before choosing a frontend, native bridge and update strategy.

First business scenario

A person opens the installed app, chooses a local file through a native dialog, makes and saves a change, then restarts and recovers the expected state. A denied or revoked file permission produces a clear, recoverable result.

Records to model

Workspaces or documents, local settings, user-granted file locations, pending operations, recovery metadata and the installed schema/application version. Define which process owns each record and how local data is backed up.

Recommended team

Orion, Dex, Otto, and Yara

Documents in this pack

Read the brief, adapt the proposed tasks to your business and agree on acceptance criteria before implementation. Add the selected tasks to your board when you are ready to begin.

• Project brief: planning/en/brief.md
• Proposed initial tasks: planning/en/proposed-tasks.md
• Acceptance criteria: planning/en/acceptance.md
• Choose and validate the application foundation: planning/en/starter-selection.md

Repositories to compare

Explore the category recommendations

• Electron React Boilerplate · Recommendation and scope
• Electron Vite Vue · Recommendation and scope
• Create Tauri App · Recommendation and scope
• Wails · Recommendation and scope
• Avalonia Templates · Recommendation and scope

Repository shortlist checked: Oct 25, 2026. Recheck current official sources before selecting a revision; inclusion is not a security audit or a guarantee of suitability.

Proposed initial tasks

These are suggested tasks to discuss and add to your board. Installation writes these documents into the project; it does not create work items, run external setup commands or contact the linked services.

Define scope and outcomes

Identify the users, the business outcome and what the first version excludes. Use this scenario as the initial acceptance journey: A person opens the installed app, chooses a local file through a native dialog, makes and saves a change, then restarts and recovers the expected state. A denied or revoked file permission produces a clear, recoverable result.

Compare at least two foundations

Compare at least two linked repositories against the scenario and records. Separate shipped features from paid editions, add-ons and work you must build. Record a reasoned choice or why a custom build is preferable.

Verify the current upstream and dependencies

Review official source, licenses, edition terms, dependency requirements, maintenance activity and security advisories for the exact revision. Record unresolved findings and necessary changes before adopting it.

Model data and permissions

Define ownership, validation, relationships and allowed access for these records: Workspaces or documents, local settings, user-granted file locations, pending operations, recovery metadata and the installed schema/application version. Define which process owns each record and how local data is backed up. Include at least two roles and explicit denied-access cases.

Prototype the smallest complete scenario

Use representative sample data in an isolated test environment. Demonstrate the full scenario, including one invalid input and one failure or correction, before expanding the product.

Plan restoration and upgrades

Test a backup and restore of the prototype, define an upgrade and rollback approach and estimate hosting, migration, integration and maintenance effort. Record owners for operation and acceptance.

Acceptance criteria

These criteria define the first prototype's review, not completed work. Attach evidence and unresolved issues when the team evaluates each item.

• The agreed scenario is demonstrated end to end with representative records: A person opens the installed app, chooses a local file through a native dialog, makes and saves a change, then restarts and recovers the expected state. A denied or revoked file permission produces a clear, recoverable result.
• At least two candidates have been compared, and the chosen revision, license and edition constraints, dependency fit and security findings are recorded with official source links.
• At least two roles have verified allowed and denied actions, with no access to another user's or organization's restricted records.
• Invalid input, a failure and a correction are handled with visible results and without unintended duplicate records or business actions.
• A backup has been restored in a test environment and the expected records and access rules have been verified.
• The team has documented an upgrade and rollback plan, known gaps, operating responsibilities and the remaining implementation work.
• A packaged build demonstrates the first file workflow on each promised operating system; native permissions and communication boundaries, required toolchains, signing, updates and data migration are documented and tested where in scope.

Choose and validate the application foundation

Compare Electron React Boilerplate and Electron Vite Vue when Chromium/Node and the existing web stack are suitable. Evaluate Tauri for a web frontend with a Rust-based native boundary, Wails for a Go-backed web UI and Avalonia for a .NET-native UI direction. The recommended desktop and release agents coordinate the choice; involve the required Rust, Go or .NET expertise rather than assuming one stack fits every project.

Create Tauri App, Wails and Avalonia Templates are generator, framework or template tooling repositories. Record the toolchain version, chosen template, supported target OS and actual generated app root. Cloning these repositories alone does not create or build the distributable application.

Validate least-privilege IPC/native commands, navigation and external links, file dialogs, local persistence and error recovery. Test the packaged build separately from development on every promised operating system. Plan installer format, signing/notarization, update authenticity, rollback and data migration; avoid promising one-click distribution without that evidence.