How Long Does a Custom Website Take to Build

A custom website takes as long as discovery, content, integrations, and QA take — not as long as someone sits in Figma. Design hours are a line item. Calendar time is wait states: the brief, the copy, the photos, the CRM keys, the form that actually hits an inbox, and the phone pass. I will not invent a market median. The numbers below are planning bands, labeled as such, including the live-in bands published on /websites: a five-business-day Website Direction Sprint, then Creator 1–2 weeks, Business 3–4 weeks, Product 6–10 weeks, assuming one decision-maker and feedback measured in days. This spoke sits under Websites That Feel Like Films.

The short answer

• Clock the wait states, not the mockups. Discovery, copy, media, integrations, and QA decide the date.
• Use planning bands, not a median. I have not measured “the average custom site.” I will not publish one.
• Spurlock published bands (planning, not a promise against stalled feedback): five business days for direction; 1–2 / 3–4 / 6–10 weeks for scoped Creator / Business / Product builds.
• A week is a sprint, not a brand system. Positioning, sitemap, art direction, one homepage concept. Not CMS, motion, and launch.
• Staging is not live. Forms, DNS, analytics, and a mid-range phone decide whether the calendar produced a site or a preview.

If someone says	Translate it to	Then plan
“Design is two weeks”	Canvas time	Ask when copy, keys, and QA sit
“We’ll just start”	No kickoff gates	Move the start date
“Custom takes three months”	Unscoped committee time	Demand a labeled band + assumptions
“We can launch Friday”	Theme or a lie	Sprint or builder; not a custom system

Why are design hours the wrong clock?

People ask “how long to build” and hear “how long to design.” Those are different clocks. Comp time can be short. The project still sits because nobody wrote the offer sentence, the photographer has not delivered, Shopify admin is in a contractor’s email, or legal has not blessed the claims on the fold.

Clock people mean	What they are actually counting	What actually moves the date
Design hours	Figma / Framer / Webflow canvas time	Brief quality and revision rounds
Build hours	Components, CMS, motion	Whether templates are unique or cloned
Discovery	Jobs, IA, proof, out-of-scope	Unwritten strategy becomes redesign
Content	Copy, photos, logos, proof	Empty CMS fields and lorem in production
Integrations	Forms, CRM, booking, merch, mail	Keys, sandboxes, and who owns the account
QA + launch	Phones, a11y, DNS, redirects, analytics	“Looks fine on my laptop” is not shipped

If you only budget design hours, you will be “90% done” for a month. The remaining 10% is the real site: words, keys, and a production URL.

Treat design as one workstream. Treat the other four as the schedule.

What planning bands can you use without inventing a median?

I will not quote a fabricated “typical custom website is twelve weeks.” Scope is not a single product. A five-page artist home is not a Product Platform with auth. A trades phone-first rebuild is not a film-grade brand system. Bands exist so you can plan. They are not a dataset of every studio on earth.

Spurlock Studios published planning bands (as of the /websites offer copy; they assume one decision-maker and fast feedback):

Band (planning)	What it is	Calendar if inputs arrive	What it is not
Website Direction Sprint	Positioning, sitemap, art direction, one polished homepage concept	Five business days	A live custom site
Creator Site	Custom fold and motion for a scoped creator / solo brand build	1–2 weeks live-in	A CMS empire or a product V1
Business Site	Broader pages, conversion architecture, two named integrations	3–4 weeks live-in	Unlimited collections and a shop rewrite
Product Platform / SaaS	One agreed production-ready V1	6–10 weeks live-in	An open roadmap

Those live-in numbers are planning bands on a locked scope, not a median of “custom.” If copy is late, keys are late, or five people have veto, the calendar stretches. The invoice should not silently absorb an undefined wait.

Week-shape inside those bands (planning, inputs on time, one approver):

Band	Week shape if the gates are green	What eats a week if a gate is red
Direction sprint (5 business days)	Days 1–2 jobs + sitemap; days 3–4 direction + homepage concept; day 5 priced build	No offer sentence, no logo file, five taste opinions
Creator 1–2	Week 1 fold + core templates on staging; week 2 motion budget, CMS minimum, QA, live	Copy freeze fails; hero asset missing; DNS owner missing
Business 3–4	Week 1 structure + fold; week 2 interior templates; week 3 integrations + content load; week 4 QA + cutover	CRM properties undefined; second integration appears in week 3
Product 6–10	Front: lock V1; middle: build agreed surfaces; last 1–2: QA, auth/billing dry runs, launch	New surface area mid-build; environments not ready

