Website RFP Spec and Launch Acceptance Checklist

You hand the website project to a vendor. Three months later they deliver. You open it and it is not what you pictured. The mobile layout breaks. You fill in the contact form and nothing arrives. You search your company name on Google and cannot find yourself. You ask for the source code and hear that it was not included in the quote.

Here is the uncomfortable part: most of the time the vendor did nothing wrong. They built exactly what they understood you to want. The gap was never written down, so when the argument starts there is no document to put on the table.

Website projects break at the same two points every time: the requirements were never defined precisely enough, and nobody agreed what "done" looks like. This article does one thing — it gives you two checklists you can copy and use today. One for before you sign, one for before you launch. In between sits a contract-ownership table covering the ten items that most often turn into stranded assets.

A note on scope: this is a process document, not legal advice. Anything touching contract terms, copyright assignment, or liability should go past your own attorney. What we can do is make sure you ask the right questions before the delivery date, not after. If you have not yet set a budget range, start with how to read a website quote and come back.

1. Website projects fail on paperwork, not on craftsmanship

Direct answer: disputes cluster at two moments — defining requirements before signing, and agreeing acceptance criteria at launch. The build phase itself rarely causes trouble. Add one written document at each end and most conflicts disappear before they start.

Why does this happen so reliably? Because a website is a product where both sides can hear the same sentence and picture different things. You say "a professional-looking site" and the vendor hears layout and color. You are picturing "visitors who arrive and want to request a quote." You say "multilingual" meaning two complete content sets; the vendor quotes a language switcher with content supplied by you. In manufacturing this gap does not occur, because the drawing carries dimensions and tolerances. In website procurement nobody draws a drawing.

The specification is the drawing. It does not need to be long and you do not need to be technical. It needs to turn your expected outcome into sentences the other side cannot reinterpret. Two or three pages usually removes eighty percent of the friction.

The second reason is that a large share of a website cost lands after delivery. Domain renewals, hosting, SSL, and backups are recurring line items that industry cost surveys put at roughly 15 to 25 percent of the initial build cost, every year. On a quote these often appear as one line that says "first year included." The second-year invoice is the surprise, and the credentials are still with the vendor. That is not a vendor trick. It is a specification that never said who pays, who manages, and whose name the account sits under.

There is also a structural second-order effect worth naming: a project with no acceptance checklist usually has no closure either. The site goes live because it is "basically done," the final payment sits unpaid, the vendor thinks you are stalling, you think they are not finished, and neither side can articulate what is missing. A line-by-line checklist protects both parties equally: when the boxes are ticked the project is closed, the final invoice is paid without resentment, and anything new is a new engagement. The checklist is not a weapon against the vendor. It is the mechanism that lets everyone stop working.

2. What belongs in the specification: twelve fields, two pages

Direct answer: a workable website specification has twelve fields — objective, audience, site structure, content responsibility, languages, functionality, admin and maintenance, performance and compatibility, SEO basics, AEO requirements, data and integrations, and schedule milestones. Three to five lines each is enough. Length is not the point; converting verbal promises into text is.

Copy the table below into a document and use it as your template. The middle column tells you when a field is specific enough. The right column is what actually happens when it is not.

The twelve-field template

Fields 4, 9, and 10 are the ones small companies omit entirely. Field 4 gets its own section next; 9 and 10 are covered in section four. For everything else there is one drafting trick that matters more than the rest: write each requirement as "after launch I must be able to do X," not as a technology name. You do not need to specify a framework. You need to write "I must be able to publish a new product article from the admin panel in ten minutes without contacting you." The first sentence you cannot defend in an argument. The second one is testable.

3. The field that starts most arguments: who produces the content

Direct answer: most website quotes exclude copywriting, professional photography, and translation, but rarely say so explicitly — this is the number one source of procurement disputes. The specification must name who produces each content type, by when, and with how many revision rounds.

Know the market before you argue about it. Published cost surveys put one-page brochure sites at roughly NT$15,000 to 50,000, company sites at NT$50,000 to 200,000, ecommerce at NT$100,000 to 500,000, and custom systems above NT$200,000; another survey places typical brochure-site builds at NT$45,000 to 120,000, usually including responsive layout and basic SEO setup. Read "usually including" carefully — it covers layout and configuration, not content. Twenty pages of product copy, fifty product photographs, and an English adaptation can easily exceed the build fee on their own. The currency differs by market; the ratio does not.

