Capabilities / Plans
How a plan is drafted
Sands writes facts your brief states straight into the plan, then plans the work around them. The more real the brief, the sharper the plan.
Watching it write
The plan drawer opens as soon as you ask, with the outline of the plan in place. Sands fills it top to bottom, section by section, and a Sands marker shows where it is writing. What it is doing right now shows in the drawer's top bar. The chat reply finishes once the plan is complete.
You can read while it writes. Scroll away and the drawer stops following; Jump to Sands brings you back. If you stop the run before the plan is finished, the unfinished draft is removed.
What Sands takes from your brief
| You write | Sands does |
|---|---|
| A date range: "Oct 5 to Oct 16" | Uses it as the plan's dates, exactly, and plans only working days. |
| A duration: "done in 6 weeks" | Plans to that length and asks for the start date if it is missing. |
| The team: "Ana (senior engineer), June (QA, half time)" | Builds the Capacity table from each person, their role and share of time. |
| Time off: "Ben is out Oct 9" | Removes those days from that person's hours. |
| A deadline: "Legal must sign off by Oct 12" | Adds an approval ticket for it, owned by the approver and due on that day. |
| Exclusions: "no mobile app this phase" | Lists them under Out of scope. |
Stated facts are kept exactly
Names, dates and deadlines from your brief go into the plan as written. Sands does not re-derive them, so a date you gave never drifts.
How tickets are set
Owners
Owners only come from the team you named. Sands matches work to roles: design work to the designer, build work to engineers, testing to QA. Approval tickets go to the person who approves. Work is spread so nobody has more than their hours; if someone is overloaded, the plan says so.
Priority and estimates
Every ticket gets a priority, High, Medium or Low, and an estimate in hours. Work that cannot fit the team's time moves to Low priority as stretch work rather than being cut. Estimates are Sands' suggestions; change any of them.
Due dates and dependencies
Each ticket is dated from its owner's available hours and what it depends on, inside its workstream and never on a weekend. When work needs an approval, the first ticket after the approval depends on it. A deadline you stated becomes the due date of the ticket it names.
Getting better plans
- Give the window: start and end dates, or a duration and a start.
- Name the team with roles, and say who is part time or out.
- State the fixed points: sign-offs, launch dates, freezes.
- Say what is out of scope.
- Attach the client brief or statement of work instead of summarizing it.
Try asking
Plan a CRM migration for a 3-person team, hard deadline Nov 30. Data migration is the riskiest part. Attached is the client brief.