Other shapes, still labeled as planning — not measured medians:

Shape	Planning-band posture	Why I will not pin a median
Theme swap on a builder	Days to a couple of weeks	You are not buying custom authorship
Authored Webflow / Framer marketing site, materials ready	Often lands inside the Creator / Business bands above	Stakeholder count blows it up
Custom Astro / similar shell, unique interaction	Same clocks; more engineering inside the band	Motion and CMS model dominate
Migration + redirects + Search Console	Add a dedicated slice inside the build band	Old URL count is unknown until you inventory
“Custom” with no brief and a committee	Open-ended	That is not a site. That is a meeting series.

Worth-it is a separate test from duration. If you are still deciding whether to leave a template, read When a Custom Website Is Worth It before you buy a calendar.

What does discovery actually consume?

Discovery is the week people skip, then pay for in revision rounds. It is not a moodboard dump. It is writing down the job of the site so design has something to obey.

Do this before anyone opens a canvas:

1. Name the audience for the next ninety days, not “everyone.”
2. Name the single primary action (book, call, listen, request, buy).
3. Name the proof a skeptic accepts in ten seconds.
4. List pages as jobs, not as a junk drawer of URLs.
5. Write v1 out of scope (blog, shop, multilingual, careers) so it cannot sneak in as “quick adds.”
6. Name who has veto. One person. Not a thread of “the team.”
7. Inventory assets: logo files, photos, old URLs, brand type, claims you can defend.
8. Name the stack constraint (Framer, Webflow, Astro / custom) from editors and exit path, not from a reel.

Discovery output	Done looks like	Fake-done looks like
Fold job	One sentence a stranger can repeat	Three slogans and a service grid
Page map	Each URL has one job	“We’ll figure pages out in design”
Proof list	Named work, constraints, receipts	“Testimonials later”
Out of scope	Written, dated	Smile-and-nod on a shop
Approver	One named human	“Loop in marketing, the owner, and the cousin”
Asset inventory	Files in a folder you both can open	“They’re on the old Squarespace somewhere”

Kickoff checklist — if three of these are blank, you do not have a start date. You have a hope.

• Primary action in one verb
• Secondary action ranked below it
• Audience for the next 90 days
• Proof assets listed (who, what shipped, what was hard)
• Out of scope for v1
• Named approver with a response SLA in days, not “when we can”
• Domain / hosting / DNS owner written down
• Old URL list started, even if ugly

Who owns the wait — write it on the kickoff doc or you will argue about “late” later:

Wait state	Default owner	Studio can proceed if	Studio should pause if
Fold job + IA	You + studio, in writing	Sentence exists	Stakeholders still campaigning for extra jobs
Copy / claims	You (studio shapes from materials)	Draft folder delivered	Empty Drive and “we’ll write it in review”
Photography	You / photographer	Usable stills for the title card	Shoot unbooked and treated as a blocker
Domain / DNS	You or a named admin	Login exists	Registrar is “the old developer”
CRM / booking keys	You / ops	Sandbox or properties list	No account, no owner
Legal on fold claims	You / counsel	Bless or cut	Counsel scheduled after announcement
Revision rounds	Named approver	Comments in days	New strategy each round

Skip this and the “build” starts as taste negotiation. Taste negotiation has no end date.

Why is content usually the long pole?

The build does not stall because a button radius is undecided. It stalls because the About page has no facts, the work grid has no real stills, and the offer copy still says “premium solutions.” I shape copy from your materials. I do not invent testimonials, conversion lifts, or a voice you cannot stand behind. Empty inputs become empty weeks.

Content type	What “ready” means	Typical wait if it is not ready	What to do instead of freezing the build
Offer copy	One repeatable sentence + scope in/out	The fold cannot be locked	Lock a draft sentence in discovery; revise once
Proof	Named projects, constraints, real stills	Case studies slip to “phase 2” forever	Ship fewer, true stories
Photography	Rights-cleared, right crop, not a dump of 4k originals	Hero is a stock handshake	Grade what you have; schedule a shoot in parallel
Logos / wordmark	SVG or high-res, usage rules	Wordmark is a PNG from a screenshot	Rebuild the mark as a file, not as a vibe
Legal / claims	What you can print	Counsel reviews after the premiere	Park contested claims off the fold
CMS entries	Structured fields, not a Google Doc novel	Launch with lorem	Minimum entries for v1 collections only
Redirect list	Old path → new path	SEO equity dies at cutover	Inventory URLs in week one, not launch night

