How to prepare technical specifications for a website so as not to overpay
You have decided to order a website. We found a web studio, discussed the task in words, shook hands – and two months later we received something that has nothing to do with what you had in mind. Sound familiar? This is not the contractor’s malice. This is the lack of normal technical specifications for the site.
Without technical specifications, each side comes up with ideas for the other. You imagine one thing, a designer another, a developer another. As a result, you pay twice: for the first version and for the rework. And sometimes three times – when the rework is also past.
We at web studio 12ia work with business turnkey and we see one pattern: projects with well-developed technical specifications fit into the budget. Projects without specifications are almost never.
Why draw up technical specifications for website development at all
Technical specifications are not bureaucracy. This is insurance. For both sides.
For the customer, the technical specification specifies what exactly he will receive for his money. For the contractor – what exactly is expected of him. When everything is written down, disputes are resolved not by emotions, but by documents.
This is what happens without technical specifications for the site:
- The contractor provides the minimum functionality to meet the budget. You expected more – conflict.
- “Minor edits” turn into full-fledged improvements for some money. Because the contract does not specify what is considered an edit.
- The designer likes the design, but it doesn’t solve your business problem. Because the task was not formulated.
- Deadlines are creeping up. Because the amount of work is a loose concept when there is no specificity.
TK for a web studio is not a limitation, but a frame. The more accurate the frame, the more accurate the result and the less you overpay.
What should be in the terms of reference for the site: mandatory items
Below is a checklist that we recommend to every client. You don’t have to write 50 pages. But each of these points should be at least briefly recorded.
1. Goals and objectives of the site
Not “a beautiful website is needed,” but specifically: why does a business need one? Attract applications? Selling goods? Inform clients? Build trust?
The goal determines everything else – structure, functionality, design. A business card website for a law firm and an online spare parts store are different projects with different budgets — decide which website format to choose before writing a brief, even if both are “on WordPress.”
2. Target audience
Who will use the site. Age, level of Internet proficiency, what devices they are using, what they are looking for, what they should do on the site. If your audience is people 55+ who access from a phone, this affects the size of buttons, fonts and navigation structure. If you don’t register it, you’ll end up with a website that’s convenient for the designer, and not for your clients.
3. Site structure
Перечень всех страниц и их иерархия. Home, catalog, product cards, about the company, contacts, blog – everything that should be on the site. Preferably in the form of a tree or a nested list.
This is the most important point of the terms of reference for website development. It is on this basis that the contractor calculates the amount of work and creates an estimate. Understanding what determines website cost will help you set realistic expectations. Forgot to indicate a section – it will not be included in the assessment, and then it will become “additional work” for additional money.
4. Functional requirements
What the site should be able to do. For each page:
- Feedback forms – what fields, where applications are sent
- Calculators, configurators, catalog filters
- Personal account, registration, authorization
- Cart, payment, delivery methods
- Multilingual
- Site search
- Chatbot, online consultant
Each feature represents hours of developer work. If it is not recorded in the technical specifications, the contractor will either not do it or will issue an invoice from above.
5. Design requirements
References – sites that you like. Not necessarily from your niche. Show what you like in terms of style, color scheme, and presentation of content. If you have a brand book or corporate identity, please attach it.
Without references, the designer will guess. And guessing means 3-5 iterations of edits, which eat up time and budget.
6. Content
Who prepares texts, photographs, videos? If the content is provided by the customer, within what time frame and in what format? If the texts are written by a contractor – how many pages, what volume, is SEO copywriting needed?
Half of project delays are due to content. The site is ready, but there are no texts. Or there are texts, but in the format “Word document with photos inserted directly into the text.” Write this down in the technical specifications in advance.
7. Integrations
CRM, 1C, payment systems, delivery services, email newsletters, analytics, social networks. Each integration is a separate task. Some integrations cost more than the website itself. If you plan to link your site with AmoCRM and 1C, you need to know this at the evaluation stage, and not after signing the contract.
8. SEO requirements
Basic minimum: meta tags, sitemap.xml, robots.txt, CNC (human-readable URLs), adaptive layout, loading speed. If you need advanced SEO optimization – semantic core, heading structure, micro markup – record it separately.
9. Technical requirements
CMS or framework, hosting, SSL certificate, loading speed requirements, browser support, adaptability. If it is important to you that the site works in Internet Explorer, say so right away. The contractor will tell you how much it costs, and you may change your mind.
10. Deadlines and stages of delivery
Not “a website in two months,” but specific stages: prototype – design – layout – programming – testing – launch. With dates. With acceptance criteria at each stage. This way you see progress and can correct course in time, rather than discovering a problem on the day of delivery.
Typical mistakes when drawing up technical specifications
Even when the customer writes technical specifications, he often makes the same mistakes:
- Too general statements. “Modern design” is not a requirement. “Minimalistic style, like site X, with accent color #2B5F8A” is a requirement.
- Result requirements instead of product requirements. “The site should bring in 100 applications per month” is a marketing KPI, not a TK item. The web studio makes a tool, but does not guarantee traffic.
- Lack of priorities. If the technical specification contains 80 points and all are “mandatory”, the contractor will not be able to meet the budget. Divide into “must have” and “nice to have.”
- Copying someone else’s technical specifications. Templates from the Internet are a good starting point. But the technical specification for your website should describe your business, your audience and your tasks.
Who should draw up the technical specifications
Ideally, together. The customer knows his business. The contractor knows how to translate business objectives into technical requirements. Knowing how to choose a web developer helps you find the right partner for this process. The best technical specifications are born in dialogue.
If a web studio offers to draw up technical specifications for a website together with you and takes money for it, that’s normal. Development of technical specifications takes hours of a qualified specialist. But then the project goes according to plan, and not according to the “we’ll figure it out as we go” principle.
We at web studio 12ia start each project with a brief session and development of technical specifications – this is included in the development process and saves both parties time and money.
Instead of output
The terms of reference do not guarantee that the project will go perfectly. But the lack of technical specifications almost guarantees that something will go wrong. The more precisely you formulate what you want, the closer the result will be to your expectations.
And also the technical specification is a check of the contractor. If the studio does not ask clarifying questions about your technical specification, does not offer improvements and does not point out contradictions, you should think about how deeply they delve into the project.
Try to go through the checklist above and sketch out the technical specifications for your future website. You will most likely have questions. And this is good – it means the process has begun.