What a Website Development Service Includes

• The risky part of a quote isn't what's priced. It's what's missing: hosting, content migration, redirects, accessibility, analytics and ongoing maintenance.

• Almost every website development service is the same six activities. What separates two quotes is how much of each is real work, and how much is padding.

• In Ontario, an accessible public website is a legal requirement at 50 or more employees, not an upgrade a vendor can quietly drop.

• Ask whose name goes on the domain, the hosting, the repository and the analytics on day one. Handover is too late to find out.

• "Maintenance" means nothing until somebody writes down what it covers, what it excludes, and how fast they answer when the site is down.

• Eight questions at the bottom of this page put two proposals on the same footing. They work on any firm, including the one you end up hiring.

Two documents that don't describe the same thing

Two quotes for the same website, and the only thing they agree on is that you need a website. One is a page and a half with four line items. The other runs eleven pages and prices things you've never heard of. Judging the work is the exact skill you're hiring for, so you compare totals instead, which is the one thing in either document that tells you least.

What follows is a decode of the document itself: which line items are real work, which are decoration, what gets left out and reappears as an invoice later, and the questions that put two proposals on the same footing. It works whether you hire us or somebody else.

Strip the language off and the work barely varies between firms. A website development service is six activities, and only some get named honestly on a quote.

The line items that are real work

• Discovery and information architecture. Which pages exist, what each is for, and what a visitor is meant to do next. Cheap to skip, expensive to retrofit.

• Design. Not one homepage mockup. Layouts for every page type you'll actually have, plus the states nobody demos: mobile, long content, a failed form.

• Front-end build. Turning those layouts into pages that hold up on a phone, on a slow connection, and in the browser your oldest customer still uses.

• CMS setup. Which parts you can change yourself, and which need a developer. This one decision drives most of your cost over the next three years.

• Integrations. Forms, CRM, booking, payments, email. Each is separate work with its own way of failing quietly, and each belongs on the quote as its own line.

• Testing and launch. Real devices and real browsers, plus the launch itself: DNS, certificates, redirects, and somebody watching the site through week one.

The line items that are usually decoration

• "Competitor analysis" or "market research" with no stated output. If you don't receive a document, it didn't happen.

• "SEO" as a single line with nothing named under it. Structure, titles and speed are a build concern. Content and links aren't. Ask which you're buying.

• "Unlimited revisions." It costs nothing to promise and gets managed away in practice. A named number of rounds with a review step is worth more.

• "Custom design" on a project that's a theme with your colours in it. Often the right call. A problem only when you pay for one and receive the other.

The test that separates the two lists: a real line item names an artifact you receive, or a decision it settles. If nobody can say what lands in your inbox at the end of it, it's there to make the document heavier. Scope also decides whether a number holds, not the billing model on the cover, which is an argument we made separately.

The biggest gap between two totals, though, is usually the platform, and it almost always happens too early. Who updates the site after launch decides it, which is the case we make on our Webflow page.

None of this is dishonest by default, and some of it genuinely isn't the developer's job. But it's all work somebody has to do before your site is finished. If it isn't in the document you signed, you'll have that conversation later from a weaker position.

Hosting, and the bill that starts at launch

A build price and a running cost are two different numbers, and quotes routinely carry only the first. Ask which account the site will live in, whose name and card are on it, and what it costs monthly. Same for the domain renewal, the certificate and any paid plugins. A site with a lapsed renewal goes dark as completely as one with a bug in it.

Content, migration and the old URLs

"Client to supply copy" is a sentence that has delayed more launches than any technical problem. Settle who writes each page, and who moves the existing content across. If you already have a site, the old addresses matter as much as the new ones. Google's guidance on moving a site is direct: use permanent redirects, and expect rankings to move while it recrawls. Redirects are cheap to plan and painful to reconstruct once the old site is gone.

Accessibility, which is law before it's a nice thing to do

In Ontario this isn't a preference. The Government of Ontario states it plainly: since January 1, 2021 the AODA requires businesses and non-profits with 50 or more employees to meet WCAG 2.0 Level AA on their public websites, for content published after January 1, 2012. At or over that threshold, accessibility belongs in the scope, priced, with testing named. Under it you're not required to, and it's still better decided on purpose than discovered.