Content procedure that keeps the band honest:

1. On day one, dump every existing page, PDF, and bio into a single folder.
2. Mark each asset: use / rewrite / kill.
3. Freeze v1 collection counts (for example: six projects, not “all of them”).
4. Put legal on the claims that will live on the fold, not on the footer trivia.
5. If a photo does not exist, design the title card to work as type + one still you do have.
6. Do not hold launch for a perfect archive. Hold launch for true words and a working ask.

What the studio can still do while content is late — and what it cannot fake:

If this is late	Parallel work that is honest	Fake progress
Body copy	Templates, type system, CMS fields, motion on placeholder structure	Shipping lorem as if it were voice
Final photos	Layout to crop rules; title card that works as type	Stock handshake as “temporary” that becomes permanent
Legal line on a claim	Park the claim; design the rest of the fold	Designing three versions of a sentence counsel will kill
CMS entries	Model the collection; load the minimum v1 set	Building twenty empty project pages
Redirect targets	Inventory old URLs; draft the map	Promising SEO continuity with no list

A film-grade site with lorem in production is not cinema. It is a costume with the tags still on.

How do integrations stretch the calendar?

Page count is a weak proxy. Named tools are not. A contact form to email can be a day. A form to a CRM with required properties, a booking embed, and a checkout is a different product. Integrations wait on access, not on CSS.

Integration	What has to exist before build time is real	Failure if you start without it
Form → inbox	Deliverability tested from a phone on cellular	Staging form, production /dev/null
Form → CRM	Sandbox or properties list, API key, owner of the object	Duplicate leads, missing fields
Booking / calendar	Account you own, embed rules, timezone	Prospects land on a dead widget
Payments / merch	Store owner access, test mode, product IDs	Fake “buy” buttons
Mail / newsletter	List provider, double opt-in rules, from-domain	Spam folder premiere
Analytics / pixels	Production IDs, conversion events named	You cannot tell if the ask works
Auth / billing / DB (Product band)	Scope locked; environments; who admins	V1 becomes an open tab

Integration kickoff — numbered, in order:

1. List every tool the site must talk to. Names, not “and more.”
2. For each, name the account owner and whether you can grant access this week.
3. Prefer native or one well-supported embed over a stack of apps faking a feature.
4. Build against test mode / sandbox first. Production keys on launch day, not as folklore.
5. Test a real submission from cellular, not only office Wi-Fi.
6. Write the failure: if the CRM is down, does the lead still hit email?

• Every integration has a named owner
• Keys exist in a place that survives the contractor leaving
• Test submission logged in the real destination
• Spam / filtering checked
• Success state on the site matches what the human received

Two named integrations is a Business-band conversation. An unbounded “connect everything” is how 3–4 weeks becomes an unplanned Product-shaped mess.

What does QA have to cover before you call it live?

QA is not a Friday polish. It is the last hard clock, and it is the one teams skip because the desktop preview looked expensive. A custom site that fails a mid-range phone, a keyboard, or a form test is not late. It is unfinished.

QA surface	Pass	Fail
Fold on a ~390px phone	Offer + primary CTA readable without pinch-zoom theater	Title card crops the ask off-screen
LCP / INP / CLS	Field-minded: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 at p75, as Google publishes for Core Web Vitals	Lab-green on Wi-Fi desktop only
Reduced motion	Designed end-state; no opacity: 0 leftovers	Motion off equals blank hero
Keyboard	Tab order matches the story; focus visible	Custom cursor, no focus
Forms	Cellular submit hits a human	Works in preview, dies after DNS
HTTPS + canonical	Production host, not a Netlify preview URL as the “launch”	Two hosts, two stories
Redirects	Old URLs mapped	404 as the migration strategy
Analytics	Primary action event fires in production	“We’ll add tracking later”
Rollback	Previous deploy or DNS TTL named	Hope

Launch QA checklist I will not skip:

• Production URL resolves; HTTPS is real
• Primary CTA on a real phone on cellular
• Form test from that phone
• Reduced-motion pass
• Keyboard pass on the contact path
• Open Graph still is the title card
• 404 matches the brand
• Sitemap / robots / canonicals agree
• Who owns domain, hosting, and Search Console is written down

