How to Order a Website: A Practical Guide to Working with a Web Studio

Ordering a website feels opaque from the outside. You send a brief, get a quote, and then... what? The truth is that the process is predictable, and knowing how it works makes the difference between a smooth project and a painful one. Here's what we tell clients before they sign anything.

The process, in five stages

Every serious project follows the same shape, whether it's a landing page or a SaaS product:

Discovery — you and the studio agree on the goal, the audience, and the scope. This ends with a written document both sides sign.
Design — wireframes first, then visual design. You review, you give feedback, the studio iterates.
Development — the design becomes a working site. You see it on a staging URL, not just in screenshots.
Testing and launch — cross-browser checks, performance, SEO basics, then deployment to your domain.
Handover and support — you get access, documentation, and a defined window of post-launch fixes.

The key expectation to set early: feedback rounds are part of the plan. A studio that promises "unlimited revisions" is either overcharging for them or planning to ignore you. Agree on the number of review rounds up front.

What to prepare before the first call

A good brief is worth more than a big budget. Before you contact a studio, write down:

The goal — what should a visitor do on the site? Buy, sign up, call, read?
The audience — who are they, and what do they care about?
Three sites you like — and, just as important, why you like them. "Clean" tells us nothing; "short paragraphs, big product photos, one clear call-to-action" tells us everything.
Content — text, images, logos. A site is only as good as the content it ships with.
The deadline — real deadlines, not "as soon as possible".

You don't need to be a designer or a developer. You need to be a person who knows their business — that's the part we can't invent for you.

How pricing actually works

Most studios price one of three ways:

Fixed price per project — predictable, but the scope must be locked. Every change beyond it is a change order.
Time and materials — you pay for hours. Fair when the scope is genuinely unknown, but you need a cap.
Retainer — a monthly fee for ongoing work: updates, content changes, maintenance.

A suspiciously low quote is a red flag, not a bargain. The real cost of a website is the work after launch — maintenance, security updates, content changes. Ask what happens a year from now: who updates the framework, who patches security issues, and what that costs.

Red flags to watch for

No written scope — if the studio won't put the deliverables in writing, the project will be defined by whoever argues loudest.
"We'll show you the design in a week" — without discovery, that's a template with your logo on it.
No staging environment — you should see and click the real site before it goes live.
The site is "done" when it's launched — a launch is the start of the site's life, not the end of the project.
Vague ownership — you should own the domain, the hosting account, and the code. Always.

What a good handover looks like

When the project ends, you should receive: access to the domain registrar and hosting, the source code (in a repository you can access), a short admin guide, and a clear statement of what's covered in the post-launch support window. If a studio hesitates on any of these, ask why — the answer will tell you everything.

A website is a business tool, not a piece of art. The best projects are the ones where the client knows their business, the studio knows its craft, and both sides agree on what "done" means before the first line of code is written.