How Long Does a Custom Website Take? Build the Schedule From Scope

Why the quoted number is usually bigger than the work

It helps to understand what a long quote is actually made of. A twelve-week project is rarely twelve weeks of building. It can be a smaller amount of building spread across a calendar, and the gaps are where the time goes: a queue in front of you, a review that takes four days to come back, an export nobody has requested from the old platform yet, a decision waiting on somebody who is in meetings all week. The design and the code are not usually what make a project slow. Waiting is.

That is worth knowing for two reasons. It tells you which questions actually shorten your timeline, and none of them are about how fast anyone types. It also tells you what to look for in a schedule: one that names its dependencies and who owns each of them is describing real work, while one that offers a single headline duration is describing a hope.

The schedule formula

Calendar duration is not developer hours divided by eight. It includes active work, dependency lead time, review and approval windows, vendor response, rework, release constraints and agreed contingency. Some work can overlap; dependencies on the critical path cannot.

• ✓
  The work itself: discovery, design, content, development, migration, integrations, testing and documentation.
• ✓
  What you are waiting on: logins, accounts, exports from the old system, copy, images, legal review, vendor access, and decisions from people who are busy.
• ✓
  Review: named approver, response window, consolidated feedback and permitted revision rounds.
• ✓
  Release day: freeze changes, take backups, switch DNS, turn on redirects, load the production credentials, run the checks, keep the rollback ready, and watch it.
• ✓
  Change: how a new feature, page, integration or approval round changes price and schedule.

"A brochure site and a commerce rebuild do not share one honest duration. The schedule follows the dependencies, not the project type.

Typical timelines by project size

These are the ranges we plan around, not commitments. The dates that bind either side are the ones written into the accepted project terms after scoping, because the drivers in the right-hand column vary enormously between projects. The same tier names appear on our pricing page, with the deliverable side described in what a Scale statement of work can include and the cost inputs in our website cost guide. Commerce scope is set out on our ecommerce engineering page.

Scope signals that change the clock

What moves the date is unique templates and states, not raw page count, and after that it is content readiness rather than engineering. Seven signals are worth pricing separately. The two most often left out of a first estimate are redirect mapping and search continuity, and both get discovered late enough to hurt.

• ✓
  Unique templates and states, not only raw page count.
• ✓
  Writing new content, moving the old, cleaning it up, translating it, setting who can edit what, and getting someone who knows the subject to check it.
• ✓
  Setting up the content types, preview, the publishing flow, roles, the import, and training whoever will use it.
• ✓
  Forms, CRM, calendars, search, maps, authentication, payments, tax, shipping and external APIs.
• ✓
  Accessibility target, browser and device matrix, security review and performance acceptance.
• ✓
  URL changes, redirect mapping, structured data, analytics continuity and search monitoring.
• ✓
  Legacy data quality, undocumented behavior, rate limits and vendor approval or certification.

The redirect and search-continuity items in that list are the ones most often left out of a first estimate. Our migration cost assessment breaks that work down, our article on what happens to search visibility during a migration covers the monitoring it needs, and our WordPress migration service page describes how we run it.

A phase-based estimate is safer than one headline number

Calendar duration is not developer hours divided by eight. A schedule that names its dependencies and its owners is describing real work; one that offers a single headline duration is describing a hope. Five phases, each with the evidence that closes it and the dependency that usually blocks it. Read the third column first, because that is where your own schedule will slip.

What the MyCustomPatches example does and does not show

MyCustomPatches is an independent client, not a PandaCodeGen property, and its figures are owner-confirmed and published with permission. Its owner reports a delivery of about 22 days. We do not hold a dated record of that confirmation, so treat it as an owner statement for one accepted scope rather than an audited figure, and not as a market average or a promise for the next site. Without a public scope baseline, phase dates, paused-time policy and acceptance record, it should not be used to infer that every project of a similar-looking size takes 22 days. The scope behind it is written up on our MyCustomPatches project page, and the rest of our delivered projects show how differently the same phase list plays out.

Client delays are not the only source of delay