Soft launch (small list, forms and phones) and hard launch (DNS cutover plus announcement) are different dates. Mixing them is how you announce a site whose form posts nowhere.

QA calendar inside a planning band — put it on the same sheet as design, or it will lose:

Band	Where QA sits (planning)	Do not do
Direction sprint	Concept review on phones; no production QA because nothing is live	Treat the homepage concept as launched
Creator	Last 2–4 days of the 1–2 week band	Announce on day the fold “looks done”
Business	Most of week 4	Wire CRM and QA on the same afternoon
Product	Last 1–2 weeks: auth, billing, roles, rollback	Demo-green on a happy-path laptop

Procedure for a one-hour launch rehearsal (do this before DNS, not after the tweet):

1. Open the staging URL on a mid-range Android on cellular.
2. Read the offer out loud from the first screen.
3. Complete the primary action.
4. Confirm the success state (inbox, CRM row, calendar, tap-to-call).
5. Repeat with reduced motion on and with a keyboard only.
6. Only then book the cutover window.

How does a one-week sprint sit next to a build?

A Website Direction Sprint is five business days: positioning, sitemap, art direction, one polished homepage concept, and a build quote priced off what you actually decided. You keep the deliverables either way. It is not a custom website. It is how you stop guessing about taste and scope before you write the bigger check.

Move	Planning-band calendar	You walk away with	You do not walk away with
Direction sprint	5 business days	Jobs, sitemap, direction, one homepage concept, priced build	Production CMS, integrations, launch
Creator build	1–2 weeks (planning; inputs on time)	Live scoped custom site	A self-serve newsroom and two CRMs
Business build	3–4 weeks (planning)	Broader templates, conversion path, two named tools	Product auth / billing
Product V1	6–10 weeks (planning, scope locked)	One agreed production V1	Unlimited mid-build wishes

Decision list — pick the move that matches the actual problem:

1. Sprint only if you do not yet know the fold job, the page list, or whether custom is even the product.
2. Sprint then build if you want to see a homepage concept before you buy the live-in band.
3. Build without sprint only if the brief, assets, and approver already exist in writing.
4. Do not buy a build to paper over an offer that still changes weekly. Stay on a builder until the offer holds. The threshold test is in the worth-it spoke.

Trades and local SMBs often need the phone path more than a ten-week cinema. If the job is tap-to-call, service area, and proof that survives a job-site phone, use the trades SMB website playbook and do not import a Product-band calendar you do not need.

What usually fails first when a custom timeline slips?

The first failure is almost never “the designer was slow at kerning.” The first failure is an input that never showed up, or a committee that reopened the brief in week three.

Failure	What it costs	What to do instead
No written fold job	Endless homepage revisions	Freeze the job sentence; design obeys it
Five approvers	Each round resets motion and type	One veto; others comment, they do not steer
Copy promised “next week” for four weeks	Build idles or ships lorem	Draft from existing pages on day one
Photography as a blocker	Hero waits on a shoot that was never booked	Title card that works with current stills
Integration keys in a freelancer’s inbox	CRM work starts at the end	Access as a kickoff gate
Scope creep disguised as feedback	Business band tries to become Product	New surface = new conversation
QA squeezed into launch morning	Broken form, bad LCP, no redirects	QA as a named slice inside the band
Big-reveal process	Six silent weeks, then panic	Staging in the open; feedback in days

Concrete failure mode I will not romanticize: a brand “finishes design” in ten days, then waits six weeks for copy, Shopify access, and a partner to bless the fold. The studio looks late. The clock was content and keys. If your contract does not name wait states as client-side calendar, you will fight about dates that were never in the studio’s control.

Protect the band:

• Kickoff gate: assets + access + approver, or the start date moves
• Feedback SLA in days, written
• Revision rounds capped
• Out-of-scope list dated
• Staging URLs from week one of the build, not a premiere
• QA days on the calendar before announcement

Bravery is not skipping QA because the comps looked expensive.

How does a slow calendar hit conversion?

Every week the old site stays up, the current fold keeps doing its current job — or failing it. A custom project does not accrue conversion in Figma. Conversion starts when a stranger can complete the ask on a phone. Delayed launch is delayed asks. I will not invent a percentage lift for “shipping two weeks faster.” I will say what actually moves.

