Award-Winning
Custom Web
Design Agency

A web design agency works out what a website has to accomplish, then makes every structural decision that follows from it. The visual layer is the last part of that job instead of the whole of it, which is the biggest misunderstanding buyers arrive with.

Strip the label away and the practice is four judgements in this order.

1. Who the site is talking to and what it has to move them to do. One audience or four, an enquiry or a purchase or an application, and what somebody has to believe first.
2. What goes on which page, and in what order. This is information architecture, meaning the map of pages and the routes between them. Get it wrong and no amount of styling recovers it.
3. How each page makes its case. Hierarchy, content, proof, and the moment a reader is asked to act.
4. How all of that behaves as a working thing. On a four-year-old phone, on a slow connection, for somebody navigating by keyboard and not a mouse.

Design and development are two different trades and the distinction is worth holding. Design settles what the site says, how it is organized and how it looks. Development is the engineering that turns those decisions into something that runs, meaning the code, the content system your team logs into, and the connections to your other software. A design can be admired and impossible to build sensibly. A build can be flawless and unusable.

What an agency owns that a template or a lone freelancer does not is the argument between those trades. A template is somebody else's answer to all four judgements above. One freelancer, however good, is one opinion with nobody to disagree with it, and no individual covers strategy, copywriting, interface, engineering, accessibility and search at a senior level at once. An agency holds those specialists in one room and loses the arguments internally instead of on your site. The people who would do it are worth meeting first, and the mix of roles we recruit into is the shape of that answer.

The honest case for not hiring one. If you are pre-revenue and still testing whether anybody wants the thing, a template you set up over a weekend is the right decision and you will hear that from us. If you need four pages that load quickly and say plainly what you do, a good freelancer is cheaper and the outcome similar. Agencies earn the fee when a site must serve several audiences, carry real traffic, or survive a year of a marketing team editing it. Below that line, the wider practice has cheaper places for your money.

Brand Vision is an award-winning web design and branding agency, headquartered in Toronto and staffed across Chicago, San Francisco and Miami as well. Trading since 2018, past 500 projects delivered, with four Awwwards and a Webby standing against the design work.

Credentials are the easy part. What matters on a website build is narrower, and it comes down to four things.

The brand and the build sit in the same building. Most websites are designed by a studio that received the strategy as a PDF and read the first four pages of it. Here the people who settled your positioning inside the branding practice sit down the corridor from the people laying out your homepage, so the argument the brand makes and the argument the site makes are one argument. Commission the two separately and the site becomes a decorated version of a strategy nobody read.

One senior team from sitemap to handover. No research passed to a second group, no junior team executing somebody else's pitch, and no account manager standing between you and whoever is building. The senior people on it are named before you sign anything.

Developers are in the room while it is still being drawn. Which sounds procedural and is the reason nothing gets approved that turns out to be expensive or impossible three weeks into the build.

Search, accessibility and performance are build decisions here. All three get settled while the structure is drawn, because retrofitting any of them costs several times what doing it once costs. Work already shipped tests that better than this page can.

The honest ceiling. Awards measure craft at a moment in time and say nothing about whether a site sold anything, so read the recognition above as evidence of execution and nothing more. Average lift in leads across past programs has been 250%, a figure pooling engagements of wildly different sizes and starting conditions that forecasts nothing about yours. And breadth only counts where every practice is strong, so the fair question to put to us is which of ours is thinnest for your project.

Who should hire somebody else. A company needing a single-platform specialist for a genuinely unusual build, meaning something like a headless commerce stack with bespoke fulfillment logic behind it, is better served by a shop that does only that. So is a company whose budget sits under the bottom of the ranges further down this page, where a freelancer gets closer to the outcome for the money. And if the address on the invoice matters more to you than the work does, the Toronto studio is where the practice was built and where most of it still runs.

A custom website design engagement covers the complete build, from research through launch, delivered by one team instead of assembled from separate vendors. The scope covers strategy, structure, content, design, development, accessibility, and search, and the reason those sit together is that separating them is where most websites lose their argument.

What a full engagement includes.

