Turn a product objective into a testable vertical slice, explicit team capacity, dependency decisions and a release plan with operating and recovery responsibilities.
Write the user, task and observable result the project should deliver. Trace one complete journey from interface through authorization and stored data to the user’s confirmation. List acceptance criteria and deliberate exclusions. Record the unresolved product or technical question that most threatens the slice, then choose a small experiment to answer it.
Document client, server, storage and external-service responsibilities. Define authentication, authorization, validation and the important data lifecycle. Record API contracts, failure behavior and which components need a server runtime. Inspect actual provider limits and costs for the expected scope; a free tier is an input to review, not an architecture guarantee.
Break the slice into implementation, testing, data migration, documentation and operating tasks with owners. Enter remaining working hours and actual team capacity in the work calculator. Use team-throughput mode only for comparable measured iterations. Keep waiting periods, dependencies and additional work allowances visible; the result is equivalent capacity, not a promised calendar date.
List setup and ongoing costs with billing periods and usage assumptions. If the product has a defined paid unit, compare fixed period costs, net unit price and variable cost in Break-Even. Keep acquisition cost, cash timing and uncertain demand in the separate plan. For a non-revenue project, use the stated budget and outcome criteria instead of inventing a sales unit.
Create milestones that end in a usable artifact: a working vertical slice, a tested migration, a recoverable release or another explicit outcome. Include automated checks appropriate to the code and manual checks for the real user journey. Assign owners for environment configuration, monitoring, support and rollback. Test risky integration assumptions before scheduling dependent work.
Review the actual slice with intended users or stakeholders and compare it with the acceptance criteria. Re-estimate remaining work from completed tasks and newly discovered constraints. Record decisions, dependencies and scope changes with owners. Download the plan and link it to the versioned implementation and test evidence so the next review starts from the same facts.
Draft and download the scope, architecture decisions and milestone record.
Compare explicit remaining work with team availability or observed whole-team throughput.
Evaluate a defined paid-unit contribution model for one accounting period.
Loading your checklist…
Keep these task-specific records with the tested version and review date.
| Record | Include | Verify |
|---|---|---|
| Work | Task working hours and stated extra work | Compare with available team working hours |
| Throughput | Comparable completed scope per whole-team iteration | Do not multiply the team rate by headcount |
| Calendar | Dependencies, availability and waiting windows | Schedule separately from equivalent capacity |
Cloudflare publishes separate limits for Pages builds, static files and functions. Check the actual service model and current limits when planning a stack.
Keep these task-specific records with the tested version and review date.
| Record | Include | Verify |
|---|---|---|
| Outcome | User-visible behavior and acceptance criteria | Demonstrate the complete slice |
| Dependencies | Owner, evidence and unresolved assumption | Resolve before dependent commitment |
| Release | Version, operating checks and recovery action | Verify the supported runtime and data path |
Testing, migration and recovery work belong in the scoped work rather than a hidden percentage.
A throughput rate from a different team or type of work may not support this plan.