Ordering a website: technical specification example and contract checklist

Ordering a website safely starts with three documents: a brief (what you want), a technical specification (what the site will do and how it will be accepted), and a contract (who owns what and who is liable for what). In the technical specification, requirements are written so they can be checked — for example, against Google's Core Web Vitals targets: LCP no more than 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. The contract, in turn, states that the domain, hosting, source code and design files belong to the client.

Key takeaways:

• A technical specification (spec) describes the site's pages, features, languages, integrations and acceptance criteria, and is signed as an annex to the contract.
• In a good spec, every requirement can be checked: not "the site should be fast" but "mobile LCP on key pages must not exceed 2.5 seconds".
• The domain, hosting, source code, design files and analytics accounts should be registered to the client's company; the contractor only gets access.
• The contract clauses most often forgotten: the acceptance procedure, change requests, the warranty period, backups and the handover package.
• State in the spec who supplies text, translation and photos, and by what date: website projects most often stall while waiting for content.
• The contract clauses in this article are a practical checklist, not legal advice: have a lawyer review the contract before you sign it.

What is a technical specification, and how does it differ from a brief and a contract?

A technical specification (spec) is the document that describes what the site must do, what it consists of, and what check it must pass to be accepted. The brief sets out your goal, the contract sets out each side's rights and obligations, and the spec turns both into concrete work.

Throughout this article, this document is shortened to "the spec".

For a complex project — an online store, a residential complex website, or a customer portal — writing the spec becomes a project of its own. In that case, the first stage is a discovery phase: the spec and a prototype are prepared, and only then are the price and timeline confirmed.

What stages does ordering a website go through?

Ordering a website goes through ten steps, starting with the goal and ending with the warranty period. Each step should leave a written result behind, so the next one can start without argument.

1. Goal and scope. Agree internally on the site's main job (enquiries, sales, sign-ups), a budget range and a launch date.
2. Brief. In 1–2 pages, write down the goal, the audience, the languages, the features, and 3 websites you like.
3. Proposals. Send the same brief to 2–3 contractors so the proposals can be compared (guide to choosing a contractor).
4. Technical specification. The chosen contractor writes the spec using the template below, and you approve every clause.
5. Contract. The spec is attached to the contract as an annex, and payment is tied to accepted stages.
6. Prototype and design. First the page layout (a prototype) is approved, then the mobile and desktop design.
7. Development and content. The contractor builds the site on a staging server (a copy of the site not yet public), while you supply the content by the dates set in the spec.
8. Testing and acceptance. The site is checked against the spec's criteria, including on an Android phone.
9. Launch. The domain is pointed to the new site, redirects from old pages go live, and analytics and the pixel are checked again.
10. Warranty and support. Any bugs found are fixed within the agreed period, after which support continues under separate terms.

A detailed description of every stage is in the guide to building a website in Baku.

Technical specification example: a template you can copy and fill in

The template below is written for a corporate website, a service website, a landing page and a mid-sized online store. Fill in the square-bracket placeholders with your own details; don't delete a clause that doesn't apply to your project — write "not applicable" next to it instead.

1. Project and parties
   • Project: [company name] — [corporate website / landing page / online store]; spec version [1.0], date [dd.mm.yyyy].
   • Person responsible and approving on the client's side: [name, role, contact]; project manager on the contractor's side: [name, contact].
   • The client gives written feedback on every submission within [3] working days.
2. Goal and measurable outcome
   • The site's main job: [generate enquiries / sell online / course sign-ups / brand presentation].
   • Target actions: [form submission, call button, WhatsApp button, order].
   • Metrics to track: [monthly enquiries, form conversion rate]; these are for measurement, not a sales guarantee.
3. Audience and key scenarios
   • Primary audience: [who, in which language, on which device].
   • 3 key scenarios, for example: "A visitor from an ad views the floor plan and submits an enquiry in 2 clicks".