• Research and strategy. Goals, audience, competitive review, and an audit of the existing site. Analytics and search data shape the sitemap and the content priorities before anyone opens a design file.
• Information architecture and UX. Page models, navigation, and the flows people actually move through, resolved in wireframes and interactive prototypes with the usability team, so the expensive decisions get made before code exists.
• Visual design. A design system built on your brand identity, with components and responsive layouts instead of a set of flat page comps.
• Content. A content plan per page, with hierarchy, length targets, and copywriting where it's in scope. Editorial review either way.
• Development. A clean, well-structured CMS, the design system implemented properly, and integrations built and tested instead of assumed.
• Accessibility and performance. WCAG standards and Core Web Vitals handled from the first line, not remediated afterward.
• Search foundations. Semantic structure, metadata, schema, sitemap, redirects from old URLs, and analytics configured before launch.
• QA, launch, and handover. Testing across real devices, redirect mapping, training for your team, and documentation.

Two of those carry more weight than their position on the list suggests. The wireframe stage, because a layout everybody has already argued about is cheap to change and a built page is not. And the content plan, because a design approved against placeholder text gets rebuilt the week the real copy lands.

What a web design project does not include is worth naming, so nothing arrives as a surprise at invoice stage.

• Photography and video production, which we art-direct and commission but do not shoot in-house
• Brand collateral like pitch decks, print and packaging, which is graphic design work on its own line
• Ongoing search, content and paid programs after go-live
• Copywriting for a large content library, scoped separately once the real page count is known
• Third-party licences, meaning fonts, stock imagery and paid plugins, itemized so you know exactly what you are renting

Every proposal itemizes which of these your project includes and which it does not, so you can compare it honestly against another web design company instead of comparing one lump sum to another.

A template is a set of design decisions made for a different company. Custom web design starts from your business and your audience instead. That distinction sounds abstract until you look at what it costs on either side.

A template arranges your content into a hierarchy built for someone else's offer. Which is why template sites so reliably bury the one section that would actually convert, and why the page order rarely matches how your buyers make a decision. It also ships with code paths you'll never use, which is a common and invisible cause of poor Core Web Vitals scores, meaning main content that takes longer than 2.5 seconds to appear and a layout that shifts while somebody is reading it.

Then there's the second year. Customizing a template means fighting it, and the accumulated workarounds usually cost more than the original build did. Meanwhile a competitor can buy the same one. Once the workarounds outgrow the thing they were patching, what you are really buying is a replatform, which is a second project nobody put in a budget.

What the template argument gets right is speed and certainty. You see the thing before you pay for it, it launches in days instead of months, and it costs a few hundred dollars against several thousand. For a business testing whether a market exists at all, that trade is correct and we will say so out loud. Same for a single-purpose page that has to exist by Friday.

The result is easy to spot from outside, once you know what you are looking at. Six or seven sections in an order nobody chose. A hero image that means nothing. Three button styles, because two of them came with the theme. And a phone layout that technically works while asking a visitor to scroll past four irrelevant blocks to find a phone number. If that describes your current site, the template is not the only problem, but it is the thing setting the ceiling.

Custom means the architecture, the components, the content structure, and the visual system are built for the work your site has to perform. It doesn't mean expensive for its own sake. Where a smaller scope is the right answer, a focused custom build still beats a stretched template, because the decisions underneath it were made for you.

Worth saying plainly. Custom is not the same as building everything from nothing. We build on established platforms all the time. The portfolio shows what that looks like across very different businesses, and the argument behind each build is the part worth judging.

You decide on our recommendation, and the recommendation follows your requirements instead of what we prefer to sell. Every one of these platforms is the right answer for somebody and the wrong answer for somebody else, so here is the honest version of each, including what it costs you.

Webflow. Strongest for marketing sites where design control matters and a non-technical team publishes often. In favour, hosting and security are handled, output is clean, and a marketer can build a page from approved components without a developer. Against, it is a hosted platform with published content limits worth designing around, since a collection list displays up to 100 items unless pagination is turned on, a page can carry up to 40 collection lists and 10 nested lists, and there is no server-side code, so genuinely custom back-end logic has to live in an external service. Cost is a monthly site plan, which is predictable and not free.

WordPress. Right for large content libraries, real editorial workflow, and cases where a specific plugin is doing load-bearing work. In favour, you host it wherever you like, the five built-in roles from administrator down to subscriber map neatly onto a publishing team, and almost anything can be built. Against, it is genuinely yours to maintain, meaning core updates, plugin updates, backups, and security, and every plugin added is another dependency that can break or slow the site down. Sites we inherit in poor condition are overwhelmingly on this platform, and it is nearly always the plugin stack rather than the platform.