Delay	Conversion effect	Not the effect
Fold still has four peer CTAs	The ask stays noisy	“Brand awareness” as a consolation
Proof pages unpublished	Skeptics bounce; models and humans both get mush	A blog calendar substituting for case studies
Form untested	Leads die silently	Traffic as a vanity win
Trade site hides the number	Calls do not happen	A cinematic grain overlay “building trust”
Seasonal window missed (tour, peak HVAC, drop)	The site launches after the reason to act	“We’ll catch the next one” as a plan
Staging only	Nobody in the market can convert	Internal compliments

Procedure — keep conversion on the calendar, not as a hope after launch:

1. Name the primary action in the brief. That action is the launch criterion.
2. Put a working ask on staging as soon as the fold exists. Do not wait for motion.
3. Soft-launch the form to a small list. Confirm delivery.
4. Hard-launch when DNS, HTTPS, and the phone path work.
5. Measure the action (calls, bookings, qualified forms), not bounce rate theater.

A custom site that launches without a working ask took however many weeks to ship a mood board. Mood boards do not pay rent.

What should you ask a designer about this?

Ask for clocks, gates, and wait states. Do not ask “can you do it fast” and treat the smile as a schedule.

Question	A useful answer	A useless answer
What are you clocking — hours or calendar?	Discovery, content, integrations, QA named	“Design takes two weeks” as the whole plan
What band is this project in?	Sprint / Creator / Business / Product or equivalent, with assumptions	“It depends” with no bands
What has to be true on day one?	Asset + access + approver checklist	“Just send whatever you have”
How many unique templates, not pages?	A number	“Unlimited pages”
Who writes copy?	You / them / from your materials, named	“We’ll find the voice in design”
How many revision rounds?	A number	“Until you’re happy” (no date)
What happens when we are late with content?	Start date moves, or a freeze with placeholders	Silent slip, then blame
What does live mean?	Production URL, form test, phone pass	A Figma prototype or a preview deploy
Who owns DNS and the repo on day 30?	Named	“We’ll figure handoff later”

Ask it as a procedure in the sales call:

1. Have them walk the four clocks (discovery, content, integrations, QA) against your stack.
2. Write the planning band and the assumptions (one approver, feedback in days, named tools).
3. List kickoff gates. If a gate is red, the start date is a lie.
4. Agree the definition of live in one sentence.
5. Agree what happens when scope grows.

If they cannot name wait states, they are selling canvas time. Canvas time is not a website.

What should you skip if you only have a week?

Skip the custom brand system. Buy a direction sprint or a ruthless cut on the current site. A week can lock jobs and a homepage concept. A week cannot honestly ship CMS collections, two CRMs, a motion budget, a migration, and QA that survives a phone.

In a week	Out of a week
Fold job in writing	Full custom design system
Sitemap of pages that matter	Every service micro-page
Art direction you can show a partner	Scrubbed scroll scenes on every section
One homepage concept	Shop + blog + careers + multilingual
Kill competing CTAs on the current site	A stack migration
Phone-first CTA if you are a trade	New photography production
Form delivery test on the current domain	“Replatform and redesign” as one move

One-week checklist:

• Write the fold job and primary action
• Cut the extra CTAs on the live homepage if you control it
• Inventory assets and old URLs
• Name the approver
• Decide sprint vs stay-on-builder vs later build
• Do not announce a custom relaunch date you cannot staff

If you are a trade shop, the week is better spent on tap-to-call, NAP consistency, and a form that rings a human than on commissioning cinema. The playbook for that lane is the trades spoke, not a Product-band fantasy.

A week used as direction is expensive in a useful way. A week used as “we’ll just build the custom site” is how you get an unfinished preview and a missed date.

When is a custom site not worth starting yet?

Custom is not worth starting when the offer still wiggles, the proof does not exist, or nobody can approve. Duration is beside the point. You would be buying calendar for a product you cannot describe.

Signal	Wait	Start
Offer changes every two weeks	Stay on a builder; spend on the offer	Offer has held for a quarter
No photos of real work / trucks / rooms	Shoot or gather first	You can fill a proof grid with truth
Template is already converting and the leak is follow-up	Fix follow-up	Template cap is losing shortlists
Five stakeholders, no veto	Get governance	One named approver
You cannot name the primary action	Write that first	Action is a verb
You need a live URL this Friday	Theme / builder	Custom bands do not do Fridays
You want custom because the word sounds expensive	Read the worth-it spoke	Template cap, ownership, or conversion path is the reason

Stay / go, in order:

