What I ask before saying yes to a rush project

What do I ask before saying yes to a rush project?

I ask five questions: what actually happens if the date slips, what can be cut to hit it, who can make decisions quickly, what is already ready, and what the rush costs. A real deadline, flexible scope, and a fast decision maker usually mean yes. Otherwise I say no or propose another date.

Rush projects are tempting. The client is motivated, the budget is often ready, and there is a satisfying energy to shipping fast. They also expose every weak spot in scoping. Across 100+ projects for 25+ clients over more than six years, I have settled on a short checklist I run every time.

None of these questions are clever. Their value comes from asking them before I say yes, while there is still room to shape the project, rather than in the middle of the second week when everyone is tired.

Why do rush projects go wrong so often?

Rush projects go wrong because speed hides missing decisions. When a timeline is comfortable, open questions get answered as they come up. When it is tight, every unanswered question becomes a blocker, and blockers stack. The work itself is rarely the problem. Waiting on content, approvals, and access is what breaks the schedule.

There is also a pressure effect. Under a deadline, everyone agrees to things they have not fully thought through. Scope grows quietly because saying no feels like slowing down. By the time anyone notices, the original date is impossible.

So my first job on a rush request is not to start building. It is to find the decisions that are still open and see whether they can be closed quickly.

What happens if the deadline slips?

This is the first question, because it tells me whether the deadline is real. A launch tied to an event, a funding announcement, or a contract start date is a hard deadline. A date picked because it sounded good in a meeting is a soft one. Both are valid. They just call for different plans.

If the date is hard, I want to know the consequence of missing it in plain terms. Missed press coverage? A sales team with nothing to send? That consequence decides how aggressive the scope cuts should be.

If the date is soft, I say so gently and suggest a realistic one. Often the client is relieved. Nobody enjoys a fake deadline, and naming it early saves a lot of stress for both sides.

What can be cut to hit the date?

A rush project only works if scope can bend. I ask the client to sort the request into must-have for launch and can wait two weeks. If everything is a must-have, the project is not a rush project. It is an overbooked one, and adding pressure will not make it fit.

The cuts are usually easy once someone asks. A blog section can launch empty and fill up later. Secondary pages can go live as simple versions. Integrations can start with a manual step and get automated after launch.

I write the cut list down and share it before starting. That document becomes the reference point when someone asks for "just one more thing" in week two. I explained why I keep that kind of written trail in why I keep a written record of every project decision.

Who can make decisions quickly?

A fast project needs one person who can approve design, copy, and scope changes within a day. If approvals need three stakeholders and a weekly meeting, the timeline is fiction. I ask for a named decision maker and agree on how quickly they will respond before any work begins.

This question tends to surface the real risk. A founder who says "I will approve everything myself" is often the best possible partner for a fast build. A marketing lead who must check with legal, the CEO, and the sales team will struggle, through no fault of their own.

If decision speed is the bottleneck, I would rather know on day one. Sometimes the fix is simple, like a standing fifteen-minute call each morning for approvals.

What is already ready?

I ask what exists today: final copy, brand files, logins, domain access, product screenshots, and any content that needs migrating. Each missing piece is a dependency someone else controls. A rush build with everything ready is very different from one where copy is still being written while pages are being designed.

Access is the sneakiest dependency. Domain registrar logins, analytics accounts, and CRM credentials can take days to track down. I ask for them first, before design starts, because waiting on access at the end is the most frustrating way to miss a date.

If I am taking over an existing site under time pressure, the checklist gets longer. I covered that situation in what I check before taking over a Webflow site.

What should a rush cost?

A rush should cost more, because it displaces other work and compresses review time. I price on a fixed fee, and most of my projects land between $1,000 and $10,000. For a genuine rush, the fee reflects the reshuffling and the risk. I say that openly rather than burying it in the estimate.

Being upfront about the premium also tests the deadline. If the client is happy to pay more to hit the date, the date matters. If the premium makes them reconsider, the date was probably softer than it looked, and a normal timeline at a normal fee might suit everyone better.

Fixed fees help here. The client knows the full cost before work starts, and I carry the risk of the estimate. That only works because the scope is pinned down by the cut list and the decision maker is named.

When do I say no to a rush project?

I say no when the date is soft but treated as hard, when nothing can be cut, when decisions need a committee, or when key materials will not exist until the last few days. Any one of those alone is manageable. Two or more together usually mean the project will be late, stressful, and worse than it needs to be.

Saying no does not have to end the conversation. Often I propose a phased plan instead: a lean version by the date, then the rest over the following weeks. Many clients prefer that once they see it laid out.

The worst outcome is saying yes to a project I already doubt. It damages the work, the relationship, and the referrals that follow. A clear no, or a clear alternative, is kinder to everyone.

What should you do next?

If you are planning a fast launch, answer these five questions before you contact anyone: what happens if the date slips, what can be cut, who decides, what is ready, and what budget covers the rush. Write the answers down. They will make any freelancer or partner faster, and they will show you whether the date is realistic.

If you are on the other side, building for clients, try running the same questions on your next rush request. You will find most of the risk in the first conversation instead of the last week.

And if you have a launch coming up and want an honest read on whether the timeline works, reach out. I am happy to look at what you need and tell you plainly whether I can do it, and how.