Shopify. The default for most stores, because payments, tax, fraud, and inventory infrastructure stop being your problem. In favour, checkout is reliable and converts well without being rebuilt. Against, a product supports up to 2,048 variants and only three options, which catches out anybody selling by size, colour, material, and finish at once. URL structure is fixed around product and collection paths, which matters on a migration, and the deepest checkout customization sits behind the top plan.

WooCommerce. Right when the shop needs to behave unusually, or when commerce sits inside a larger WordPress build. In favour, complete control over product logic, pricing rules, and checkout flow. Against, the hosting, the performance, the updates, and your share of payment-security responsibility all sit with you, which is a real operating cost rather than a footnote.

Custom development. React, Vue, Django, Node, and headless setups, for portals and applications where an off-the-shelf platform will not hold. Maximum freedom, permanent developer dependency, and only worth it when the requirement is genuinely there.

Preference is the last input, and a hard constraint beats it every time.

A focused site runs $7,000 to $15,000, a full marketing site $15,000 to $30,000, and larger builds start above $50,000. Ranges below, so you can tell quickly whether we're in your budget.

• Microsite, 3 to 5 pages. $7,000 to $15,000. Right behind a single campaign, a product launch, or a narrow offer.
• Full marketing site, roughly 6 to 10 pages. $15,000 to $30,000, with most projects landing near $20,000. This is the common shape for a small business website or a growing company replacing something that no longer fits, and it is the band most sectors we work in sit in.
• Webflow builds. From $10,000, including custom interactions and a CMS your team can operate.
• Ecommerce, portals, and application builds. Scoped individually and typically starting above $50,000, driven by catalogue size, integrations, and payment complexity.
• B2B and corporate sites. Priced on structure and stakeholder count more than page count, since a site serving four divisions and three buying roles is a different problem from one serving a single audience.

The real driver is not the number of hours spent designing. It's how many decisions the site has to support. How many audiences you address. How much of the content already exists. How many people approve direction before it's locked, which is the variable companies underestimate most.

The build figure excludes platform and hosting fees, font and stock licences, photography or video where the site needs it, and any ongoing program after launch, all of which get quoted on their own lines so the number stays comparable between agencies.

Two honest things sit at the bottom and the top of that list. Below roughly $7,000 there is no version of this an agency can do well, and you will be pointed at a freelancer or a good template instead of being sold a thin engagement. And a quote at a third of these ranges is usually one of three things, meaning a template with your logo on it, one junior covering all four disciplines, or a scope that quietly omits content, accessibility and the redirect map. Ask which of the three it is and the answer usually arrives quickly.

Every proposal is itemized line by line, so you can question any component and remove what doesn't earn its place. Book a call and we'll tell you which range applies before you commit to anything.

Most projects run 8 to 12 weeks. A focused build with ready content and one decision-maker can land in 6. Larger builds run 4 to 5 months.

Where the time goes.

• Discover, roughly 2 to 3 weeks. Goals, audience and competitor research, analytics review, audit of the existing site, then the sitemap and content plan.
• Design, roughly 3 to 4 weeks. Architecture and UX flows first, then visual design and components, presented as interactive prototypes, not flat screens.
• Development, roughly 3 to 5 weeks. CMS build, design system implementation, integrations, and QA across real devices.
• Launch, roughly 1 week. Redirects, accessibility and performance checks, analytics, training, and handover.

Ecommerce, complex integrations, or migrating a large legacy site extend the development phase considerably, which is where the 4 to 5 month range comes from.

Your schedule is decided on your side of the table, not by our availability. It's content readiness and how fast feedback comes back. Projects almost never stall in design. They stall because the copy arrived three weeks after it was promised, or because six reviewers filed contradictory notes and nobody in the room could overrule anybody.

The arithmetic of feedback is worth stating, because it is the whole variable. A ten-week schedule assumes each review round comes back inside three working days as one consolidated set of notes. At a fortnight per round with three reviewers who disagree, the same scope lands nearer sixteen weeks and nothing about the work itself got harder.

That's why the content plan is built in week one instead of discovered as a problem in week ten, and why decision-makers and review dates get locked at kickoff.

Where a date genuinely cannot move, the scope moves instead. Usually that means launching a smaller site that is finished, then adding sections in a second phase, which beats launching everything half-done on the day. You get shown both versions and you pick. If you're working toward a fixed date, say so on the first call and you'll get a straight read on whether that date and that scope can coexist.