1. If the offer is unstable, do not buy custom. Buy clarity.
2. If the template is costing deals or you cannot own an exit, custom (or authored-on-builder) is in play — that is the worth-it spoke.
3. If you are a local trade and the phone number is buried, fix the phone path before you buy film grain.
4. If you need to see the fold before a build check, buy the five-day sprint.
5. If brief, assets, and access exist, pick a published live-in band and protect it with gates.

Starting a custom build to soothe ego, with no proof and no approver, is how “how long does it take” becomes “why isn’t it done.” It was never going to be done. It had nothing to obey.

How do you measure whether the timeline is working?

Do not measure “percent designed.” Measure gates. A timeline is working when kickoff gates were green, wait states are visible, staging exists, and the definition of live has not quietly shrunk to a screenshot.

Signal	Timeline is holding	Timeline is theater
Kickoff	Assets, access, approver dated	“We’ll collect as we go”
Brief	Fold job unchanged for the band	Job rewritten each review
Staging	Clickable URLs in the first third of the build band	Big reveal at the end
Feedback	Comments in days, one veto	Slack archaeology
Content	v1 fields filled or explicitly deferred	Lorem on the launch candidate
Integrations	Test events in the real tool	“We’ll wire it at launch”
QA	Phone / form / a11y on the calendar	Polish as leftover hours
Live definition	Production URL + working ask	Preview URL emailed to friends

Measurement procedure:

1. Write the planning band and assumptions on day zero (scope, approver, feedback SLA, named integrations).
2. Score kickoff gates red / yellow / green. Red moves the start date.
3. Once a week, list blockers as wait-state owners (client content, client keys, studio build, third-party vendor). Do not hide client wait inside “the build is late.”
4. Require a staging URL while the band is still young.
5. At the QA slice, run the launch checklist. Failures extend live, they do not get announced through.
6. After hard launch, track the primary action for two to four weeks. That is conversion, not a substitute for whether the build calendar held.

If you cannot name this week’s blocker in one sentence, you are not managing a timeline. You are hoping.

Weekly scoreboard (five minutes, same questions every week):

• What is this week’s single blocker, in one sentence?
• Whose wait state is it (studio / you / vendor)?
• Did the fold job stay frozen?
• Is staging clickable?
• Did live’s definition shrink to a screenshot?

Three yeses on the last three rows and a named blocker: the band is still real. Three nos: stop designing, fix the gate.

FAQ

How long does a custom website take to build?

As long as discovery, content, integrations, and QA take — not as long as the design file. I will not invent a market median. Spurlock published planning bands: five business days for a Website Direction Sprint, then 1–2 weeks Creator, 3–4 weeks Business, and 6–10 weeks Product for a locked scope, assuming one decision-maker and feedback in days. Late copy, keys, or a committee stretch the calendar.

How do I measure whether the custom website timeline is working?

Score gates, not “percent designed.” Kickoff assets and access should be green, the fold job should stay frozen, staging should exist early, wait states should have owners, and live should mean a production URL plus a working ask. If the only metric is a Figma progress bar, the timeline is theater.

What usually fails first when teams try this?

Inputs. Copy, photos, integration keys, and a single approver. Teams blame design speed while the project sits on empty CMS fields and a CRM nobody can log into. The second failure is scope creep dressed as feedback. Write wait states and out-of-scope on day one or the band is fiction.

How long does this take to show results?

A working form or tap-to-call can produce leads the day you hard-launch, if QA passed. That is the conversion clock you actually bought. Organic search, AI citations, and “the market noticed” are different clocks — often weeks of crawl and consistency, not a Friday miracle. Do not treat a build live-in band as an SEO SLA. I will not fabricate a leads-by-week-two number.

What should I skip if I only have a week?

Skip the custom system. Use the week for a direction sprint or for cuts on the current site: one fold job, fewer CTAs, asset inventory, a named approver. Do not promise a migrated, integrated, QA’d custom launch in five business days. That is how dates die.

When is this not worth doing yet?

When the offer still changes, proof does not exist, or nobody can approve. Custom calendar cannot replace a missing product. Stay on a builder, fix the phone path if you are a trade, or buy a five-day sprint to lock direction. Start a build when the brief, assets, and access can survive week one.

CTA

If you want a date you can defend, clock discovery, content, integrations, and QA — then pick a planning band that matches the actual product.

Explore /websites or book a Website sprint at /contact?intent=websites-sprint.