Before answering “How much will a website cost?”, I would establish what must be delivered. A small service website and a store with products, inventory, payments and order handling are different projects. Even two quotes for the same number of pages can cover different content, integrations and handover work.
I do not use this guide as a market price list or a package offer. It is a way to compare real proposals without inventing a price range. The same questions apply whether I am evaluating a local team in Adana or Mersin or working with someone remotely.
Define the first job the website must do
I would describe the first release in one sentence. “Introduce the business” is a starting point, but I need something more specific to test: a visitor can find the current menu, understand a service and send an enquiry, or buy an available product.
A restaurant might need a menu, location and reservation route. A service business might need clear scope and contact details. A manufacturer might need product specifications and a quote request. These are hypothetical examples, not claims about projects I have delivered. I would not assume every business needs every feature.
I separate the first release from later work. A blog can sometimes wait; a working primary customer journey and appropriate access controls cannot simply be treated as optional extras. A membership or booking system that nobody needs can make the first release unnecessarily large.
Separate project work from recurring costs
I list setup, content preparation, design, development, migration and testing as project work. Then I record domain, hosting, licences, apps, maintenance and any usage-related fees separately. For each item I want a billing period, currency and named provider or owner.
I do not assume a promotional first payment will be the renewal price. I ask how taxes, currency changes and usage limits are presented in the actual offer, then verify current amounts with the provider. This is a project comparison method, not individual financial or legal advice.
The business also contributes time. Someone has to supply photographs, approve copy, clean product information and learn the operating process. I would record which tasks remain with the business instead of assuming an external quote covers them.
Turn package names into explicit deliverables
“Starter”, “professional” and “premium” do not tell me enough about scope. I put proposals into the same checklist. An omitted item is a question to resolve, not a free inclusion.
| Area | Question I would ask | Example acceptance evidence |
|---|---|---|
| Pages | Which pages and languages are included? | Approved content at the agreed addresses |
| Content | Who prepares text and images? | Deliverable files and confirmed usage rights |
| Mobile | Which customer journeys will be tested? | Usable navigation and forms on a narrow screen |
| Enquiries | Where will a submitted message arrive? | A delivery test and visible error handling |
| Migration | Which old URLs and media are covered? | Reviewed mappings and redirect checks |
| Measurement | Which events will be implemented? | Checked consent behaviour and data scope |
| Handover | Who owns accounts and receives files? | Independent business access and handover notes |
| Maintenance | What work and support period are included? | Written responsibilities and response process |
I would not accept “SEO friendly” or “fast website” as complete deliverables. I want to know which pages, conditions and checks those claims refer to. A promise about rankings or sales does not replace a technical acceptance test.
Recognise the extra work in ecommerce
Product count matters, but it does not describe the whole job. A small catalog can have many variants, size tables or personalisation options. Unstructured product data needs preparation before it can be loaded reliably.
For payment, shipping, accounting and inventory connections, I would identify the authoritative record. When an order changes, which information moves to another system, when does it move, and who sees a failure? Connecting systems and operating them need separate responsibilities.
A migration may also involve product URLs, images, customer information and order history. I would define the required data before moving it and avoid unnecessary personal data. A working new storefront does not by itself prove that historical records were transferred correctly.
I would include representative order journeys and failure cases in the scope: failed payments, stock changes, cancellation and refund handling. Where the provider offers a suitable test environment, I would use it first. Any real financial transaction needs its own agreed authority and cost.
Reduce scope before removing essential checks
If the budget is tight, I first examine functionality and content workload. A suitable existing theme or a simpler design may be enough. It still needs accessibility, security and mobile checks appropriate to the project.
A quote form might meet the need without a membership system. A single useful language may be better for the first release than empty pages in several languages. Every feature should have a purpose, an owner and someone responsible for maintaining it.
I would compare prices only across the same delivery list, time horizon and support assumptions. A cheaper initial quote can exclude work that another includes. A higher price is not, by itself, evidence of better delivery.
Compare two proposals against the same brief
I would send both suppliers the same short brief. Consider a hypothetical five-page service website in Turkish and English. Its job is to explain the service and deliver enquiries to the business; it does not need accounts or online payments.
One proposal might include translation and a form delivery test while the other leaves both to the client. I would ask for those differences to be priced or remove them from both offers and record them as internal responsibilities. I would not rank the headline totals while the underlying work differs.
| Shared requirement | Answer I want in each proposal |
|---|---|
| Five pages in two languages | Page list, translation owner and final review owner |
| Text and photography | Supplied-content assumptions and extra production scope |
| A working enquiry form | Delivery to the agreed destination and failure behaviour |
| Existing website continuity | URL, media and required data inventory |
| Post-launch costs | Renewal periods, maintenance limits and extra-work approval |
| Future handover | Account ownership, files, access and operating notes |
This is a comparison worksheet, not a tariff. If an on-site meeting or a photography session in Adana is needed, I would make it an explicit deliverable. I would not derive a price from the city name alone. Remote work still needs the same scope discipline.
Calculate the first year and renewal period separately
My comparison would use one-off work + service charges due in the first 12 months + usage-dependent costs under stated assumptions + separately approved extras. If an annual licence is already included in the first invoice, I would not count it again among monthly charges. I also keep currency and tax inclusion visible.
For payment fees or usage-based services, I ask for the provider's current terms and a clear volume assumption. Unknown order volume is not a definite cost. If I cannot verify a charge, I label it “to confirm” and show that the total remains incomplete in that respect.
I ask what happens after any introductory discount. A separate renewal column for the domain, hosting, licences and maintenance makes the ongoing commitment easier to see. Internal content approval or data preparation can be recorded as tasks or hours; I do not automatically turn that time into an external supplier charge.
Include old URL continuity in the delivery scope
For a replacement website, I would look beyond the new screens. Which old addresses will remain, and which will point to an equivalent new page? Google's site migration guidance recommends preparing a URL mapping and using server-side permanent redirects for changed addresses.
I would include that mapping and checks of important old links in the proposal. This does not guarantee a particular ranking. For a Shopify store, my consulting scope and handover guide develops the platform-specific questions.
A short brief you can adapt before asking for a quote
I would start a supplier conversation by completing the template below. Replace the bracketed fields with your own requirements. If something is unknown, write “to agree” rather than leaving it open to assumption. This is a requirements note for comparable replies, not a contract or a price commitment.
First-release purpose: The visitor should be able to [complete a task]. I will check this with [an observable acceptance test].
Starting point: My current website is [address / none]. Pages, content and links to preserve are [list].
Scope: [Page types and counts], [languages], [enquiry or store journeys]. Work excluded from the first release is [list].
Content: [Person] supplies copy, [person] supplies images and [person] handles translation. Missing content is [list].
Connections: Existing systems are [list]. The business retains account ownership; working access should be limited to the assigned tasks.
Schedule: Target launch is [date]. Content is due on [date], with [role] responsible for approval. Dependencies affecting the schedule are [list].
Your proposal: Please separate inclusions, exclusions, assumptions, acceptance tests and handover files. Show one-off charges, first-year costs and subsequent renewals separately, including currency and tax treatment.
Changes: Let us review the cost and schedule impact of additional requests in writing before implementing them.
I would not include passwords or customer records in an initial brief. The name of a system, the expected information flow and the responsible person are often enough to describe a connection. I would agree any necessary access arrangements after the project scope is clear.
Turn the reply into something you can check
First, I would label every requirement consistently across both proposals: included, separately priced, supplied by the business, or unresolved. Next, I would send unresolved items back to the person responsible. Until there is an answer, I would not treat them as free or complete.
Finally, I would rewrite a deliverable as a concrete check. Instead of “install a contact form”, I would use “the agreed test message reaches the authorised inbox, and a missing required field produces a clear message for the visitor”. I would name the person checking it and the evidence needed to close it. This is what makes a quote useful to me: it describes not only a cost but also what counts as finished.
How I separate a defect, a revision and a new request
Before discussing an extra charge, I compare the request with the approved delivery list. A form failing to deliver the agreed test message is different from adding a CRM connection later. I use the hypothetical examples below to make that conversation concrete. The labels do not automatically determine what is included or chargeable; that depends on the written scope and the parties' agreement.
| Example request | Record I check first | Decision to clarify |
|---|---|---|
| The form does not deliver its acceptance-test message | Approved form requirement and failure evidence | The correction needed to deliver the agreed behaviour |
| A heading or image arrangement changes on an approved page | Included revision types, rounds and approved design | Whether this fits the remaining revisions or needs separate agreement |
| CRM delivery is added to the enquiry form | Original integration list | New scope including data mapping, access, failure handling and maintenance |
| A third language is requested | Approved page and language list | Additional translation, layout, linking and testing deliverables |
I would not turn an unclear request straight into an hours estimate or a total. First I would describe what changes, which existing deliverables it affects and what demonstrates completion. Then I would ask the implementer to separate the one-off charge, any new recurring cost and the schedule impact. An unquoted item remains “to determine”, not zero.
If the CRM connection cannot be ready for the first release, one option might be to launch the agreed form and add the connection later. If that connection is essential, the schedule may need to change. I would record the work each option leaves with the business. This is an illustrative decision, not a reported project result.
My short change record includes the request, reason, inclusions and exclusions, cost, schedule, approver and acceptance test. Agreeing that record before implementation makes the delivery baseline easier to identify later.
What I check at acceptance and handover
At acceptance, I would check the important links, enquiry route, mobile journey and access arrangements as well as the design. Before launch, I want a rollback approach, a support contact and a named recipient for the handover. Domain and account ownership should already be clear.
For paid strategy or project leadership, see working with me. An initial message explaining the business need, existing website and intended first-release outcome is a useful starting point for defining scope.