We do both, and a website redesign is its own discipline, not a cheaper version of a new build. The job is to carry forward what already works while correcting what doesn't, and that requires knowing which is which before anything gets designed.

What disappears in a rebuild nobody audited is pages that were quietly earning search traffic, integrations that were quietly working, form flows that were quietly converting, and years of accumulated URL equity. The site looks better and performs worse, and the diagnosis usually arrives three months later when lead volume hasn't recovered.

So the work starts with an inventory.

1. Analytics. What draws visitors, what converts them, and which pages have gone a full year without being opened.
2. Search data. Every term the site currently holds a position on, and the exposure if those pages move or disappear.
3. Behaviour. Where people drop, stall, or loop back, which usually identifies the real problem faster than any opinion in the room.
4. Technical state. Speed, Core Web Vitals, mobile rendering, accessibility, and whatever has broken since launch.

A rebuild is justified by structure and not by appearance. Where the information architecture no longer matches what the business actually sells, where the platform cannot do what the next two years require, or where the technical floor is low enough that every fix ends up fighting the build, replacing the site is cheaper than defending it. Wanting the site to look current does not belong on that list, and on its own it is usually satisfied by new typography, new imagery and one rebuilt homepage.

Sometimes the inventory produces a full rebuild. Other times the recommendation comes back far smaller. A few pages rewritten, the navigation restructured, and a technical cleanup, at a fraction of a full rebuild. We've talked clients out of redesigns they arrived asking for.

Worth knowing before you plan the calendar. A redesign frequently takes longer than a new build of the same size, because the inventory work is real and because every decision has an incumbent version to argue with.

We also take on sites we didn't build. If you'd rather have the diagnosis before committing to anything, a UX audit or a marketing audit is a standalone engagement, and the findings carry into whatever follows.

Online stores are a full part of the practice, on Shopify, WooCommerce, or a custom stack depending on how the business actually runs.

Ecommerce web design is a different problem from a marketing site, because a store is a sequence of decisions and every unnecessary one costs a sale. So the work treats discovery, product evaluation, cart, and checkout as one connected path instead of four screens designed separately.

Where the attention goes.

• Findability. Category structure, filtering, and search that match how people actually shop your catalogue, which is rarely how it's organized internally
• Product pages. Enough information to remove doubt, ordered so the deciding detail isn't buried below the fold
• Cart and checkout. Every removable step removed, guest checkout available, and the payment and shipping logic tested against real edge cases
• Mobile. Where most purchases now happen, and where a checkout designed on a desktop quietly fails
• The plumbing. Payment and tax configuration, abandoned cart flows, conversion tracking, and the analytics that tell you what's selling and why

Where stores quietly lose money is narrower than most teams expect, and it is nearly always one of these.

1. A filter combination that returns nothing on the third click, with no route back
2. Variant imagery that doesn't change when somebody picks a different colour
3. Shipping cost revealed only at the final step, which is among the most common reasons a full cart gets abandoned
4. A site search that fails on plurals, misspellings and the words customers use instead of your internal product names
5. A checkout that works on the phone the team tested and not on the one the customer is holding

Platform choice is practical. The hosted route takes payments, tax and inventory infrastructure off your team permanently, at the cost of living inside somebody else's rules. A self-hosted store makes sense when the shop needs to behave unusually or when commerce sits inside a larger content site, and it hands you the hosting, the performance and your share of payment-security scope. A custom stack is right when the catalogue or the business logic genuinely exceeds what either supports, and that is a smaller group of businesses than the group that asks for one. We will talk you out of it where a hosted store would win on cost, uptime and payment risk for years.

Search matters more here than almost anywhere, since product and category pages are where discovery happens. Ecommerce SEO is built into the architecture instead of added afterward, and the same applies to how the store reads to consumer audiences arriving from paid channels.

The foundations are included on every build. Ongoing search work is a separate program, because it's continuous rather than a launch task.

Included in every site we ship.

• Clean semantic structure and proper heading hierarchy
• Meta titles and descriptions, schema markup, and an XML sitemap
• Image optimization and performance tuned for Core Web Vitals
• Redirects mapped from every old URL
• Analytics and conversion tracking configured before go-live
• Content structured so a specific claim can be extracted cleanly, which is what AI search engines lift when they cite a source

