What project specifications are actually for
Project specifications are not an administrative document intended to obtain three comparable quotes. It is the tool that transforms a vague intention into an executable project, and it serves the writer as much as the recipient.
On the company side, the exercise forces decisions on questions that, if left open, will resurface at the worst possible moment. Who approves. Who provides the copy. What happens if content arrives six weeks late. These trade-offs cost half a day of reflection upfront and several weeks of drift when they are evaded.
On the provider side, precise specifications allow for accurate pricing. A vague brief produces either a quote inflated by a margin of uncertainty or a low quote followed by a series of amendments. In both cases, the client pays for the imprecision—simply at different times.
Useful project specifications should be between eight and fifteen pages. Beyond that, it becomes a document that no one reads and loses its contractual function. Below five, it leaves too many gray areas to serve as a reference in case of disagreement.
The document does not need to be written by a technician. It must describe what the company wants to achieve, not how to build it. A client who imposes a technology in their specifications deprives themselves of the advice they are seeking, and sometimes ends up with an unsuitable solution that the provider executed to the letter.
The twelve sections of complete project specifications
The template below covers both showcase websites and online stores. Not all sections carry the same weight, but none can be removed without creating a zone of uncertainty.
- Company presentation. Activity, market, typical clientele, price positioning, identified competitors. Things the provider cannot guess.
- Project objectives. Formulated as expected results, not features. “Receive qualified quote requests” rather than “have a form.”
- Targets. Who visits the site, with what level of knowledge of the subject, from which device, at what point in the buying journey.
- Functional scope. The list of expected functions, sorted into indispensable, desirable, and out of scope. This last column is the most useful.
- Provisional sitemap. The list of pages and their hierarchy. It will evolve, but it sets the order of magnitude.
- Content. Who provides the text, photos, and videos. By what date. What already exists and what remains to be produced.
- Visual identity. Existing or to-be-created brand guidelines, mandatory elements, liked and rejected reference sites, with reasons.
- Technical constraints. Mandatory hosting, tools to connect, business software, industry regulatory constraints.
- Performance and accessibility requirements. Quantified and verifiable thresholds rather than “the site must be fast.”
- SEO. Targeted queries, geographic areas, languages, existence of a site to be migrated.
- Schedule and milestones. Desired go-live date, calendar constraints, approval deadlines on the client side.
- Budget and terms. Budget or range, payment schedule, what is included after delivery.
Two sections deserve special development because they are almost always botched and are where most disputes are concentrated.
The functional scope and its “out of scope” column
Listing what the site will do is natural. Listing what it will not do is much less so, yet it is what protects both parties. Writing in black and white that the client area, multilingual support, or connection to management software are not part of the first version avoids the painful conversation in the third month.
Sorting into three levels works better than a flat list. The indispensable determines the go-live. The desirable is handled if the budget allows and is quoted separately. The out-of-scope is explicitly postponed. This hierarchy allows for trade-offs during the project without renegotiating the whole thing.
Content, the primary factor for delays
On projects that spiral, the cause is rarely technical. It is almost always editorial: the texts are not ready. A company systematically underestimates the time required to write twenty pages because this task falls to people who already have full-time jobs.
The specifications must therefore name a content manager, set a delivery date per batch, and specify what happens in case of delay. Two options exist: the provider delivers with temporary content and bills for a later intervention, or the project is suspended and the schedule shifted. Choosing upfront avoids debating it under tension.
Visual identity described by examples rather than adjectives
“Modern,” “clean,” “professional” convey no actionable information. These words mean opposite things to different people, and a provider who receives them designs what they like, which guarantees two rounds of unproductive corrections.
The method that works consists of citing three liked sites and three rejected sites, explaining why in one sentence. “I like the sobriety of this one but the photos are too cold” conveys more information than ten adjectives. The cited sites do not need to be in the same sector; they serve as aesthetic benchmarks rather than models to copy.
You must also specify what is mandatory: existing logo, brand colors, licensed typography, print guidelines to follow. A project where the logo must be redone midway changes in nature, and this possibility deserves to be opened from the start if the brand is old.
What to quantify rather than describe
The difference between vague specifications and useful specifications often lies in replacing adjectives with numbers.
“The site must be fast” means nothing and cannot be verified. “The site must achieve a Lighthouse score higher than 90 on desktop and 85 on mobile, and pass the three Core Web Vitals thresholds on main templates” is measured on the day of acceptance testing. This is the commitment we make on our deliveries, and it only has value because it is verifiable.
The same reasoning applies to the rest. A maximum response time for modification requests. A number of correction cycles included for mockups, generally two. A warranty period after go-live. A volume of training for handover. Each of these lines avoids a discussion.
The SEO component, the one everyone forgets
Specifications that treat SEO in one line produce a site that will have to be redone. Three elements must appear there, and they determine structural choices that are impossible to fix after the fact.
Sitemap and targeted queries
URL structure, page depth, and subject distribution are decided before the first mockup. A site designed around the company’s organizational chart rather than its customers’ search intent starts with a handicap that no subsequent optimization can fully overcome.
The specifications must therefore list the main targeted queries and indicate which page handles them. This is the starting point for the architecture described in our article on the semantic silo—organizing pages into thematic clusters—and doing it at this stage costs a few hours versus several days of rework later.
Migration, if a site already exists
Redesigning a site with a history requires a redirection plan. Each URL from the old site must be redirected to its closest equivalent, otherwise the new site starts from zero in terms of authority. This task must appear in the specifications with an identified owner, because it is regularly forgotten and then discovered three weeks after go-live, when traffic has collapsed.
The document must also specify who provides the list of existing URLs and who verifies the redirections after the switch. This is one of the points we systematically handle in a website redesign, and one of the few where an error produces an immediate and measurable loss.
Local SEO, when the area matters
A company whose clientele is geographic must state this in its specifications, because it changes the sitemap, markup, and expected content. Location pages, business profile declarations, and review strategies are prepared from the design phase, as detailed in our local SEO guide.
Legal obligations and accessibility
A professional site carries obligations that the specifications must name, because they translate into real work. Legal notices, privacy policy, general terms and conditions if the site sells, cookie consent management compliant with European regulations, and a processing register if personal data is collected.
The consent banner deserves special attention. A botched implementation blocks measurement tools or, conversely, drops trackers before acceptance, exposing the company. It also degrades CLS and therefore measured performance, making it both a legal and technical issue.
Accessibility is becoming a greater regulatory obligation depending on company size and sector. Even outside any legal constraints, respecting minimum contrasts, keyboard navigation, and alt text improves the experience for all visitors and is much easier to handle during design than as a fix.
The six pitfalls that derail a project
Nine years of projects consistently reveal the same causes of drift. None are technical.
Undefined validation circuit
When no one formally has the final word, every mockup comes back with the contradictory opinions of four people. The provider arbitrates blindly, the client is satisfied with nothing, and the project bogs down. Naming a single decision-maker, even if they consult others, solves this problem on its own.
Scope that expands silently
Each request taken in isolation seems minimal. Added up, twenty minimal requests represent an unplanned week of work. The solution is not to refuse changes, but to track them: every out-of-scope request is quantified and approved before execution, even when it is offered for free.
Confusion between personal taste and effectiveness
“I don’t like blue” is a legitimate opinion. “Our customers won’t click on this button” is a verifiable hypothesis. Specifications that express measurable objectives allow mockup discussions to be brought back to the ground of effectiveness rather than preference.
Absence of formal acceptance testing
Without a final validation procedure, the project never truly ends. Written acceptance testing, listing the points to check and the acceptance criteria, marks the end of the production phase and the start of the warranty. Without it, the boundary between bug fixing and paid evolution remains blurred for both sides.
The question of ownership evaded
Who owns the code, the mockups, the domain name, the hosting, and the analytics accounts. The answer must be in writing. A client who discovers after two years that their domain name is registered in their former provider’s name also discovers their provider’s bargaining power.
Access not gathered at the start
Domain name, hosting, email, measurement accounts, social networks, review platforms: a project starts needing six to ten access points, and at least two are always missing. The holder is sometimes a former employee, sometimes a previous provider with whom the relationship ended badly.
Recovering lost access takes between two days and three weeks depending on the service, and this search almost always starts at the worst moment—the day before go-live. An appendix to the specifications listing each access, its holder, and its availability status avoids this blockage. It’s one page to fill out that saves a week.
The post-launch phase forgotten
A site is not finished on the day of delivery. Updates, backups, monitoring, fixes: these tasks exist, someone must perform them, and they have a cost. The specifications must state if they are included, for how long, and exactly what a potential maintenance contract covers.
What the specifications should say about the schedule
A desired go-live date is not enough. What actually structures the calendar are the client-side validation deadlines, which are almost always underestimated.
A showcase website project takes three to five weeks of actual work on the agency side. Yet it frequently stretches over three months because between each step is a validation phase that depends on the availability of a busy executive. A mockup sent on a Friday and approved ten days later, repeated four times, adds six weeks to the calendar without any work having progressed.
The specifications must therefore commit the client as much as the provider: a maximum turnaround time for each deliverable, usually five business days, and the consequence of a delay. Most contracts provide for a schedule shift proportional to the delay, which is fair and, above all, a deterrent.
Real calendar constraints deserve to be named: trade shows, business seasonality, end of a hosting contract, product launch. An arbitrary date mobilizes resources unnecessarily; a justified date allows work to be organized around it. A tourism site that must be online before the season does not have the same margin as an institutional site with no deadline.
Specifications and budget: how to coordinate them
Two schools of thought clash. Announce your budget in the specifications, or keep it to compare proposals. The second is intuitive; the first is more effective.
A provider who knows the budget can propose the best solution at that price point, arbitrate between functions, and frankly signal if the requested scope is out of reach. A provider who doesn’t know it guesses, and the client compares offers that don’t cover the same scope, making the comparison useless.
Announcing a range rather than an exact figure preserves negotiating room while framing the response. To get an idea of the order of magnitude before writing, our website price simulator gives an estimate in a few minutes, and the article on how much a website costs in 2026 details what each item covers.
A final point on comparing quotes. Price alone says nothing until the scope is identical. A two-thousand-euro quote that excludes writing, photos, migration, and maintenance is more expensive than a three-thousand-five-hundred-euro quote that includes them. Comparing requires bringing each proposal to the same scope, an exercise that project specifications make possible.
The specificities of online store projects
An e-commerce site adds a layer of complexity that the specifications must anticipate, otherwise the initial quote will be exceeded by half.
The catalog first. How many references, how many variants per reference, where do product sheets and images come from, is there an exportable file from the management software. Manually re-entering eight hundred products represents several weeks of data entry—a line that never appears in development quotes.
Then the business rules. Shipping costs by zone and weight, free shipping thresholds, quantity discounts, promo codes, tax management according to the delivery country. Each of these rules is simple in isolation, but their combination represents the bulk of the configuration workload.
Finally, the connections. Payment solution, carriers, inventory management software, accounting tool, review platform. Each connection assumes a technical interface is available and documented on the third-party service side, which is not always the case. The specifications must list these tools by name, not by function, and specify who provides access. These trade-offs also determine the choice of platform, a subject we cover in e-commerce site creation.
A directly reusable template
The document can be built in any word processor. Its form matters little; its structure counts.
Start with a context page: who you are, what you sell, to whom. Follow with an objectives page formulated as results, with an indicator per objective if possible. Then devote two to three pages to the functional scope in three columns: indispensable, desirable, excluded.
Reserve one page for the sitemap, in the form of an indented list rather than a diagram. One page for content, with the table of responsibilities and dates. One page for visual identity, citing three liked sites and three rejected sites, with an explanatory sentence for each: this section is worth more than ten adjectives.
Finish with technical constraints, quantified requirements, the SEO component, the schedule, and the budget. Add an appendix listing existing access points and their holders; it will save you a week at the start.
A word of advice on distribution. Sending the same document to five providers is legitimate, but read the questions they ask in return. One who responds with a quote without asking any questions probably hasn’t read the document or has no intention of discussing the scope. The questions a provider asks say more about their level than their brochure. You can judge ours by browsing our portfolio.
A final word on what the document becomes after signing. Too many specifications disappear into a folder the day the project starts, even though they constitute the common reference in case of disagreement. Keeping it open, annotating it at each trade-off, and evolving it through amendments rather than email preserves its value until final acceptance.
Key Takeaways
Project specifications serve to decide before spending. The questions they ask—validation circuit, content manager, excluded scope, ownership of deliverables—are exactly those that derail projects when they remain open.
Three sections make the difference between a useful document and a formal one. The scope with its exclusion column, which protects both parties. The content with its schedule and manager, because that is where delays are born. The quantified requirements, because a commitment that cannot be measured cannot be enforced.
The rest can be written in a few hours and read in twenty minutes. It is not a heavy investment; it is the only time in the project where correcting an error costs nothing.