Six content types, each with a named owner and a date

So field 4 needs this level of granularity:

• Copy: who writes it? If the vendor writes, is that editing your draft or writing from scratch? How much raw material do you supply? How many revision rounds?
• Product and lifestyle photography: supplied by you or shot by them? How many days on site? How many images cut out and retouched?
• Diagrams and spec tables: who converts your existing PDF catalog into web tables?
• Video: who shoots, who edits, hosted externally or on-site?
• Translation: machine translation with human editing, or native-speaker writing? Is the English version a translation, or written for the overseas buyer from scratch?
• Ongoing additions: after launch, who produces the monthly content?

Writing the content yourself is not always cheaper

Time to break a common myth: owners assume writing the content themselves saves money, and then the content never gets finished and the site sits unlaunched for a year. Content is not where you save money; it is where you schedule. If you decide to write it yourself, the specification should say "the client delivers all copy by week X; delays extend the schedule and are not a vendor breach." That sentence protects the vendor and forces you to book the time. The more pragmatic pattern is staged: launch with the material you already have, treat content completion as ongoing post-launch work, and let the site start accumulating data. The zero-to-launch build guide has a fuller schedule for this.

One more second-order effect: when content responsibility is undefined, the vendor is often hurt worse than you are. Their cost structure is person-months. A three-month stall parks a designer and a developer. If you want a long-term relationship with one vendor — which is usually the economical choice, because a website needs feeding — clarity here serves both sides.

4. The section almost nobody writes: SEO basics and AEO requirements

Direct answer: if the specification omits minimum SEO and AEO requirements, you will receive a site that looks polished and that neither search engines nor AI assistants can read — and retrofitting that costs far more than requiring it up front. This is the highest-leverage section of this article, because nine specifications out of ten skip it entirely.

Six minimum SEO requirements

Start with SEO fundamentals. You do not need to ask the vendor to rank you — that is a separate engagement. You need to require that the build does not block you from doing it later. Six requirements, copy them verbatim:

1. Every page has an independently editable title and meta description, not one set shared site-wide. Google documents how title links and snippets are generated; losing edit control means forfeiting that surface.
2. URLs are controllable, semantic, lowercase, hyphenated, with no query-string parameters or sequential IDs.
3. The site generates and updates a sitemap.xml matching Google sitemap guidelines.
4. robots.txt is editable, and at launch you confirm no leftover site-wide block from the staging environment — a perennial launch accident.
5. Every image accepts alt text. Google image best practices treat alt text as a primary signal for understanding an image.
6. Multilingual pages carry correct hreflang annotations per Google guidance on localized versions.

Four AEO requirements

Now AEO. Answer Engine Optimization means making your content readable and citable by ChatGPT, Perplexity, and AI Overviews. It differs from classic SEO in one decisive way: many AI crawlers execute little or no JavaScript. If your site renders entirely on the client, a human sees content and a crawler retrieves an empty shell. Google devotes substantial space in its JavaScript SEO basics documentation to exactly this rendering gap. Four requirements:

1. Primary content must be server-rendered or statically generated — with JavaScript disabled, View Source still shows the text.
2. Emit JSON-LD structured data covering at least Organization, Product or Service, BreadcrumbList, and FAQPage, validating clean in the Rich Results Test and the Schema Markup Validator. The available types are listed in Google structured data gallery.
3. robots.txt must not block AI crawlers unless you have a deliberate reason. Check this explicitly, because some hosts and plugins block them by default.
4. Each page carries one self-contained answer paragraph plus a clear H2/H3 hierarchy.

None of this adds much vendor effort up front. Retrofitting it means rebuilding the front end. The AEO technical implementation guide has step-by-step configuration you can attach to the specification as an appendix.

Performance: use Core Web Vitals as the acceptance standard

For performance thresholds, use Core Web Vitals as the acceptance standard: it is publicly defined, free to measure, and leaves no room for argument. The current good thresholds are LCP within 2.5 seconds, INP within 200 milliseconds, and CLS at or below 0.1, evaluated at the 75th percentile of page loads. Measure with PageSpeed Insights. Writing "the mobile home page and primary product pages must score in the green band in PageSpeed Insights" turns a feeling into a testable clause.

