A web design package should protect your launch date, not turn it into a polite mystery. If the proposal gives you a page count and a price but stays fuzzy about content, approvals, SEO basics, hosting handoff, or what “done” means, the calendar is already in danger.
Most people comparing web design proposals are trying to answer the same practical questions. What is actually included beyond the mockups? Who handles content import, forms, SEO basics, and launch-day setup? How many review rounds are included before feedback turns into delay? And which missing line item is going to pop up the week before launch like an unwanted sequel?
The plain version first: a good package is not just design plus development. It is a list of deliverables tied to realistic phases, named responsibilities, and acceptance criteria. Acceptance criteria means the test for “done.” A handoff is the moment one part of the project gets passed cleanly to the next person or team. If those pieces are missing, the timeline often slips for boring reasons: content is late, forms are not fully scoped, nobody confirmed DNS access, or QA becomes a vague promise instead of a checklist.
Here’s the quick map. Below you’ll get a line-by-line checklist, a phase-by-phase timeline reality check, a responsibility map, a simple scoring rubric, and 12 questions to take into your first call. If you are comparing providers right now, keep this guide open beside the proposal instead of relying on hopeful interpretation.
The Short Answer: A Launch-Safe Package Names Deliverables, Owners, and Acceptance
In this article, a package means four things together: the deliverables, the timeline, the responsibility split, and the acceptance gates. If one of those is missing, the package is incomplete even if the design work itself looks strong.
This is usually written in the proposal under Deliverables, Project Plan, Scope of Work, or Assumptions. The risky part is that many proposals sound complete while leaving the delay-prone parts vague. Typical omissions include content migration, CMS setup limits, form testing, SEO launch basics, hosting or domain handoff, and what happens in the bug-fix period after launch.
If it is not written, assume it is unclear. That may sound a little stern, but calendars respond better to documented scope than to shared optimism.
What a Web Design Package Should Include, and What It Usually Leaves Fuzzy
Use this table as your first scan. You are checking whether the package covers the work that gets a site from approved design to working launch.
| Area | What should be named | What often stays vague | Where this shows up |
|---|---|---|---|
| Design and build | Responsive layouts, template count, page count, revision rounds, development of approved designs | Which pages are unique, which reuse templates, and what happens on mobile | Deliverables, Design Scope, Project Plan |
| CMS setup | Which CMS is used, editor roles, reusable page sections, blog/news support if included | What editors can change safely and what needs developer help later | Technical Scope, CMS Setup, Admin Features |
| Content import | Whether existing text and images are migrated, how many pages are populated, who formats and approves content | Who cleans old copy and who is responsible if assets arrive late | Migration, Content Entry, Assumptions |
| Forms and interactions | Contact or quote forms, notifications, confirmation messages, spam protection basics | Who tests deliverability and where submissions are routed | Features, Functional Scope |
| SEO launch basics | Indexability defaults, title and meta templates, sitemap and robots basics, URL structure decisions | Whether these are included before launch or left for “later” | SEO Basics, Launch Readiness |
| Analytics basics | Tracking code placement and who verifies it is firing | Which conversions are checked and when | Integrations, Measurement |
| Launch and support | Deployment steps, DNS and SSL ownership, redirect handling, bug-fix window | What counts as a bug versus a paid change request | Launch Plan, Support, Warranty |
If you want a useful baseline for what a service package should feel like when it is fully mapped, the site’s web design services page is a sensible next step. It gives you a service context, but the proposal still needs the checklist above in writing.
Timeline Reality Check: The Phases That Protect Your Launch Date
Most delays do not come from one dramatic failure. They come from small dependencies that were never named. A launch-safe package maps the project into phases with a visible “done” milestone for each one.
| Phase | What happens here | What “done” looks like | Common delay point |
|---|---|---|---|
| Discovery | Page list, goals, technical requirements, inputs, approvals, dependencies | Signed scope, final page list, asset request list, launch target agreed | Content owners are not identified or required access is missing |
| Design | Wireframes or mockups for key templates and mobile behavior | Design approval is explicit, not “looks good for now” | Unlimited-looking feedback loops with no deadline |
| Build | Templates, CMS setup, forms, content entry, integrations | Templates function, pages are populated, forms route correctly | Late content, unclear CMS scope, missing access credentials |
| QA | Cross-browser checks, mobile checks, links, forms, tracking, launch checklist | Test list is complete and issues are resolved or accepted | No checklist, so QA becomes “click around and hope” |
| Launch | Deployment, DNS or hosting changes, SSL, redirects, final verification | Live site loads correctly, forms work, tracking works, redirects behave | DNS access, SSL, or redirect ownership was never confirmed |
| Support | Bug fixes, handoff notes, paid change process, ongoing support options | Bug window is defined and the request path is documented | Everything after launch gets treated as a surprise invoice |
Ask the provider to tie dates to dependencies. If the proposal says “4 weeks,” the next question is “4 weeks assuming what arrives when?” A timeline without assumptions is just decorative confidence.
Deliverables Checklist: Compare Proposals Line by Line
This is the part to score, not skim. A package should make each deliverable easy to confirm.
- Pages and templates: Number of pages, number of unique templates, and whether landing pages, blog templates, or case study templates are included.
- Responsive behavior: Mobile navigation, form behavior, image handling, and how layouts adapt on smaller screens.
- CMS setup: Which CMS is included, what the editor can update, whether blog/news publishing is supported, and whether roles or permissions are configured.
- Content import: How many pages are populated by the provider, whether old content is migrated, and who formats text, images, and documents.
- Forms and email: Which forms are included, where emails go, whether confirmation emails are sent, and who tests deliverability.
- SEO basics: Indexability, title and meta templates, heading structure expectations, sitemap and robots basics, and URL decisions before launch.
- Analytics basics: Tracking code installation and the simple check used to confirm it is working.
- Performance and accessibility basics: What will be checked, reported, and fixed before launch at a practical level.
- Optional extras: Newsletters, galleries, document libraries, or forum-like features only if they are explicitly included and scoped.
Mini-example of “done” helps here. “Form included” is vague. “Contact form sends to [email protected], shows a success message, sends a confirmation email, and was tested on desktop and mobile” is usable.
If you are still deciding whether the package lines up with the broader service mix you need, the homepage gives a quick overview of the core service lanes. Keep that separate from the proposal test. The homepage tells you what they offer. The checklist tells you whether your launch is protected.
Responsibility Map: Who Provides What So Nobody Blames the Calendar
A responsibility map is exactly what it sounds like: a written split between what you provide and what the provider delivers. This is usually written under Client Responsibilities, Assumptions, or Dependencies. If it is missing, delays become strangely ownerless.
| Client provides | Provider delivers |
|---|---|
| Approved text, images, brand assets, legal copy, and feedback within agreed windows | Design files or approved layouts, page build, CMS configuration, and content implementation as scoped |
| Domain, hosting, DNS, or registrar access when required | Deployment plan, technical setup guidance, and launch execution as scoped |
| Inbox addresses and business rules for forms, notifications, or routing | Forms wiring, notification setup, confirmation behavior, and test execution |
| Timely approval on designs, content, and QA feedback | Defined revision rounds, bug fixes within scope, and post-launch handoff notes |
Dependencies list to confirm before work starts:
- Domain registrar or DNS access exists and the right person can approve changes.
- Hosting or server credentials are available if the provider is not hosting directly.
- Brand files, logos, and approved copy owners are identified.
- Decision-makers and approval turnaround windows are named.
- Inboxes for forms, notifications, and support messages are confirmed.
- Any existing URLs that need redirects are documented.
That last one matters more than people expect. A timeline can survive a missing icon. It does not enjoy missing access.
SEO Basics Inside the Package: The “Don’t Launch Blind” Items
This section is deliberately narrow. You are not buying a full SEO strategy here. You are making sure the package includes the SEO basics that prevent launch-day surprises.
- Indexability: Ask whether important pages are set up so search engines can index them. Indexability means a page is allowed to be discovered and stored in search results.
- Title and meta templates: Confirm there is a default structure for titles and meta descriptions on the main page types.
- Sitemap and robots basics: Ask whether a sitemap is available and whether robots settings avoid accidental blocking.
- URL structure decisions: Confirm that key URLs are agreed before build is effectively locked.
- Heading structure expectations: Ask how H1s and page headings are handled in templates so the content is not structurally messy by default.
If the proposal treats all of that as a later add-on, ask whether the launch itself is considered complete without those basics. Usually it should not be.
When the package needs to go beyond brochure-site scope into application logic, workflow complexity, or more bespoke build requirements, a neutral useful resource is this overview of custom web development services. It is relevant when the real issue is that the project is no longer a simple package fit.
Quality Gates: What QA Should Test and What Acceptance Means
QA means quality assurance: the structured testing step before launch. Acceptance criteria means the checklist that decides whether the project or a phase is approved. Without those, “almost done” can last longer than an actual sprint.
| QA area | What should be tested | Example acceptance criteria |
|---|---|---|
| Layout and devices | Major browsers, mobile navigation, content spacing, image behavior | All approved page templates render correctly on current major browsers and mobile devices |
| Forms | Submission, validation, confirmation message, email routing | Each scoped form submits successfully and sends the expected notifications |
| Content rendering | Headings, images, downloads, formatting, links | No broken layouts, missing assets, or obvious content formatting issues on scoped pages |
| Technical basics | Broken links, redirects, sitemap basics, title and meta templates, tracking code | No broken links on scoped pages, tracking is verified, SEO templates are applied |
| Performance basics | Heavy pages, image loading, obvious slowdowns | Priority pages meet the agreed practical performance standard and no major loading issue blocks launch |
Also ask how many approval rounds are included. One common delay pattern is this: the proposal includes “revisions,” but not how many, how feedback is collected, or what happens if feedback arrives late. That is not a tiny detail. That is the project clock.
Hosting and Domain Handoff: Confirm These Before Launch Day
The handoff section is where otherwise competent projects suddenly become very interested in email chains from three months ago. Keep it boring and explicit.
- DNS ownership: Who changes DNS records, and who has the authority to approve it?
- SSL readiness: Who installs or validates the certificate so the live site loads securely?
- Redirects: If there is an older site, who maps old URLs to new ones?
- Email records if needed: Confirm whether the provider touches email-related DNS records or only web hosting items.
- Staging and production: Is there a staging site, and who moves the approved build to production?
- Final launch checklist: What exactly gets checked after the switch: forms, tracking, broken links, preferred URL behavior, and mobile review.
The site’s hosting and domain guidance page is helpful for understanding the infrastructure side, but your proposal still needs the handoff items above in plain language.
Support After Launch: Define the Bug-Fix Window and Change Pricing
After-launch support should answer two questions clearly. First, what counts as a bug? Second, what becomes a paid update?
- Bug-fix window: Ask for the number of days covered after launch and what types of issues are included.
- Included fixes: Broken form behavior, layout regressions, missing assets, or scoped features not matching acceptance criteria are usually bug candidates.
- Billable changes: New pages, new features, content rewrites, extra revision cycles, or added integrations are usually change requests.
- Request process: Ask how support requests are submitted, what response times look like, and whether maintenance plans exist for ongoing updates.
This is also the right moment to avoid mixing channels. Plan advertising after the site is actually launch-ready. If paid traffic is part of the next phase, the online advertising page is a sensible follow-on, but it should not be compensating for unfinished launch work.
12 Questions to Ask in the First Call
- Which pages are unique designs, and which pages use shared templates?
- What content import is included, and who is responsible for formatting or cleaning existing content?
- Which CMS features are included at launch, and what is explicitly out of scope?
- How many forms are included, where do submissions go, and who tests deliverability?
- What basic SEO launch items are included before go-live?
- What does QA cover, and do you have a written test checklist?
- What are the acceptance criteria for design approval, build completion, and launch readiness?
- How many review rounds are included, and what happens if feedback arrives late?
- Who owns DNS, SSL, redirects, and any hosting handoff tasks?
- What assumptions are built into the timeline about content, approvals, and access credentials?
- What is the post-launch bug-fix window, and how are extra changes priced?
- Can you show similar completed work so I can compare package promises with real outcomes?
That last question is where the references and portfolio page becomes useful. You are checking whether the provider’s finished work matches the clarity promised in the proposal.
A Simple Scoring Rubric for Comparing Proposals
Use a 0 to 2 score for each category. 0 means missing or vague. 1 means partly covered but still unclear. 2 means specific, written, and testable.
| Category | What earns a 2 |
|---|---|
| Deliverables clarity | Pages, templates, CMS features, forms, and launch items are listed specifically |
| Timeline realism | Phases, milestones, and dependency assumptions are named clearly |
| Responsibility split | Client inputs and provider outputs are documented without guesswork |
| SEO launch basics | Indexability, templates, sitemap or robots basics, and URL decisions are included |
| QA and acceptance | Testing scope and acceptance criteria are concrete and testable |
| Hosting handoff | DNS, SSL, redirects, staging, and deployment ownership are defined |
| Support terms | Bug-fix window and paid change process are clearly written |
| Proof and fit | Relevant references or comparable examples are available and credible |
How to read the score:
- 13 to 16: Usually a strong, launch-safe proposal with normal follow-up questions.
- 9 to 12: Probably workable, but there are enough gray areas to create launch friction.
- 0 to 8: Too many blanks. Expect scope debates, timeline slips, or post-launch surprises.
Final Check Before You Choose
The best package is rarely the one with the prettiest promise. It is the one that makes launch boring in the best possible way: the pages are named, the phases are realistic, the responsibilities are split, the QA gate is testable, and the hosting handoff is confirmed before anyone touches DNS.
If you want a second pair of eyes on a proposal, use the contact page and send the scope outline or your shortlist of questions. Start with one simple prompt: Which proposal line item is currently missing: content import, QA, or hosting handoff?