The site launches ready for search instead of needing remedial work, which is a lower bar than most agencies clear and a lower bar than it sounds.

One technical point belongs in the build conversation and not the search one. Several of the larger AI crawlers will download a page's script files and then decline to run them, so anything your site assembles in the browser after load is not there as far as those systems are concerned. A site rendered entirely on the client can rank in Google and still be absent from the answers ChatGPT and Perplexity produce. Where that content gets rendered is a decision made once, early, and expensive to reverse later.

What sits outside the build is the ongoing discipline. Keyword and intent research, content production, technical SEO beyond launch state, authority building, and monthly reporting. That runs as a monthly program because rankings compound over months rather than arriving on a delivery date.

Foundations shorten the wait without removing it. A competitive term moves in a window measured in months, commonly four to twelve of them, and any firm quoting you page one inside a month has either mistaken luck for method or picked words with no buyers behind them. And once a program is running, what gets reported is enquiries, pipeline and revenue. An impression count is not a result and it will not be presented to you as one.

The two are designed to fit together. Sites we build have the structure a search program needs, so scaling visibility later never means rebuilding what you just paid for. And if you'd rather run search internally or with another partner, everything is documented well enough for them to pick up.

Only if the migration is handled badly, and that is the single most preventable way a strong-looking redesign turns into a lost quarter. Handled properly, rankings usually improve, because the new site is faster and better structured. Done without care, organic traffic slides and the drop often goes unnoticed until the next reporting cycle.

Rankings drop for three reasons, all preventable.

• Deleted content. Pages nobody on the marketing team valued turn out to have been earning steady traffic for years.
• Missing redirects. Old URLs aren't mapped to new ones, so accumulated link equity evaporates and users hit 404s. This is the single most avoidable cause of post-launch traffic loss.
• Broken technical signals. Heading structure, schema, internal linking, and page speed all change at once, and the site reads differently to search engines than it did before.

What we do about it on every project.

1. Record what the site already earns, before a single page moves. Traffic by page, the keyword positions attached to each, and which URLs other sites have linked to. Where no benchmark exists yet, a search audit produces one, and reconstructing that picture after the pages have moved is far harder than capturing it now.
2. Give every retired URL a destination. The redirect map gets built alongside the pages, not assembled in a panic the week of go-live.
3. Make keep-or-cut decisions from data, not from which pages the team happens to like.
4. Preserve the foundations. Heading order, schema markup, the internal link structure and Core Web Vitals, all carried across as named deliverables.
5. Protect local visibility where geography matters, including profiles, citations, and local search signals.
6. Monitor for the first ninety days, so anything that slips gets caught while it's still small.

Knowing what normal looks like afterward is what lets you tell a wobble from a failure. Some movement across the first two to six weeks is expected while search engines recrawl the new addresses and reassess them. A dip that closes inside that window is the system working as designed. A dip still sitting there in week eight is a diagnosis, and it is usually a redirect chain three hops long, a canonical tag still naming the old address as the real one, or a template that lost its heading structure somewhere in the rebuild.

This is handled by the same team that would run an ongoing search program, which is the practical argument for keeping design, development, and search in one place. Split those across two firms and the migration plan belongs to neither of them.

Every site is designed mobile-first, not designed for desktop and then squeezed down. Those produce visibly different results, and for most businesses half or more of visitors only ever see the mobile version.

Responsive web design isn't one layout scaling. It's a system that changes what gets emphasized as the screen changes. Hierarchy shifts, because the third thing on a desktop page is often the first thing a phone user needs. Pacing shifts, because scroll length reads differently on a small screen. Content sometimes shifts too, since a table that works at full width needs a different structure at 390 pixels.

What that means concretely.

• Body copy at or above 16 pixels, since anything smaller makes an iPhone zoom the whole page the moment somebody taps a form field
• Touch targets sized for thumbs and not cursors, meaning a tap area of roughly 44 by 44 pixels with clear space around it
• Forms realistic to complete on a phone, with the right input types and minimal fields
• Performance that holds on a slower connection, not merely on office wifi
• Testing at 390 pixels wide, where most current phones sit, and on real devices before launch, because emulators miss the problems that actually lose customers. Build quality matters here too, since a bloated template or plugin stack is a common cause of poor mobile performance

