The traditional pull request arrives finished: code done, tests written, author braced for judgment. By that point the expensive decisions are locked in, and “have you considered a different approach?” means redoing two days of work. A draft PR flips the order - feedback lands while changing course is still cheap.
What a draft is for#
Open the PR as a draft the moment the shape of the change exists: the migration, a sketched controller, maybe a failing test that names the behavior. The draft status says plainly: do not review the details yet, do look at the direction.
That early look catches the reviews that matter most:
- “This duplicates what the billing package already does” - before you polish your version.
- “The column should live on the invoices table, not the users table” - before the migration ships.
- “We tried this approach in March, here is why it hurt” - before you rediscover March.
The working agreement#
Drafts only work if the team reads them in the right spirit. Two conventions keep it healthy:
- The author says what they want. “Does this structure make sense?” gets a useful answer; silence about intent gets either no review or a full one you did not want yet. The PR description matters more, not less, in a draft.
- Nobody treats a draft as a promise. Scope can shrink, approach can change, the branch can be rebased - drafts are force-push-with-lease territory by default.
Marking the PR ready for review is then a real signal: the direction is settled, now judge the details.
The quiet side benefit#
Drafts double as a status board. A team that opens drafts early can see what is in flight without asking - which prevents the awkward moment where two people discover at merge time that they both spent the week on the same invoice controller. It also feeds the habit that keeps everything else moving: work arrives in small, reviewable pieces, because a draft that has been open for three weeks is visibly not that.
Open it early, say what you want, mark it ready when it is. The PR stops being a verdict and becomes a conversation - which was the point of having a team.
Share this post
Keep reading
A First CI Pipeline for a Laravel Project
Install, lint, test, build - four jobs that run on every pull request and turn 'works on my machine' into a check everyone can see.
A Staging Environment Worth Having
Staging only catches what it shares with production. Same deploy path, same services, sanitized data - and a clear rule for what it is for.
Branch Naming Conventions That Scale Past Three People
Branch names are a user interface for your team's work. The conventions that survive growth, the ones that collapse, and why boring always wins.
