Projects
Create your first project
How to turn a business idea into the first Kaidera project request without needing to write a technical specification.
Created from Phase 2 docs inventory and current customer journey planning.
What a project is
A project is a bounded piece of work with a goal, files, worker activity, review gates, memory, and evidence. It can be a new product, feature, website, internal tool, integration, automation, or documentation effort.
Start with the outcome
Describe the result you want in business language. You do not need to describe every technical step. Kaidera should help turn the goal into clearer requirements, work packets, and review points.
- Name the business goal.
- Describe the users or audience.
- Add examples, screenshots, diagrams, or existing notes if you have them.
- State what would make the first version review-ready.
Who should create it
The first project should normally be created by the person who understands the business outcome and can approve direction. That may be the product owner, founder, department lead, operations owner, or a delegated project owner.
Where the project starts
A customer starts from the project area in the customer portal or through guided onboarding. The project request should capture the goal, context, constraints, and first useful result before the AI worker team begins deeper planning.
Add useful material
Add only the material that helps the team understand the work. A short brief, existing screenshots, diagrams, business rules, forms, example reports, customer journeys, or notes can make the first plan much stronger.
- Use FileVault for files that should stay attached to the project.
- Use Draw when the idea is easier to explain visually.
- Use plain notes when the important part is workflow or business logic.
What happens next
The platform should help clarify the request, identify missing details, propose a path, create scoped work, and show what needs approval before the work progresses.
Review the first plan
Before work continues, check whether the plan matches the business goal, names the right users, includes the right constraints, and has a realistic first review point. If the plan is too broad, narrow it before the AI workers start producing work.
Avoid vague requests
A request such as "build my app" is usually too broad. A better first project explains the audience, the workflow, the first useful version, any security limits, and who will approve the result.
What can go wrong
Most first-project issues come from unclear goals, missing constraints, unknown approvers, or too much scope. Fix those early. It is better to start with a smaller first version than to ask the platform to guess the whole product.
Read next
After creating the first project, read the Workbench and FileVault guides. They explain where the work appears and where project material should live.
Website context
Connect this guide back to the product story
The technology docs map links this page to the public technology narrative and helps buyers move from a capability overview into the right operating guide.
Open technology docs map →