Analytics, and knowing whether any of this worked

Somebody has to install measurement, in accounts you own, and agree what counts as a lead before launch. Skip it and you have a site nobody can evaluate.

This is the part that stays with you long after the build is a memory, and the part most often handled with one sentence.

Start with the domain, because everyone assumes it's settled. ICANN's registrant rules contemplate this exact arrangement, a website designer registering a domain name for a client, and put the responsibilities on whoever is recorded as the registered name holder. If that's the agency rather than you, their inbox gets the renewal notices and their login controls where your traffic points.

Then go through the rest of it one account at a time, and write down whose name each is in:

• The registrar account, and the registrant recorded on the domain itself

• DNS, if it's managed somewhere other than the registrar

• Hosting or the platform subscription, including who the invoice goes to

• The code repository, owned by your organization rather than a personal account

• Analytics, Search Console and any tag manager

• Whatever sends your transactional email and stores your form submissions

• Any licence, theme, plugin or font bought for the project, and whose name it's in

Then ask the harder version. Owning the code and being able to use it aren't the same thing. A repository with no setup notes and no record of how the site gets deployed is technically yours and practically unusable. Make documentation a named deliverable.

We structure engagements this way ourselves. The scope document comes before the number, and it states what's included and what's explicitly excluded. Account ownership belongs in that document rather than in a conversation at the end. Our services page shows where that sits.

Maintenance is the vaguest word in the document, and usually sold as a monthly line with no definition under it. The line exists for a real reason. Patchstack's 2026 security report counted 11,334 new vulnerabilities across the WordPress ecosystem during 2025, up 42% on the year before, with 91% of them in plugins rather than core, and about half of the high-impact ones exploited within a day of disclosure. A site left alone isn't a site standing still.

The trouble is that four different things get sold under one word. Ask for them separately:

• Keeping it alive. Platform and plugin updates, backups stored somewhere other than the site, certificate renewals, uptime monitoring. A backup only counts once somebody has restored one as a test.

• Fixing what breaks. Including what breaks because of an update they applied. Get the answer to "who pays for that" in writing, before it happens.

• Small changes. A new staff photo, a revised service page. How many a month, and how fast.

• New work. A new page type, a new integration, a rebuilt section. Almost never included, and shouldn't be. It should be quoted, and the plan should say so.

Then ask two more things: what response time you're promised, and what happens when the site goes down at nine on a Saturday. A plan that only runs during business hours is a defensible thing to sell. It isn't a defensible thing to discover.

Send these to every firm on your list, in writing, and read the answers next to each other rather than each proposal on its own. The differences that matter show up in the answers, not the totals.

• "What will I have received when this is finished?" A good answer is a list of things: files, accounts, documents, logins. A weak one lists activities they'll have performed.

• "What's explicitly excluded from this scope, in writing?" Anyone who can't name exclusions hasn't scoped it. It's the most informative question here.

• "Whose name goes on the domain registrant, the hosting account, the repository and the analytics property, on day one?" The answer you want is yours, from the start, not transferred at the end.

• "Who writes the content, who moves the existing content, and what happens to the old URLs?" A firm that raises redirects before you do has done this before.

• "What accessibility standard are you building to, and is testing for it in this price?" You want a named standard and a named method. "We follow best practices" is not a standard.

• "What does maintenance cover, what does it exclude, and what's your response time?" Ask for it as the four separate things above, not as one monthly line.

• "What's your process when I ask for something that isn't in the scope?" A described process beats a promise to be flexible. Flexibility with no process is how the last month turns tense.

• "If we part ways in a year, what does moving to another firm involve?" Listen for documentation, access and a handover, not just "you own the code."

Two or three get a straight answer from everybody. The rest don't, and which ones do is the comparison the totals can't give you.

Open both proposals at the section saying what isn't included, and read those two lists against each other first. If one document has no such section, you've learned the most useful thing it was going to tell you.

Then run whoever survives through the vetting questions in how to identify the right development partner, before anybody signs anything.