What to Do When Your Studio Asks for More Time

A studio asking for more time is giving you information, and the request itself is usually a good sign. A studio that stays silent and delivers late is a bigger problem than one that tells you early. The right response depends on why they need it, how much they need, and whether this is the first time or a pattern.

Why the request is often a good sign

A studio that asks for an extension is telling you three things.

1. They are tracking the schedule closely enough to see the problem.
2. They trust the relationship enough to raise it honestly.
3. They would rather have an uncomfortable conversation now than a worse one later.

Compare this to the alternative: silence until the deadline passes, followed by an excuse. The request is the professional version, and responding well to it encourages the behaviour you actually want.

That said, not every request deserves automatic approval. The right response is informed, not reflexive.

A studio that asks early is managing the project. A studio that tells you after the deadline is managing your expectations.

The three questions to ask

Before deciding, ask three things.

What specifically is taking longer than planned? A clear answer means they understand the problem. A vague answer means they might not.

What does the extra time buy? More time should produce a specific, nameable improvement. "More polish" is vague. "The tutorial flow is not testing well and we need to rebuild the first three screens" is specific.

What is the revised date, and what is your confidence in it? A studio that asks for two more weeks and commits to the new date is making a concrete plan. A studio that asks for "a bit more time" is not.

The answers to these three questions tell you whether the request is a controlled adjustment or a sign of something unstructured.

When to grant it

Four situations where extra time is the right call.

• The scope changed and the timeline did not. If you added features or requested changes after the original plan, extra time is a consequence of your decisions, not the studio's.
• The quality gap is specific and fixable. A build that is close but has a named problem that extra time will solve is the best case for an extension.
• External factors intervened. Platform changes, device updates, or approval delays that were not foreseeable and not caused by poor planning.
• The studio has a strong track record. A team that has hit every previous milestone and asks for two extra weeks on one has earned the benefit of the doubt.

In all four cases, the extension should come with a clear revised date and an agreement about what will be delivered on that date.

When to push back

Three situations where extra time may not be the right answer.

The request is vague. "We need more time" without a specific reason suggests the team does not understand why they are behind, which means more time may not fix it.

This is the third time. One extension is normal. Two is a concern. Three is a pattern, and the pattern points to a planning or estimation problem rather than a one-time difficulty.

The extra time comes from testing. If the schedule is being compressed by moving the ship date but keeping the content the same, the compression comes out of QA and polish. That trade produces the most expensive kind of bugs: the ones players find after launch.

Pushing back does not mean refusing. It means asking harder questions before deciding.

"What would you cut to hit the original date?" is a fair question. The answer tells you whether the team has thought about trade-offs or whether they are treating the deadline as the only variable.

The scope trade conversation

The most productive response to a time request is often a scope conversation.

Instead of more time with the same scope, offer the same time with reduced scope. This forces a prioritisation that benefits the project regardless of which option is chosen.

A useful framework.

The third option is underused and often the best. Splitting a milestone lets you see real progress before committing to the rest, and it converts a binary decision into a checkpoint.

Ask the studio which features they would defer. Their answer reveals their priorities and often surfaces a feature that neither side would miss.

Adjusting the plan, not just the date

If you grant the extension, update everything that depends on it.

• Downstream milestones. A two-week delay on milestone three shifts milestones four and five unless something else changes.
• Budget. More time usually means more cost. Clarify whether the extension is included in the original quote or whether it adds to the total.
• Launch date. If the game has a target launch window, check whether the extension puts it at risk. Better to know now than at the next milestone.
• Your own commitments. If you promised a publisher a build by a certain date, update them early rather than letting the delay cascade.

Write the revised plan down and share it. A verbal agreement about new dates is easy to remember differently.

Red flags in repeated requests

A single extension is information. A pattern of extensions is a diagnosis.

Three patterns and what they indicate.

Every milestone slips by a similar amount. The estimates are consistently optimistic, and the team is not learning from previous rounds. Ask them to add a buffer to future estimates.

Slips are getting larger. The project may be more complex than the plan assumed, and the gap between plan and reality is growing. A scope review is overdue.

The request always comes at the last moment. The team is not tracking progress closely enough to see problems early. Ask for more frequent check-ins or a mid-milestone review.

In all three cases, the conversation should be about the process rather than the specific deadline. Fixing one date does not fix the pattern that caused it.

What we would do

Thank the studio for telling you early. This is genuine, not a formality. A studio that raises problems early is easier to work with than one that avoids them.

Then ask the three questions: what is taking longer, what does the extra time buy, and what is the revised date with confidence level.

If the answers are clear and this is the first or second request, grant it with a written revised plan. If the answers are vague or this is a pattern, have the scope trade conversation instead.

The short version

• A studio asking early is managing the project. Respond to that honestly.
• Ask what is taking longer, what the time buys, and the confidence in the new date.
• Grant extensions when scope changed, the quality gap is specific, or the track record is strong.
• Push back when the request is vague, it is a pattern, or the time comes from testing.
• Offer a scope trade or milestone split instead of defaulting to a longer schedule.
• Update every downstream dependency when a date moves.

Ask your three questions this week if a deadline is under pressure. If you want a studio that raises problems before they become surprises, start a conversation.