Answer in brief
Hiring someone to build a website means buying scope, a date, a number of correction rounds and the access you receive at the end — price only makes sense after those. What to check on a live site, how to read exclusions, and how to compare two quotes fairly.
What you are actually buying: You are buying scope, a date, a number of correction…
When you hire someone to build a website you are buying four things at once: a defined scope, a delivery date, a number of correction rounds, and a set of access credentials at the end. Price is the fifth, and it is the one that makes sense only after the other four are fixed.
Most disappointment in this market comes from comparing offers on price alone. Two quotes that both say a website can differ by whether content is included, whether the source code is handed over, and whether a correction after the first version costs extra.
So the useful skill is not judging talent from a portfolio. It is reading an offer closely enough to know what you would receive, and then putting two offers side by side on the same rows.
What follows is the set of rows worth comparing, the checks you can run yourself before signing anything, and a worked example using a published price ladder where every one of those rows is stated up front.
Read the offer before you read the portfolio
A portfolio tells you what a supplier has been allowed to make. It does not tell you what they will commit to for you, and the gap between those two is where projects go wrong.
The offer is the document that answers your questions. It should name the scope, the timeline, the number of revision rounds, and what is not included. An offer that leaves any of those four implicit has not been written for a buyer.
Pay particular attention to the exclusions. A supplier who writes down what they will not do is easier to work with than one who writes only benefits, because the second version leaves you to discover the boundary at the point where you need something.
If an offer is a single paragraph and a number, ask for the four rows in writing before you compare it with anything. A supplier unwilling to put them in a message is telling you something useful early.
Portfolio: check the live site, not the picture
A portfolio image is a design deliverable, not evidence that a site works. Open the live sites instead. If a supplier cannot point you at any address that is currently running, ask why — there are honest reasons, and hearing them is part of the assessment.
On each live site, check the things you will care about on yours. Open it on a phone. Fill in a form and see what happens. Click into a deep page and back out. Load it on a slow connection and see what appears first.
Speed is worth checking rather than asking about, and MDN's performance documentation sets out the vocabulary for what is being measured. You are not auditing anyone; you are finding out whether the sites this supplier ships behave the way you would want yours to.
Accessibility is the check people skip and regret. Try navigating a page with the keyboard alone and see whether you can reach and use the main controls. The W3C's WCAG 2.2 quick reference is the practical list, and a supplier who has clearly thought about it is telling you something about their standards.
Price: what a number has to include to be comparable
A price is comparable only when the rows behind it are the same. Before comparing two figures, write down for each: what is built, over how long, with how many correction rounds, and what is excluded. If a row is empty, the comparison is not ready.
Watch for the parts of a website project that are commonly left outside a build price: content and translations, photography, the licensing of a payment provider, ongoing support after launch. None of these being included is a problem; not knowing is.
Ask what a change after the last included round costs. Every project has one, and the answer separates suppliers who have thought about the working relationship from those who have only thought about the sale.
Be careful with a quote that is far below the others without a stated reason. Sometimes the reason is real — a template already built, a narrower scope, a quieter month. Ask for it, because a reason you can hear is reassuring and an absent one is not.
Timelines: know what the number is measuring
A timeline is only meaningful with its unit and its starting point. Working days and calendar days are different promises, and a schedule that begins when content arrives is a different commitment from one that begins when the contract is signed.
Ask what the clock is waiting for. If the build cannot start without your text, your photographs and access to your systems, then the date you should be planning around is the date those are ready, and that date is usually yours to control.
Look at how the supplier describes speed elsewhere in the offer. A published ladder that says 1-2 working days for a small fix and 2-3 weeks for a product build is telling you about their unit of work, and it lets you sanity-check the estimate you are given.
Finally, ask what happens if the date is missed and why it would be. The useful answer names a cause — a dependency, an approval, an integration — rather than promising it will not happen.
Revisions: read the term of the exact package
Revision terms are where offers differ most and are read least. One round after the first full build, two rounds before launch, two rounds per delivered feature — these are three different commitments, and they belong to different pieces of work.
Read the term of the package you are actually buying rather than the one you read about first. Assuming a neighbouring package's terms apply is a mistake that only surfaces when you ask for the change you assumed was included.
Ask what a round is. A round that means one consolidated list of corrections is different from a round that means one email, and the difference matters on the day you have three people's comments to send.
Also ask when the rounds expire. Correction rounds attached to a launch usually stop at launch; support after that is a separate arrangement, and it should be priced where you can see it.
Exclusions are the most useful part of any offer
The list of what a supplier does not do is the part of an offer that saves the most money, because it is the part that predicts the conversations you will have later.
Content and translations are the usual first item. Many suppliers, including VITON13, do not write client content or produce translations — that stays with you, and knowing it during the quote is what lets you plan the writing instead of discovering it mid-build.
Native mobile applications are the second. A responsive website and an application in a store are separate products; if you are imagining an app, say so early rather than assuming a website package stretches to cover it.
Payment licensing, photography and ongoing support each appear as exclusions in different packages for good reasons. None of them is a warning sign. An offer that lists them is easier to trust than one that lists none.
Access and ownership, settled before work starts
Agree in writing, before the project starts, who will hold the domain, the hosting account, the repository and the administrative logins at the end. This is a commercial matter, not a technical footnote: it decides whether you can change supplier later without paying twice for work already done.
The arrangement that works is a domain registered to your company, with the developer given delegated access. The one that causes trouble is a domain registered to the developer to spare you the paperwork.
Ask for the source code to be delivered in a repository rather than as an archive of files. An archive works until the next developer needs to know what changed and why, and then it does not.
Environment variables and third-party account credentials belong in the same conversation. A site that runs on settings only one person has is a site that has an unnamed dependency on that person.
Communication and the release rhythm
Ask how often you will see something running. A supplier who can show a working build on a regular rhythm is easier to steer than one who disappears and returns with a finished product for approval.
Ask who you will talk to, and whether that is the person doing the work. Neither answer is wrong, but a project with an intermediary needs a clearer written scope, because every clarification travels one step further.
Agree where decisions are recorded. A messaging thread is fine to talk in and a poor place to keep the scope; the moment a decision changes what is being built, it needs to land somewhere both sides can find it later.
Set the expectation for response times in both directions. Your approvals are on the critical path as often as the supplier's work is, and a project where only one side has a deadline is a project that will slip.
Signals worth slowing down for
An offer with no exclusions. Every real scope has a boundary, and an offer that describes only what is included leaves you to find the boundary at the worst moment.
A refusal to put the timeline, the revision count or the handover list in writing. Any of the three can be discussed and adjusted; none of them should be hard to state.
A promise about a search ranking, a conversion figure or a traffic number. Nobody controls those, and a supplier willing to promise one is either mistaken or is describing a metric you have not agreed on.
And an estimate given before anyone has asked how many pages you need or who is writing the content. A number produced without those two answers is a starting position rather than a quote, and it will move.
Comparing two quotes honestly
Put the offers into one table with the rows fixed by you: scope, timeline and its unit, revision rounds and when they expire, exclusions, handover contents, cost of a change after the last round, and the price. Fill every cell, asking where you have to.
Then read the table for what is different rather than for which number is smaller. In most comparisons, one offer includes something the other prices separately, and the ranking changes once you add the missing item to the cheaper column.
Decide what you would sacrifice if the budget were tight, and mark it in the table before you talk to anyone. Deciding that under pressure at the end of a negotiation tends to produce a different answer than deciding it calmly at the start.
Keep the table after you choose. It is the scope you agreed, in the form you will want it in during the acceptance checks, and it takes no extra work to preserve something you have already written.
A worked example: a published price ladder
It helps to compare against an offer where all the rows are stated. VITON13's development service prices five packages, and each one names its price, its timeline, its revision term and its exclusions rather than leaving them to be asked about.
Site Fix Pack is $70 over 1-2 working days for up to five agreed fixes, with a mobile and desktop check and a before/after list at handover, one round of revisions, and new pages, redesign and migrations named as not included. Launch Site is $380 over 3-5 working days for a responsive build, core CMS or data wiring and deployment setup, with two rounds of revisions before launch and content and translations supplied by the client.
Launch Site Express is $520 and delivers the Launch Site scope in a priority queue over 2 working days with daily builds, a launch checklist and a handover call, one round of revisions after the first full build, and content, photography and ongoing support excluded. Product Build is $880 over 2-3 weeks for feature delivery, state and route logic, testing and hardening, with two rounds of revisions per delivered feature, and native mobile apps and payment licensing outside the scope.
Ongoing Dev Support is $290 per month on a monthly cycle with 30 days notice to stop, covering priority updates, a weekly release rhythm and technical maintenance; the volume is agreed at the start of each cycle, and a new build or redesign is scoped separately. Whatever you end up choosing, that is the level of detail worth asking every supplier for before you compare a single figure.
Practical checklist
- Ask in writing for four rows: scope, timeline, revision rounds included, and what is excluded.
- Open the supplier's live sites on a phone and send a submission through one of their forms.
- Ask what event starts the clock and whether the days are working days or calendar days.
- Read the revision term of the package you are buying, not of the one next to it.
- Agree before work starts who will hold the domain, hosting, repository and admin logins.
- Put both quotes into one table with your own rows and fill every cell.
Questions and answers
What should I compare besides the price?
Four rows: exactly what is built, over what timeline and in which kind of days, how many correction rounds are included, and what is excluded. While any one of them is blank, two prices are not comparable, because different amounts of work sit behind them.
How do I know whether a price is reasonable?
Compare it with an offer whose rows are stated. VITON13 prices five packages: Site Fix Pack at $70 over 1-2 working days, Launch Site at $380 over 3-5 working days, Launch Site Express at $520 over 2 working days, Product Build at $880 over 2-3 weeks and Ongoing Dev Support at $290 per month. That is the level of detail worth asking every supplier for.
What can I check in a portfolio myself?
Open the live sites rather than the images. On a phone, by sending a form, by going into a deep page and back out, and on a slow connection. Separately, try moving through a page using only the keyboard — it shows quickly whether accessibility was considered.
Why does it matter who owns the domain?
Because it decides whether you can change supplier later without paying twice for work already done. The arrangement that works is a domain registered to your company with delegated access for the developer, and it should be agreed in writing before the work starts rather than at handover.
What should make me slow down in an offer?
No exclusions listed, a refusal to put the timeline or the revision count in writing, a promise about a search ranking or a conversion figure, and an estimate given before anyone asked how many pages you need or who writes the content. The last one is a starting position, not a quote.