Projects

Create your first project

How to turn a business idea into the first Kaidera project request without needing to write a technical specification.

Public draft for dev reviewLast verified 2026-05-22

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 →