Content and approvals can be critical dependencies, but it is unfair and inaccurate to say most waiting is always the client's fault. An agency can delay discovery, design, implementation, QA, communication or rework. A vendor can delay access or approval. The schedule should expose every dependency and owner instead of assigning blame in advance.

An example of a project that is slow for good reasons

Not every long timeline is a failure of process, and it would be dishonest to imply otherwise on a page selling speed. One current build, a site for a medical practice, is taking a while, and every reason for it is a good one. We cannot use stock photography, because the whole proposition rests on this practitioner's own work and their own results. The owner sees patients all day, so each round of feedback realistically comes back the next day rather than the same afternoon. The copy is medically sensitive and has to be correct, which means it gets checked properly rather than quickly.

That project should be slow. Compressing it would mean using someone else's photographs, accepting less review on clinical wording, or pretending an owner with a full clinic can turn feedback around in an hour. The useful question is never how fast a site can be built in the abstract. It is which parts of your particular project genuinely cannot be hurried, and whether the schedule in front of you is honest about them.

What “content ready” means

Content readiness is the single input that moves a Growth-tier date more than anything on the engineering side. Ready means an approved page inventory, copy that is final or clearly staged with a named approver, licensed media, structured business data, decided SEO choices, and an agreed plan for what is still missing. The named approver is the part that is usually skipped and always needed.

• ✓
  Approved page inventory, navigation and target audience.
• ✓
  Final or clearly staged copy with a named subject-matter approver.
• ✓
  Licensed images, video, logos, icons, testimonials and attribution.
• ✓
  Product, service, team, location, policy and contact data in an agreed format.
• ✓
  SEO decisions for titles, descriptions, headings, URLs, redirects and structured data.
• ✓
  A plan for missing content, including whether placeholders can reach production.

You do not need a finished design to start

A common reason projects sit unstarted for months is the belief that you need a polished design before anyone can begin. You do not. You need your content and a direction, and the direction is allowed to be loose. Some clients arrive with a clear vision and we build to it. Some send a handful of references and say roughly this, and we design from there. Some say surprise us, which is also a workable brief. None of those change the price, and the last two are more common than people expect.

What genuinely moves your date is whether the words and the images exist and whether someone can approve them. Waiting until the design is settled in your head before you start is usually just the waiting moved earlier, where it is less visible and nobody is tracking it.

Can a site launch in one week?

A narrowly scoped site can sometimes move that quickly when content, design direction, access, decisions and acceptance are ready, but PandaCodeGen does not publish a universal seven-day promise. A rush plan must identify what is included, what is deferred, the review cadence, quality gates and whether the compressed schedule changes price or risk. We do not refuse rush work. We price the additional hours it takes up front, because the alternative is pretending speed is free and then finding somewhere quieter to take it out of, which is usually testing.

Quality gates that should not be removed to save time

We do not refuse rush work. We price the additional hours it takes up front, because the alternative is pretending speed is free and then finding somewhere quieter to take it out of, which is usually testing. Six gates are the ones that get quietly dropped, and the performance gate is the one buyers most often assume is free.

• ✓
  Functional and failure-state tests for forms, integrations, calendars, payments and notifications.
• ✓
  Responsive, keyboard, focus, label, contrast and content-state checks.
• ✓
  Security controls, dependency review, secret handling, abuse controls and production configuration.
• ✓
  SEO output, URL, redirect, sitemap, canonical, robots and structured-data checks.
• ✓
  Representative mobile and desktop performance tests under the accepted method.
• ✓
  Backups, cutover, rollback, monitoring, documentation and account handoff.

The performance gate is the one buyers most often assume is free. Our guide to speeding up a website and our explainer on Core Web Vitals describe the work that sits behind it.

What PandaCodeGen puts into the schedule

The signed scope should state the project start condition, milestones, deliverables, dependencies, business-day definition, review windows, change control, acceptance, launch, support start, pause conditions and remedies. The normal payment split is 30 percent at onboarding and 70 percent on delivery, subject to the accepted contract.

Starter support is 15 business days and Growth or Scale support is 30 business days under the agreed coverage and start date. Support does not silently add new features or third-party changes to the original schedule. Our custom engineering service page describes the delivery process those clauses sit on, and our article on what website ownership actually covers explains what the handoff at the end should transfer.