What a website spec is and whether a small business needs one

The word "spec" sounds imposing and scares both sides equally. The client pictures being forced to write a document many pages long. The contractor suspects that without a document they will be buried in revisions later. Both fears are fair, but neither is solved by the document people usually have in mind.

What is a website spec?

A website spec, or technical specification, is a document that describes exactly what has to be built: the site structure, the list of pages, the functions, how forms behave, the requirements for content and for the technical side.

The classic spec comes from large projects, where there are many people doing the work, several levels of approval and a high cost of error. There the document is mandatory: it is the only way to hold a shared understanding in place.

A small project works differently. One client, one contractor, a conversation that runs directly between them. And the document that saves time inside a corporation often eats it here.

Does a small business need a spec?

In its classic form - usually not, and here is why.

Writing a full spec drains the effort of both sides and demands decisions from the client that cannot be made in advance: they do not know what the second section will look like or how many fields the form needs. The result is a document written as a formality, or written by the contractor for money and changed anyway.

The second reason: a spec goes stale at the first change. As soon as you look at the first mockup and realise you want something else, the document stops describing the project.

But the conclusion that "nothing needs to be fixed in writing, then" is wrong, and it costs more than either alternative.

What has to be fixed in writing in any case?

Not a spec, but the scope. The minimum set you cannot start without:

The list of pages or blocks, by name. Not "a company website", but an actual list.

The key functions - forms, a catalog, filters, a client portal, language versions. Each one named separately.

Who supplies the content - texts, photographs, the logo. This is the most common reason a launch slips.

What counts as a revision and what counts as a new task.

The price and the payment terms.

What is handed over at the end - access, source files, instructions.

That is enough for the vast majority of small-business projects, and it fits into a short document rather than a multipage spec.

How is a brief different from a spec?

A brief answers the question "why", a spec answers the question "how".

The brief is filled in by the client, and it is short questions about the business: what you do, who your clients are, what a person should do on the site, which examples you like, which you do not. Its point is to hand over context, not to design the solution.

The spec is written afterwards and describes the implementation. In a small project the role of the spec is usually played by a brief plus a scope fixed in the proposal, and that is enough.

That is exactly how I work: a short brief from the client, then a proposal listing what is included. How the process works as a whole: How to Create a Business Website: Where to Start.

Who should write the spec - you or the contractor?

If it really is needed, the contractor should write it and the client should approve it.

The reason is simple: the client knows the business, the contractor knows how it gets built. A document written by a client with no development experience usually describes the wrong things: too much detail on the obvious and nothing at all on what matters.

The normal pattern: you describe the task, the contractor states what they will do, you check that you were understood. If all you get back for a described task is a price with no list of work, that is a reason to be wary, and not the only one: How to Choose a Web Developer and Not Get Burned.

A separate case is a spec written as a paid service before development. That is justified in complex projects with integrations, but for a landing page or a standard services site it is usually excessive.

What if you do not know what you want?

That is a normal state, and it does not stop you from starting.

A client can rarely describe a design in words. But they can almost always point: these sites I like, these I do not, this part is clear, this one is overloaded. References work better than descriptions.

So the visual direction is better agreed before the full build, on a pair of examples and the hero screen, rather than described in a document in advance. Turning around on references costs nothing, turning around on a finished site is expensive.

What you do need to know in advance is not the design but the task: what a person should do on the site and where they will arrive from.

How does a fixed scope protect you from disputes over revisions?

A dispute over revisions always comes from one thing: the sides understand differently where the agreed work ends.

The client thinks that "change the block" is a revision. The contractor thinks that rebuilding the structure of a page is new work. Both are right within their own frame, because nobody drew the line.

What helps:

Separate fixes from changes. Fixing an error, a typo, a mismatch with what was agreed - always included. Adding a new section, changing the structure, reworking it around a new idea - a separate task.

Name the set of revisions in advance - how many rounds on design and on content are included in the price.

Record the sign-off on each stage in writing, at least as a message in chat.

This is not bureaucracy but protection for both sides. The client knows what they will get, the contractor knows where to stop.

How much does a spec cost and is it included in the price?

With me, fixing the scope is part of the work and is not charged separately: a brief, a proposal with a list of work, a price for the agreed scope. A landing page from $190, a multipage website from $490, a complex project on request.

A separately paid spec only makes sense where the design work is a large job in itself: integrations with accounting systems, client portals, complex logic. In projects like that the document saves more than it costs.

What the price is made of: How much does a website cost in Tashkent.

Tell me about your task through the form on the contact page - I will put together a list of work, and you will see exactly what is included.