The failure mode is a site that passes every desktop review and loses money quietly. Nobody on the approving side ever sees it, because approval happens on laptops in a meeting room. Then the analytics show mobile converting at a third of desktop, and the conclusion drawn is that mobile visitors simply buy less. Sometimes that is true. More often the phone version is asking for something a phone cannot comfortably give.

Campaign landing pages get particular attention, since paid media arrives overwhelmingly on mobile and a conversion path that only holds together on desktop is money spent to lose a sale.

If your analytics show mobile converting worse than desktop, that gap is frequently the entire business case for the project, and it's one of the first things we look at during discovery. Where the deeper issue is how people move through the product instead of how it renders, that becomes a question for usability research and not for layout.

Accessibility is designed in from the first wireframe, and every site is built to WCAG 2.2 AA standards. Retrofitting it afterward costs several times more and produces a worse result, because accessibility affects structure and hierarchy, not contrast ratios alone.

What that covers in practice.

• Structure. Semantic markup and a logical heading order, so screen readers can navigate the page the way sighted users navigate it visually. This is interaction design work as much as visual design work
• Keyboard navigation. Every interactive element reachable and operable without a mouse, with visible focus states
• Contrast and type. Colour combinations and sizes that meet ratio requirements, decided during design, not corrected after
• Forms. Properly labelled fields, error messages tied to their inputs, and instructions that don't rely on colour alone
• Interaction. Components that behave predictably, announce state changes, and don't trap focus

On the compliance side, WCAG conformance is the substance and the regulations reference it. For US organizations it's the most defensible position on an ADA claim, and web accessibility litigation has become a genuine and growing risk for commercial sites. For Ontario organizations, AODA obligations reference the same standard.

The ground under this moved recently and being specific is worth more than being reassuring. The United States Department of Justice rule made under Title II of the ADA names WCAG 2.1 AA as the technical standard for public entities, and its compliance date for large entities passed in April 2026 with smaller entities following in April 2027. Ontario's AODA points at WCAG 2.0 AA. Private commercial sites in the US sit outside both, governed by litigation instead of a published rule, which is the worse position of the two because the standard becomes whatever a court accepts. Building to 2.2 AA clears all three. We're not your lawyers, so anything carrying real exposure should go past counsel, but the build shouldn't be where the exposure comes from.

Where a site already exists, an accessibility pass runs alongside a usability audit, since the two surface overlapping problems and one sweep costs less than two.

The side benefit is real. The same structural discipline that makes a site accessible tends to make it easier for search engines and AI crawlers to read, so it earns its place twice. It also overlaps heavily with the UX research that tells you where people actually get stuck.

You own everything outright once the project is paid in full, and the site is configured so non-technical people can run it without a developer.

What your team can do without calling anyone. Publish new pages from approved templates, edit copy, swap imagery, update navigation, add blog posts, manage products and inventory on ecommerce builds, and update structured content like case studies, team pages, and locations.

What has guardrails, deliberately. Brand elements, image dimensions, and structured fields are locked or constrained, so a rushed Friday edit can't break the layout or push an off-brand colour into production.

What still needs us. New page types, structural template changes, new integrations, and anything requiring design or engineering judgment.

On ownership, the transfer is complete. Source and design files, custom code, your content and analytics history, and hosting, domain, CMS, and analytics accounts registered in your name with full administrative access from day one. There are two exceptions, both spelled out in the agreement where you can see them. Unselected concepts stay with us, and third-party assets like licensed fonts, stock imagery, and paid plugins carry their own terms, itemized so you know what you hold.

Nothing runs on a proprietary system only we can operate. Handover includes live training and documentation written for marketers, not developers, whether the site runs on a hosted platform or a custom stack. The test we hold that documentation to is whether somebody who missed the training session can publish a correctly structured page without asking us a question. Where they can't, the handover isn't finished.

One honest limit on the guardrails. A constrained editor is a constrained editor, so occasionally a team wants a layout the component library doesn't offer. That's a small piece of work and not a crisis, and the alternative, meaning an open editor that permits anything, is how a site ends up with six button styles inside a year.

After launch we stay involved another 30 to 90 days depending on project size, included in the engagement. Monitoring, fixes, the edge cases QA didn't surface, and an analytics review once real traffic has told you something. What follows is your choice, whether that's a maintenance plan, an ongoing search program, wider marketing support, or a clean handoff. An agency that makes routine edits difficult is protecting its retainer, not your site.