# Plan a launch without losing the brief.

Keep the story, the tasks, and the next decision in the same place.

By Integrity team · 2026-09-26

Canonical: https://integrity.sh/articles/ai-build-plan-from-notes/

A launch plan needs more than a list of things to finish. It needs a reason for those things to exist. Keep that reason beside the work, so the team can still find it when the board gets busy.

Here is a small, fictional project: Orbit studio is preparing an autumn launch. Maya owns the story, Sam owns the visuals, and Alex is putting the campaign together. They need a brief, a board, and a place to compare ideas. In Integrity, those can live in the same project.

## Start with the decision

Before making tasks, write a short brief. Who is this for? What should they understand? What do you want them to do next?

For Orbit, the audience is independent teams. The message is that good ideas deserve somewhere to become shared work. The next step is an invitation to try a project together.

That is enough to start. Keep three headings in the document: **Audience**, **The story**, and **Next decision**. Nest supporting notes under each heading. If a detail is unresolved, say so; a confident-sounding placeholder can turn into an accidental commitment.

> A good brief stays in the conversation.

## Give the work a shape

Create a database for launch tasks. Add a status, a work type, and an owner. Begin with only the tasks you can explain: write the campaign brief, collect references, design the hero artwork, build the campaign page.

A board makes movement visible. Ideas, Ready, In progress, and Done are useful starting groups. They are not a substitute for deciding what “done” means. Put the acceptance criteria inside the record: for a campaign page, that might include reviewed copy, mobile checks, and working signup links.

![Launch board: real UI with fictional project data](https://integrity.sh/assets/landing/launch-board-desktop-v1.6689260934.png)

The pictured board is a curated demo using Integrity’s real database components. A card carries its owner and work type; opening the record gives its longer description room to breathe.

Use another database view when the question changes. A board answers “where is the work?” A table is often better for reviewing properties across records. Switching the view should not require copying the project into a second database.

## Keep the brief beside the board

Open the document in a second pane while you work through the database. Open a record on the side when a task needs attention. The point is to keep the decision and its context visible together.

A canvas gives references a different job. Put the working document beside visual material and short notes, then use their position to show relationships. Keep detailed task tracking in the database rather than writing a second, competing checklist on a sticker.

When the campaign artwork changes, check it against the audience and story. When a task grows, update its record. The brief remains the place for the rationale.

## Ask AI for a specific contribution

Mention the brief and ask for something bounded:

> Read this brief and suggest five launch tasks. For each, explain what it produces. Flag missing decisions instead of inventing deadlines or owners.

Review the proposal before assigning it. Then ask the assistant to make the agreed changes in the relevant document or database. AI work uses the workspace’s credits; writing and arranging things yourself does not.

## Leave a useful handoff

End the review by recording what changed, who owns the next step, and what remains undecided. A teammate arriving tomorrow should be able to start from the project itself.

Try this on one small launch first. A brief, a board, and a real next decision are enough. Add structure when it answers a question you actually have.