12 Questions to Compare Website Development Quotes Fairly
Use seven questions to make website development quotes comparable. Confirm ownership, repo access, scope change rules, post-launch support, and payments.
You have a few quotes on your desk. Some look similar on the surface: “website + admin panel + SEO + support.” The numbers are wildly different. That usually means the quotes are not actually comparable. The fastest way to find out is to ask the same hard questions to every vendor and listen for specifics.
1) Who owns the code and the design files after launch?
This decides whether you can switch vendors without rebuilding, and whether your site becomes a reusable asset or a locked subscription.
A solid answer sounds like: “You own the source code, the compiled build, the design files (Figma/Sketch), the copy we wrote for you, and all accounts we created. We’ll hand over everything at launch and document how to run it.” Ask what “design files” means. It should include the editable file, not just exported PNGs.
A worrying answer sounds like: “You own the website, but we keep the code,” “We don’t share source files,” or “You can pay a fee to buy the code.” Another red flag is vague language like “licensed to you.” If they won’t put ownership in writing, assume you’re renting.
2) Where does the code live, and do I get access to the repository?
The repository is the single source of truth. If you don’t have access, you can’t see progress, you can’t restore quickly after a mistake, and you can’t onboard a new developer without friction.
A solid answer sounds like: “We use Git. The code lives in a private repo on GitHub/GitLab/Bitbucket under your organization, or we transfer it to you at launch. You have admin access. You can see commits and releases. We tag the launch version.” Bonus points if they describe how they handle secrets (API keys) so those don’t live in the repo.
A worrying answer sounds like: “We’ll send a ZIP when it’s done,” or “It’s on our server.” ZIP handoffs lose history, hide scope creep, and make debugging harder.
3) Is this a fixed price or hourly — and what happens if scope grows?
Pricing structure affects your risk. Fixed price can be safe if the scope is clear. Hourly can be fair if you get transparency and control. The dangerous version is “fixed price” with vague scope, where every detail becomes a paid change.
A solid answer sounds like: “This is fixed for the defined scope. If scope changes, we send a written change request with cost and timeline impact before starting. If it’s hourly, we estimate in ranges, log hours, and you approve a weekly cap.” Ask what triggers a change: new page types, extra languages, new integrations, new roles in the admin panel.
A worrying answer sounds like: “We’ll see as we go,” “Don’t worry, it won’t change,” or “Everything is included” with no list of what “everything” is. If they can’t explain their change process, budget surprises are likely.
4) Who writes the technical specification, you or me?
A technical spec is not busywork. It’s how you avoid building the wrong thing and arguing about what was “obvious.” If nobody owns the spec, you’ll pay for rework.
A solid answer sounds like: “We’ll lead discovery, write the spec, and you sign off. You provide business rules and examples. We turn that into user flows, page templates, data fields, integrations, and acceptance criteria.” A strong vendor can show a sample spec: how a product card behaves, what happens when stock hits zero, which emails are sent, which fields are required.
A worrying answer sounds like: “You tell us what you want and we build it,” with no written requirements. Or the opposite: “You must provide a full spec,” unless you truly have an internal product team. Either way, unclear ownership here usually becomes delays and change fees later.
5) What exactly happens after launch — and for how long?
Launch is not the finish line. DNS issues, email deliverability, payment edge cases, and “small” content tweaks show up right after go-live. If support is undefined, you’ll be stuck negotiating during a problem.
A solid answer sounds like: “We include a defined stabilization period (for example, a few weeks) for bug fixes related to the agreed scope. After that, we offer ongoing maintenance with clear terms: what’s included, what’s billable, and response times.” It should also cover backups, security updates, and monitoring—especially if the site uses plugins or a framework that needs patching.
A worrying answer sounds like: “We launch and then you’re on your own,” or support that depends on one person’s availability with no backup. Also be careful with “free support forever” unless it’s narrowly defined.
6) Can I edit text and images myself, without calling you?
If you need a developer for every banner change, your site becomes slow to operate. On the other hand, not everything should be editable—too much flexibility can create inconsistent pages and broken layouts.
A solid answer sounds like: “Yes. You’ll have an admin panel (or CMS) for core content: pages, blog/news, hero sections, product info, images, SEO fields. We’ll train you and provide short documentation. We’ll lock layout-critical components so edits can’t break the design.” Ask to see the editor experience in a live demo, not screenshots.
A worrying answer sounds like: “Just email us changes,” or “You can edit it in the code.” That’s not operational. Another red flag is a CMS that’s technically present but so complicated your team won’t touch it.
7) How will you handle online payments and RS.ge invoicing?
In Georgia, “payments” is not one checkbox. You need to decide: card payments now or later, which provider, what the checkout flow is, how refunds work, and how invoices/receipts are issued (including RS.ge requirements if you need them). These choices affect cost and timeline.
A solid answer sounds like: “We’ll confirm your payment provider and exact flow (one-time, subscription, partial payments). We’ll specify what data is stored, how we handle failed payments, and how invoices are generated. If RS.ge integration is needed, we’ll define whether it’s automated, semi-automated, or manual and what fields are required.” Good vendors ask early about legal entity details, VAT status, delivery rules, and refund policy.
A worrying answer sounds like: “We’ll add payments later,” without explaining the impact. Or “RS.ge is easy” without having done it in a real checkout and accounting flow.
8) Who hosts the site, and whose account is it registered under?
Hosting isn’t just performance. It’s control. If the hosting account belongs to the vendor, you may lose access during a dispute, or you may be unable to change DNS, renew SSL, or view logs when something breaks.
A solid answer sounds like: “Hosting is in an account you own (or we create it in your name). You have admin access. You pay the provider directly. We manage deployments and monitoring if you want, but you keep the keys.” Also ask about backups (frequency and retention), SSL certificates, and where emails are hosted (separate from the website, ideally).
A worrying answer sounds like: “We host it on our server,” with no admin access for you. Or the domain is registered under the vendor’s name “for convenience.” Weblier’s approach, for example, is that clients own the code and every account—use that as a benchmark when comparing.
9) What’s the realistic timeline, and what usually causes delays?
A timeline should reflect the actual work: discovery, design, development, content, testing, and launch. The real question is what depends on you—and what happens if you’re late with materials.
A solid answer sounds like: “Here’s the plan by weeks, with dependencies: you provide branding assets and content by date X; we deliver design by date Y; you approve within Z days; we build in sprints and show a working demo each week.” A credible vendor lists common delay causes: slow approvals, missing product data, late copy in two languages, last-minute feature additions, payment provider onboarding, and legal checkout text.
A worrying answer sounds like: “Two weeks, no problem,” for anything beyond a simple landing page. Or a timeline with no milestones and no mention of approvals. Weblier’s typical flow is discovery (~1 week) → design (1–2 weeks) → build (2–4 weeks) → launch, but any studio should be able to map the same reality to your scope.
10) Can I see three live sites you built and speak to one of those clients?
Portfolios can be misleading. A beautiful site might be a template, or the vendor may have only done a small part. Client references tell you what working together feels like after the contract is signed.
A solid answer sounds like: “Here are three live projects similar to yours (industry, features, bilingual, e-commerce, admin). Here’s what we did: design, build, content migration, integrations. And yes, you can speak to a client—we’ll ask permission and set it up.” When you speak to the client, ask about deadlines, change requests, and how issues were handled after launch.
A worrying answer sounds like: “We can’t share links,” “All our work is under NDA,” or they only show Dribbble shots. NDAs exist, but a studio doing steady work can usually share at least a few public sites and one reference.
11) What’s your response time when something breaks?
When checkout fails or the site is down, “we’ll reply soon” isn’t good enough. Response time affects revenue and stress. But you also want honesty: 24/7 support costs money, and not every business needs it.
A solid answer sounds like: “We define severity levels. For critical issues (site down, payments failing), we respond within a stated window during agreed hours, and we have an escalation path. For minor issues (layout tweak), we handle it within a few business days.” Ask whether they monitor uptime, who gets alerts, and whether more than one person can respond.
A worrying answer sounds like: “Just message us,” with no timeframe, or a single developer who might be unavailable. Also be careful if they promise instant fixes without asking what stack, hosting, and access they’ll have—real incidents require investigation.
12) What is explicitly NOT included in this quote?
This is the question that prevents fights. Every quote has boundaries. A good vendor will tell you what they are before you sign, even if it makes the quote look less “complete.”
A solid answer sounds like: “Not included: copywriting, translation, product data entry, professional photography, paid plugins, third-party subscription fees, legal policy writing, complex SEO strategy, ad tracking setup beyond basic analytics, custom illustrations, and ongoing content updates. Integrations not listed are out of scope. Extra page templates beyond X are out of scope.” The exact list depends on the project, but it should be written.
A worrying answer sounds like: “Everything is included,” or silence. The most common surprise exclusions are content population, bilingual content preparation, and integration costs (payment provider fees, SMS, delivery APIs).
FAQ
If two quotes are close in price, can I assume they’re equivalent?
No. Compare what you get control over (accounts, repo access, editable design files), what’s included post-launch, and how change requests work. Two vendors can both say “CMS included,” but one gives you a clean editor with training, and the other gives you a barely configured panel that still requires developer help. Ask for the “not included” list and a milestone timeline from both.
Should I pick fixed price or hourly?
Pick based on how clear your scope is. If the site is straightforward and you can define page templates, integrations, and admin needs upfront, fixed price with a change-request process is usually safer. If you’re still figuring out product rules, content structure, or you expect iterations, hourly with a weekly cap and transparent reporting can be more honest and less adversarial.
What should I prepare before I request quotes?
Have these ready: examples of sites you like (and what you like about them), a list of required pages, languages (often Georgian + English), key features (forms, booking, e-commerce), who will provide copy and images, and any integrations (payments, delivery, CRM, RS.ge invoicing needs). Even a rough sitemap and 10 bullet points of requirements will improve quote accuracy.
Is “domain and hosting included” good or risky?
It can be fine, but only if the accounts are in your name and you have admin access. “Included” should mean the vendor handles setup and renewals while you keep ownership and credentials. If the domain is registered under the vendor, you’re exposed. Ask directly whose account holds the domain, hosting, SSL, email, analytics, and payment provider settings.
If you want, we can do a focused 15–20 minute call and walk through your current quotes line by line. You’ll leave with a short list of follow-up questions for each vendor, including us.