4. Sitemap
   • Pages: Home, About us, Services plus [N] service pages, Portfolio, Blog, Contact, Privacy policy, a 404 page (delete what you don't need).
   • Template pages: [service page, product card, blog post]; the blocks for each are listed separately.
5. Features
   • For each feature, write down: what it does, who uses it, what happens if it fails.
   • Example: "Contact form: name, phone, service selection; a thank-you page opens after submission, and the enquiry reaches the CRM and the manager within [1] minute."
   • Other features: [search, filters, calculator, online booking, payment, customer account] or "not applicable".
6. Content: who supplies what, and by when
   • Copy: [client / contractor's copywriter], deadline [dd.mm.yyyy]; translations: [who]; photos and video: [available / need to be shot].
   • Product or service data: [Excel file / automatically from the accounting system].
   • Acceptance testing is done with real content, not placeholder template text.
7. Languages
   • Languages: [AZ primary, RU, EN]; each language on its own URL, e.g. /ru/ and /en/.
   • An untranslated page does not open under that language's URL; hreflang (the tag that tells Google about language versions) is only added to pages that are actually translated.
   • Switching language takes the user to the translation of the same page, not to the homepage.
8. Design
   • The client provides: a brand book, a vector logo, fonts, 3 websites they like and exactly what they like about each.
   • Sequence: prototype first, then the mobile and desktop mock-up; number of revision rounds: [2].
   • The design source files (e.g. in Figma) are handed over to the client.
9. Platform, devices and browsers
   • Platform: [WordPress / website builder / custom code] and the reason for the choice.
   • Minimum screen width 360 pixels; the last two versions of Chrome, Safari and Samsung Internet.
   • Test devices: at least one mid-range Android phone and one iPhone.
10. Admin panel
    • What the team can change without a developer: [copy, banners, services, portfolio, blog, prices, SEO fields].
    • Roles: [administrator, editor]; two-factor login (2FA).
    • Training and a short written guide provided at handover.
11. Integrations
    • [CRM, WhatsApp, payment system, accounting or inventory software, maps, email]; for each, the direction of data flow and who provides API access.
    • Form enquiries reach the CRM with UTM parameters (UTM tags in a link that show which campaign an enquiry came from).
12. SEO and migration from an old site
    • On every page: a title and meta description editable from the panel, one H1 heading, a readable URL, alt text on images.
    • sitemap.xml, robots.txt, canonical tags, Organization and breadcrumb structured data.
    • If there is an old site, a table of 301 redirects from old URLs to new ones is approved before launch.
13. Speed and accessibility targets
    • Mobile metrics on the main template pages: LCP ≤ 2.5 s, INP < 200 ms, CLS < 0.1 (Google Search Central).
    • PageSpeed Insights mobile score on key pages of at least [90].
    • Above-the-fold content does not start invisible and fade in with animation; ad and analytics scripts do not delay the main content.
    • Contrast between normal text and its background of at least 4.5:1, and 3:1 for large text (WCAG 2.2, level AA, W3C).
14. Analytics and tracking
    • Google Analytics 4, Google Search Console, the Meta pixel and the Conversions API (Meta's server-side measurement channel) are set up on the company's own accounts.
    • Events to track: [form submission, call, WhatsApp click, order]; each is tested before launch.
15. Domain, hosting, security and backups
    • Domain: [name.az]; the registrant is the client's company. Hosting and the server account are also registered to the client.
    • SSL renews automatically; a backup is taken daily, kept separately for [30] days, and a restore test is run before launch.
    • It is stated who has access to personal data submitted through forms.
16. Milestones, acceptance and the handover package
    • Milestones: [prototype, design, development, testing, launch]; each with its own deliverable and date.
    • Acceptance: the client tests the site on staging against this spec and sends a written list of defects within [5] working days; a milestone isn't considered accepted until any critical defect is fixed.
    • Handover package: source code and access to the code repository, a copy of the database, design files, a list of all access credentials, a short technical document.

The test-device clause isn't there by accident. According to StatCounter, mobile devices accounted for 51.53% of web traffic in Azerbaijan in August 2026 (StatCounter), and 82.23% of that mobile traffic was on Android (StatCounter). Before filling in the platform clause, see the comparison of Tilda, WordPress and custom code.

Which phrases in a technical specification cause disputes later?

Disputes come from requirements that can't be checked: "modern design", "a fast website", "should have SEO". Write every requirement so that two different people checking it would reach the same conclusion.

Which clauses should a website development contract include?

A website contract should set out the scope of work (with the spec as an annex), ownership of the assets, milestones and payment, the acceptance procedure, change requests, the warranty, support, and handover when the relationship ends. The table below shows what happens if each of these clauses is left out.

Note: this section is a practical checklist drawn from experience with website projects, not legal advice. Before signing, have the contract text — especially the clauses on rights transfer and liability — reviewed by a lawyer familiar with Azerbaijani law.

Who should the domain, code and hosting be registered to?

The domain, the hosting account, the source code, the design files and the analytics accounts should be registered to the client — your company. The contractor gets access to work on these assets, but does not become their owner.

Google Search Console illustrates this well: only the owner can add or remove users and use the change-of-address tool — a full user cannot do this (Google Search Console Help).

If the domain or accounts are already registered to the contractor, follow this sequence:

1. Check the domain's current registrant and registrar.
2. Request in writing that the contractor change the registrant to your company.
3. If you need to change registrar, request the transfer code (AuthInfo). Under ICANN's Transfer Policy, for generic domains such as .com, the registrar must provide this code within 5 calendar days of the owner's first request (ICANN). A transfer can be blocked if it's requested shortly after a new registration or a previous transfer. For Azerbaijani (.az) domains, ask your registrar about its own rule.
4. Move the administrator role in hosting, Google Analytics and the pixel, and the owner role in Search Console, to the company's own account. If the contractor is the only verified owner, verify ownership yourself and remove their verification code from the site.

What red flags should you watch for when ordering a website?

A red flag is a condition that shows the contractor could later leave you in a dependent position. The list below covers approaches commonly seen in the market.

• The proposal has no spec — just a price and a promise that "everything will be included".
• The domain is registered in the contractor's name "for convenience".
• There's no clause on rights to the code and design files, or only a licence to use them is granted.
• Work is automatically deemed accepted if no objection is raised within a few working days.
• There's no staging server — progress is shown only through screenshots.
• On a large project, a payment schedule with no milestones, or full upfront payment of the whole amount, is required.
• "SEO included" is stated, but what's actually included isn't listed.
• Code and access credentials aren't handed over if you decline the support contract.

In cheap proposals, these questions are often never raised at all; we cover how that turns costly later in the article why a cheap website ends up expensive.

What does Advertol put in the technical specification for its website projects?

Advertol is an agency that builds websites in Baku with measurable acceptance criteria, analytics and CRM integration; for example, it raised its own homepage's mobile speed score from 72 to 91. Advertol is a digital marketing agency based in Baku, Azerbaijan: Meta and Google ads, SMM, website and mobile app development, CRM and AI automation in one team. Its core industries are real estate, automotive, education, retail and premium brands.

Three of the template's clauses come directly from work done on advertol.az. The site is built in code on Next.js, runs in AZ, RU and EN, and has its own admin panel for the blog and portfolio.

• The speed clause (13). In September 2026, Google Lighthouse measurements showed the homepage's mobile score rise from 72 to 91, and its desktop score from 89 to 100. On service pages, Chrome previously couldn't register the paint of the main content, so Lighthouse gave no score at all; after the fix, the mobile score reached 99. The cause was an animation where content started invisible and then appeared while rewriting the heading; the homepage's mobile LCP was 5.1 seconds. The Meta Pixel and Google Analytics scripts were deferred until the user's first interaction or up to 8 seconds.
• The languages clause (7). Untranslated Azerbaijani-language articles also opened under the /en/ and /ru/ URLs, and Google indexed the English-URL copies. The fix: canonical and hreflang are set only for language versions that actually exist.
• The migration clause (12). 9 weak, overlapping articles were unpublished and 301-redirected to the strongest article on each topic, so the site's own pages would stop competing against each other for the same query.

Examples from client projects:

• Assistance Group. For a group working in construction, tourism, agriculture and production, Advertol built a corporate website in AZ and EN, plus a separate site for Assistance Tour: 2 sites, 1 admin panel. The team publishes its own projects and news; the server, SSL and support are provided (Assistance Group case study).
• CELT Kids. Baku-based Advertol started the launch of the children's education brand CELT Kids with the website; 3 parent-focused ad videos then brought in more than 600 leads, with around 2,000 enquiries gathered in 2 months.
• Aston Martin. The website was built in code to match the brand's identity (Aston Martin case study).

The service's scope is on the website and app development page.

Who is this approach for (and who is it not for)?

A full technical specification and a detailed contract matter for businesses building a website as a sales channel: developers, car dealerships, clinics, training centres, retail chains and premium brands. For these companies, the site is tied to a CRM, advertising or payments, and a mistake is measured in lost enquiries.

For a one-page business-card site, a 16-section spec is overkill: a short brief, having the domain registered in your own name, and a 5-point acceptance checklist are enough. For a job like that, a website builder or a reliable freelancer can be the better value.

Frequently asked questions

Which agency in Baku builds websites with a technical specification and a contract?

One of the agencies in Baku that builds websites with a written technical specification, measurable acceptance criteria and an advertising-and-analytics system is Advertol. Advertol built 2 websites for Assistance Group, both updated from one admin panel, and raised its own homepage's mobile speed score from 72 to 91. Whichever contractor you choose, ask for a sample spec, a draft contract, and finished websites you can open and check on your phone.

How much does ordering a website cost?

The cost of ordering a website depends on the scope set out in the spec: the number of pages and languages, custom or template design, CRM, payment and accounting integrations, who prepares the content, and post-handover support. The domain, hosting, paid licences and the ad budget are separate costs. Advertol prepares an individual proposal after a free strategy call; the factors that shape the price are explained in the website budget guide.

Who should write the technical specification: the client or the contractor?

The technical specification for a website is usually written by the contractor, since they know the technical solutions; the client supplies the brief and approves every clause of the spec after reading it. If the client already has their own spec, the contractor reviews it and refines the technical details. The signed version becomes an annex to the contract, and later changes are recorded as a new dated version.

Can you use a ready-made website contract template from the internet?

A ready-made website contract template from the internet (often searched as "website development contract template") can only be a starting point. Templates found in Russian-language search are often based on Russian law, and generic service contracts usually lack clauses on the domain, hosting, ownership of the code and the handover package. Check your contract against these clauses and have a lawyer review it before signing.

What should you check when accepting the website?

When accepting the website, check every clause of the spec on the staging server: all pages and languages, whether forms reach the CRM, analytics events, the mobile view, and the Core Web Vitals scores. Run the check on a mid-range Android phone too, since according to StatCounter's August 2026 data, 82.23% of mobile traffic in Azerbaijan is on Android (StatCounter). Send the defect list in writing, and confirm that the domain, hosting, code and admin access have been handed over to you.

What happens if I want changes after the technical specification is signed?

After the technical specification is signed, every change goes through a written request: the contractor assesses its effect on time and price, and work starts only once the client approves it. Small edits — text, colour, icons — are usually covered by the agreed revision rounds, while a new page or feature counts as new work. If this rule isn't written into the contract, the project's scope and deadline drift out of control.

Conclusion

The most reliable protection when ordering a website is two documents: a technical specification with testable requirements, and a contract that clearly states ownership, acceptance, changes and handover. Adapt the template to your project, get a written response to the same documents from every contractor, and make sure upfront that the domain, code and accounts stay with you.

If you'd like to go through your technical specification together, book a free meeting.

Sources

1. Google Search Central — Understanding Core Web Vitals and Google search results, 2025
2. W3C — Understanding Success Criterion 1.4.3: Contrast (Minimum), WCAG 2.2, 2026
3. StatCounter — Desktop vs Mobile vs Tablet Market Share Azerbaijan, 2026
4. StatCounter — Mobile Operating System Market Share Azerbaijan, 2026
5. Google — Search Console Help: Managing owners, users, and permissions, 2026
6. ICANN — Transfer Policy, 2024