5. Ten things the contract must nail down

Direct answer: the ten items that most often become stranded assets are the domain registrant, hosting accounts, SSL certificate, source code, design source files, third-party licenses, revision counts, warranty scope, maintenance fees and response times, and handover on vendor wind-down. For the domain and the source code, the difference between writing it and not writing it can be the survival of the entire site.

Two legal realities first.

The domain: the registrant is the owner

One: the owner of a domain is the registrant, not whoever registered it for you. ICANN maintains a formal process for Change of Registrant, and it requires the current registrant to cooperate. If the vendor registered the .com under their company name, that domain is legally theirs and you need their consent to move it. Domains are cheap — roughly NT$500 to 800 a year for a .com — but the domain is the address of every marketing asset you own. Clause one of any website contract should read: the domain is registered in the client company name, with credentials delivered within seven days of signing.

The source code: unwritten means not yours

Two: by default you do not own the source code copyright. In the United States, the Copyright Office explains that a work by an independent contractor qualifies as a work made for hire only if it falls within one of nine statutory categories and the parties sign a written agreement saying so — website code is generally not in those nine categories, so ownership passes only through an express written assignment. Taiwan reaches the same place by a different route: Article 12 of the Copyright Act provides that for a commissioned work the commissioned party is the author unless the contract says otherwise, and where economic rights are not addressed, they vest in the commissioned party. Two jurisdictions, one conclusion: unwritten means not yours. Again, background rather than legal advice — have your attorney draft the actual clause.

The ten-item contract ownership map

Walk this table line by line before signing:

Item 10 matters more than it looks. Web studios are small and turnover is high; nobody can promise a three-person shop will exist in three years. The clause is not distrust — it converts an unpleasant possibility into a procedure both sides already agreed to. In practice there is a stronger safeguard than any clause: register the domain, hosting or platform, Google Analytics, and Search Console under your own company email from day one, then add the vendor as a collaborator. If they disappear, you lose nothing.

6. The launch acceptance checklist: twenty-eight boxes

Direct answer: acceptance is not "does it look right" — it is a sequence of repeatable actions, each with a stated pass criterion. Print the table below, sit down with the vendor, tick the boxes together, sign it, and settle the final invoice the same day.

Before you start: three phones, one desktop, one outside network

Before you start, get three different phones (at least one iOS and one Android), a desktop machine, and a network you do not normally use, such as a phone hotspot. Many acceptance failures happen because everything was only ever viewed on the vendor machine and the vendor network. Mobile matters and the numbers are not in dispute: Statista puts mobile devices, excluding tablets, at more than half of global website traffic, around 51.5 percent in the second quarter of 2026, and Google has long used mobile-first indexing, meaning it evaluates your site primarily from the mobile version.

The twenty-eight-item acceptance table

Analytics and search accounts: three things to do yourself

Items 14 through 19 — the analytics and search accounts — are the ones most often waved through verbally. Do three things yourself. First, open the GA4 realtime report, confirm your own session appears, and set the retention window deliberately per Google guidance on GA4 data retention rather than leaving the default; that setting governs how far back you can analyse later, and a wrong value cannot be recovered retroactively. Second, confirm the property is verified per Search Console property verification documentation, and that your company account holds owner permission, not user permission — only an owner can add others and revoke access when you change vendors. Third, open the Sitemaps report, confirm submission succeeded, and compare the discovered URL count against your real page count; a large gap usually means a batch of pages was never included. Fifteen minutes total, and they determine whether you can see your own site performance after launch.

The table looks long; walking it with the vendor takes two to three hours. Do not run acceptance on launch day. Reserve a one-to-two-week pre-launch verification window: park the site on a staging URL with real content, run all twenty-eight checks, then cut the production domain over. The vendor gets time to fix things and you avoid discovering problems while customers are already looking.

SSL certificate lifetimes are shrinking

Item 5 has a change worth knowing about in 2026. The CA/Browser Forum ballot SC-081v3 phases down the maximum lifetime of publicly trusted TLS certificates: from 398 days to 200 days starting March 2026, to 100 days in 2027, and to 47 days by 2029. The implication is simple: manual certificate renewal is on its way to being unworkable. At acceptance, verify not just that a certificate exists but that renewal is automated and that someone owns it. Automated issuance such as Let’s Encrypt or platform-native renewal both work; what matters is that someone can describe the process.

7. Three recurring disputes and how to prevent each one

Direct answer: the three classic website disputes are unbounded revisions, blame for delays caused by late content, and assets you cannot retrieve after delivery. None of them is solved by finding a better vendor. All three are solved by defining terms before signing.

Dispute one: revisions that never end

The classic pattern is three stakeholders sending contradictory feedback in separate emails, with the vendor on version seven and no closer. Three preventive moves. First, name a single point of contact and write that the vendor accepts consolidated written feedback from that person only. Second, define one revision — not one change, but one consolidated round of feedback — and state how many rounds are included (two visual and two content rounds is a common fair number). Third, separate adjustment from addition: changing text, swapping an image, or nudging spacing inside an approved structure is an adjustment; adding pages, adding features, or reversing a signed-off layout is a new requirement and gets quoted. Put those three sentences in the contract and this dispute mostly stops happening.

Dispute two: whose fault is the delay

Nine times out of ten this traces back to content. The prevention is to write the schedule conditionally rather than as fixed dates: "the vendor completes development within 30 working days of receiving all copy and images from the client," not "the project completes on June 30." Then state each milestone deliverable and the consequence of client delay — schedule extension, not vendor breach. The second-order benefit is that it forces you to confront the content workload before signing rather than after. If you are still deciding whether to refresh or rebuild an existing site, work through the redesign versus rebuild decision framework first; writing the specification is much easier once that call is made.

Dispute three: you cannot get your assets back

This is the expensive one, because it usually surfaces exactly when you want to change vendors or the vendor closes shop. Section five covers the contract clauses, but here is the safeguard that works even when the contract is weak: hold four keys yourself — registrar account, hosting or platform account, Google Analytics property, and Search Console property. Create all four under your company email on day one and invite the vendor in as a collaborator. None of this requires technical skill; it requires keeping four passwords. With those four keys, the worst case is rebuilding a website rather than losing your identity on the internet.

One thing that is not a dispute but matters just as much: launch is not the finish line. Three to six months in, run a health check to catch what acceptance could not reveal — the common technical problems self-check and the manufacturer website SEO checklist both work as recurring audits.

8. Putting both checklists on a timeline

Direct answer: the specification is finished before you request quotes, and the acceptance checklist is attached to the contract at signing — neither is a document you write afterwards. Out of order, the checklist loses its force.

A procurement timeline you can copy

The working sequence:

1. Week 0: write the specification. Use the twelve-field table. Any field you cannot fill in is a decision you have not made yet, and making it now is the entire point.
2. Week 1: send the same specification to three vendors. The value is not only price comparison but comprehension comparison: how differently three vendors respond to one document tells you who actually understood the brief. The cost and quote-reading guide covers how to decompose the responses.
3. Weeks 2 to 3: confirm the platform and technical route. Only now decide between a self-hosted CMS, a SaaS site builder, or custom development; the platform comparison lays out the trade-offs. Note the order: requirements first, platform second. Reversing it lets the tool constrain the business.
4. At signing: attach both the specification and the acceptance checklist as contract exhibits. This is the pivotal step. The contract body carries the obligations; the exhibits carry the requirements and the acceptance criteria, and each references the other.
5. One to two weeks before launch: run all twenty-eight checks on staging. Tick each one, screenshot the evidence, and produce a defect list.
6. After the production domain cuts over: rerun items 1 to 6 and 18 to 24. Switching domains affects certificates, redirects, and Search Console configuration — this is where things get lost on the last mile.
7. Thirty days after launch: read the first real data in GA4 and Search Console. Only then do you know whether the site is genuinely indexed and whether anyone is filling in the form.

A closing word of balance. This article contains two checklists, ten contract clauses, and three dispute-prevention patterns, but the goal is not to treat vendors as adversaries. Most web studios are serious small teams whose fears are identical to yours: unclear requirements, endless revisions, and projects that never close. A clear specification and an agreed acceptance checklist read to them as "someone finally said what they want," and to you as "I finally know what I paid for." That is a genuinely mutual win, and the only cost is the two hours you spend before you send the brief.