Award-Winning Web Development
Agency

A web development agency builds and maintains the working software behind a website, meaning the code, the content model, the integrations and the delivery setup that turn a set of approved screens into something the public can use. Design decides what a site should be. Development decides whether it survives real traffic, real editors and real data.

The work sits on a spectrum, and where you land on it should decide who you hire.

1. A marketing site on an established platform. Templates, a content model your team publishes into, forms that reach the right inbox, and a launch that keeps the search positions the old site earned. Weeks of work instead of months, with low engineering risk.
2. A platform build carrying real logic. A store with pricing rules, a site reading live stock from an internal system, a members area, a bilingual estate with two content trees. Still mostly templating and configuration, and the difficulty moves into the data.
3. A custom application. A portal, a dashboard, a quote configurator, an internal tool. Now there are user roles, permissions, validation, error states and a database somebody has to own for years. That is product engineering wearing a website's clothes and it gets priced that way.

What a development team adds over one very good individual is unglamorous and it is the point.

Code review. Nobody merges their own work unexamined. A second developer reads the change before it reaches production, which is how a security mistake and a query that reads an entire table get caught while they are cheap.

Documented handover. Environment setup, deployment steps and the reasoning behind the architecture, written for somebody who has never met us.

Continuity. A person to call in eighteen months who remembers why a decision was made. Solo builds fail here more than anywhere, and the failure looks like a platform update nobody dares apply.

The honest case against hiring us. A brochure site for a local business with a settled offer needs none of this, and a good independent developer will build it for a fraction of what a team costs. If you are one of the software companies already running a product team, a contractor inside your own repository will move faster than any agency. And where the work is continuous instead of a project, an in-house engineer is cheaper by the second year. That gets said on first calls, which is why the engineers we hire onto staff get asked how they would talk a client out of a build. Where the site is one piece of a wider problem, the full set of practices is a better starting point.

Brand Vision has been building since 2018, an award-winning studio with more than 500 projects behind it, run from a Toronto head office with staffed teams in Chicago, San Francisco and Miami. None of that decides a development purchase, so here is the narrower version that does.

Design and engineering are one team instead of two vendors. A developer sits in the design reviews and a designer stays in the build, so there is no wall for work to be thrown over and no week spent decoding what a screen meant. The practical consequence is that nothing gets approved that cannot be built to the standard it was drawn at.

The repository is yours from the first commit. Code lands in an account carrying your name before there is anything in it worth keeping. Same for hosting, the CMS, the analytics property and every third-party service. Access is never withheld as leverage, and there is no point where walking away would cost you the work you paid for.

Senior people, and the same ones from kickoff to launch. The developer who answers you in month three is the one who wrote the thing you are asking about. No junior layer underneath, and no account manager carrying a technical question off to a person you never meet.

We will price the build down. Where a hosted platform does the job, you will hear that even though a custom build would invoice higher. Where the honest recommendation is three restructured templates and a performance pass instead of a rebuild, that is what arrives in the proposal.

Now the ceiling, because a structural advantage is only worth what it applies to. One team helps most where design and engineering decisions collide, meaning marketing sites, stores, portals and the interfaces inside them. It buys you very little on work that is purely engineering, and there are categories we do not claim. Native iOS and Android applications, data engineering, machine learning infrastructure, and anything needing a security certification your auditor names by number are outside what we do, and hearing that in week one is worth more than a capability slide.

Where you should hire somebody else. If what you need is a standing product engineering team, meaning four or more developers shipping continuously against a roadmap for years, that is a hiring problem and not an agency engagement, and agency rates are the most expensive way to solve it. Build the team, and use us for the marketing site beside it. The people who would do the work and work you can open in a browser are better evidence than anything on this page.

Web design settles what a site says, how it is organized and what it looks like. Web development is the engineering that makes it real, and most projects fail at the seam between the two.

Design produces the information architecture, the flows, the visual system and the content plan. Development produces the working thing, meaning the code, the content model, the CMS, the integrations, the performance profile and the security posture. Both are necessary and they answer to different standards. A layout can be beautiful and structurally impossible to build well. A build can be technically immaculate and impossible for anyone to use.

The seam is where the money goes. When a design shop hands files to a separate build vendor, the developer inherits pictures and a long list of unanswered questions. What happens at 1180 pixels. What the empty state looks like. What the error message says. What the layout does when the third field is optional and nobody filled it in. Those get decided by whoever is closest to the deadline, and the site that ships is a negotiation instead of the thing that was approved.

The failure mode is specific enough to recognize. A layout gets approved with a six-word headline and forty words of body copy. The real content arrives at twenty and a hundred and ten. Nothing in the design system says what happens, so the developer picks something, the text clips on tablets, and eight months later a marketer pads a sentence to stop a card collapsing. That gets blamed on the code and it was a specification nobody finished.

Where the split arrangement genuinely wins. A studio and a build shop can work together well, and sometimes have to, since the strongest identity designers are frequently not developers. It works when the specification is genuinely complete, meaning every state, breakpoint, error and empty condition is drawn and written down, and when one party is named as decider up front. Where nobody did that, the seam eats the budget.

We run the design side of the same engagement and the development as one workstream on shared specifications. Developers are in the room while structure is decided, so nothing gets approved that cannot be built properly. Designers stay on through the build, which is why the launched site still matches the one signed off.

Which page you need depends on where you start. With no site and no clear structure, that is a design-led engagement with development inside it. With designs already drawn, or a platform needing functionality, architecture or integrations, you are in the right place. If the brand itself is unsettled, the identity work comes first.

Building the site from the architecture up, so the structure fits how your business works instead of forcing the business into a template's assumptions.

The work that happens before any interface gets built.

• Requirements and technical planning. What the site has to do, which systems it connects to, who administers it, and what has to be true a year from now. One to two weeks, and it is where the expensive mistakes get avoided.
• Content modelling. The data structures behind the pages. Get this right and adding a hundred case studies is a publishing task. Get it wrong and it is a rebuild.
• Architecture decisions. Whether the project wants a hosted platform, a traditional CMS, a headless setup where content store and presentation layer are separated, or a fully custom application, and what each costs in flexibility and maintenance.
• Environment and deployment. Staging, version control and a release process, so changes get tested before they reach the people you are selling to, and so a bad release can be reversed in minutes instead of repaired live.

Then the build itself. Clean, maintainable, commented code. The design system implemented as reusable components instead of one-off pages. Accessibility and performance handled throughout instead of remediated afterward. Integrations built and tested against real edge cases and never assumed to work.

The content modelling failure is worth describing, because most readers have lived through it. A site gets built with a single rich-text field per page, which is quick and feels flexible. Eighteen months later somebody wants case studies filtered by industry and service, and there is no industry field on ninety published items, so three weeks go into retyping content already on the site. Structured fields cost an extra day at the start.

The difference between custom web development and assembling plugins shows up in year two. A plugin stack solves today's requirement and accumulates conflicts, security exposure and update risk, and the arithmetic is unforgiving, since thirty plugins releasing four updates each in a year is a hundred and twenty chances for something to break on a site nobody is watching. A properly architected build absorbs new requirements without fighting itself.

The honest limit on all of it. Custom is the wrong purchase where the requirement is genuinely ordinary. A five-page site for a settled local offer gains nothing from a bespoke content model, and the cheaper route is what you will hear recommended.

Every project ends with documentation your own developers or whoever comes after us can work from, which is the part most agencies skip and the part that decides whether you are genuinely free to leave.

Four established platforms plus custom code, and which one gets recommended follows your requirements and never our preferences. Every one of these suits some businesses and fails others, so the documented limits matter as much as the strengths.

• Webflow. Marketing sites where the design has to be exact and a non-technical team publishes on its own. Clean output, fast iteration. The limits are documented, so we design around them. A collection list renders 100 items before pagination is enabled, a single page tolerates 40 collection lists with 10 nested inside them, and nothing runs on the server, so real back-end logic sits in an outside service.
• WordPress. Content-heavy sites, established editorial workflows, complex user roles, or cases where a plugin ecosystem carries real weight. Five roles ship built in, from administrator down to subscriber, and anything past that is a capability plugin somebody maintains.
• Shopify. Most ecommerce, where payment, tax, shipping and inventory infrastructure should be someone else's maintenance burden. The limit that catches merchants out is options and not variants. There are 2,048 variants available and only three options, so anything sold across size, colour, material and finish at once needs another model.
• WooCommerce. Stores needing control over how the shop behaves, or commerce inside a larger publishing build. Freedom over product logic and pricing arrives with the hosting bill, the update schedule and your share of card-data compliance scope.

For custom work the front end runs in React, Vue and Next.js, and the back end across Node, Python and Django, PHP and Go. Headless setups pair a modern front end with Sanity, Contentful or Strapi, where headless means the content store and the presentation layer are separate services talking over an API.

One architectural rule sits above the stack choice. Several of the biggest AI crawlers pull a script file down and never run it, which means content the browser assembles after load does not exist for them. Marketing pages therefore default to server-rendered or pre-built output, and browser assembly is kept for screens behind a login where discovery is irrelevant.

The questions that decide it are practical. Who updates content and how often. What has to integrate, and whether those systems have real APIs. How much traffic is coming. Whether you have engineers who will inherit this. And what budget exists for maintenance as well as the build.

A marketing team publishing weekly with no developers needs a different answer from a product company with an engineering function. The reasoning gets explained plainly so you can argue with it, and you will hear when a hosted platform is right even though a custom build would invoice more.

Applications are a full part of what we build, and the discipline is genuinely different from producing a marketing site.

A website mostly presents information. A web application is a working product people use to get something done, which means state, permissions, data validation and error handling all become primary concerns instead of details.

What we build in this category.

• Customer portals where clients log in to see their own data, documents or account activity
• Dashboards and reporting tools that turn a database into something a non-technical person can actually read
• Configurators and calculators, including quote builders and product configurators with real pricing logic behind them
• Booking and scheduling systems with availability rules, notifications and payment attached, which is where clinics and practices put most of their engineering budget
• Internal tools, the operational software a team runs on that nobody outside the company ever sees
• Member and subscription areas with tiered access and billing

The work starts with the users and the rules and not with the screens. Who does what, what they are allowed to see, what happens when two people edit the same record, and what the system does when an integration is down. Those decisions shape the interface design instead of following it.

Concurrent editing is the example worth making concrete, since it is the requirement clients never raise and almost always have. Two staff open the same order at the same moment. One changes the shipping address, the other changes the quantity, and both press save. With no rule in place the second save silently overwrites the first, and nobody finds out until a customer complains. The rule can be a lock, a warning or a merge, and choosing costs an hour in week one or a fortnight in month nine.

The failure mode for internal tools is different and far more common. They get built by whoever was available, with no research and no error states, which is why so many of them are actively unpleasant to use by people who have no choice in the matter. Because design and engineering sit in one team here, an application gets the same usability rigour as the marketing site promoting it.

When not to buy this from an agency. If the application is the product you sell, and its roadmap runs for years, hire engineers and own it, because every month of agency involvement is a month your own team is not learning the system. What we will happily do is build the first working version, so you can find out whether the idea earns a permanent team before you go and hire one.

Integrations get scoped as part of every build instead of being treated as a phase-two problem, because a form that does not reach your pipeline is a broken form regardless of how it looks.

Common connections.

• CRM. HubSpot, Salesforce, Pipedrive and others, with fields mapped so a submission arrives as a properly attributed lead instead of an email somebody forwards manually. This matters most in longer business-to-business cycles, where one buyer touched six times across four months has to stay a single record
• Payments. Stripe, Shopify Payments and processor-specific flows, including subscriptions and invoicing
• Marketing and email. Automation platforms, list management, and event tracking that matches the reporting your marketing team runs on, which means leads and pipeline and never impressions
• Scheduling and booking, with real availability rules instead of a form that hopes for the best
• Analytics and conversion tracking, configured before launch so measurement starts on day one
• Internal systems through APIs, or through middleware where a platform's API is limited or badly documented

The design work happens before any code. What data has to move, in which direction, how often, and which system is the source of truth when two of them disagree. That last question is the one that gets skipped, and it is the reason so many integrations quietly produce duplicate records.

Three constraints decide how hard a given connection actually is. Whether the API is documented and stable, or an endpoint somebody wrote once and never revisited. What the rate limit is, meaning how many requests the far end accepts in a window before it starts refusing them, which is what turns a nightly sync of forty thousand records into a queued job instead of a simple loop. And whether the two systems agree on identity, since a contact keyed by email address in one place and by an internal number in the other will duplicate on the first person who changes jobs.

We also plan for failure, because integrations fail. What the user sees when a third party times out, whether the submission is queued or lost, and who gets alerted. The pattern we default to is writing every submission to your own database first and pushing it onward second, so an outage at the far end costs you a delay and never a lead.

On a redesign, existing integrations get inventoried during discovery and migrated deliberately. A new site that silently drops enquiries into a void is a failure no design award offsets, and the version we meet most often is a launch where the form works perfectly and the notification address belonged to somebody who left the company.

We build new stores and take over existing ones, and the development work reaches well past the storefront. Most of it lands on a Shopify build or a WooCommerce store, and occasionally on custom code where the business logic exceeds what either one models.

Ecommerce website development has to serve the customer and the operator at once. Customers need to find products, compare options, build confidence and check out without friction. The team behind it needs merchandising control, inventory accuracy, fulfillment that works, and reporting that reflects reality.

Where the engineering effort goes.

• Product architecture. Variants, options, bundles and pricing rules, modelled properly so the catalogue scales without manual workarounds
• Cart and checkout. Steps stripped back until only the necessary ones remain, guest purchase enabled, and the tax, shipping and payment rules tested against the awkward cases instead of the happy path
• Inventory and fulfillment. Syncing with your ERP, your warehouse or a third-party logistics provider, so stock levels are accurate instead of approximately accurate
• Subscriptions and recurring billing where the model requires it
• Performance under load, because a store that slows down during a promotion loses money at exactly the wrong moment
• Tracking and attribution. Abandoned cart flows, conversion events, and the analytics that tell you what is selling and why

Two platform constraints shape most of this before a line of code is written. A hosted platform hands you a checkout that converts well and will not let you rebuild it below the top plan, which is a sound trade for most merchants and an impossible one for a few. A self-hosted store hands you the checkout and puts the hosting, the caching, the updates and your share of card-data compliance scope on your side of the line, which is a real operating cost and not a footnote.

We also take on stores we did not build. Common requests are performance remediation, checkout conversion work, replatforming from a system a business has outgrown, and untangling a theme modified by four developers over six years, where the usual finding is that one override has been written three times in three places and two of them are still running.

Discovery happens on category and product pages far more than on the homepage, which makes the address structure a commercial decision. The ecommerce SEO decisions, meaning which filter combinations earn an indexable address and which get blocked outright, belong in the build instead of in a cleanup two quarters later. How a first-time visitor from a paid ad reads the store gets planned beside it, since consumer audiences decide faster and forgive less than trade buyers do.

Your team runs the publishing, because the content architecture is designed around how your organization works and then constrained so a routine edit cannot break the design. A CMS that technically allows anything will eventually contain anything.

What that involves.

• Content models. Structured fields for each content type instead of one open rich-text box. A case study has a client, a category, a result and a set of images, and modelling it that way lets the same content appear correctly in three places.
• Reusable components. A library of approved sections editors assemble pages from, so a new page is a composition task instead of a design task.
• Guardrails. Locked brand elements, defined image dimensions and constrained field options. A Friday afternoon edit cannot push an off-brand colour into production or collapse a layout.
• Permissions and workflows. Who can draft, who can publish, and what needs review first. Large publishing operations need this, and universities and school boards need it most, since forty departments with edit rights is a governance problem before a design one. Small teams do not, and we will not build approval chains nobody asked for.
• Preview and staging. Seeing a change in context before it goes live, which sounds obvious and is missing from a lot of builds. On hosted platforms it comes with the subscription. On custom stacks it has to be engineered.

What your team can do afterward. Build pages from approved sections, rewrite copy, replace imagery, reorder navigation, post to the blog, and run stock on ecommerce builds. What still needs us. New content types, structural template changes, and new integrations.

Two constraints are worth pricing before you pick a platform. Hosted builders charge by editor seat, so a fifty-person marketing department is a licence conversation as much as a permissions one, while a self-hosted CMS gives unlimited accounts and puts review discipline entirely on you. And a second language doubles the editorial surface and the failure surface with it, since a component existing only in English quietly leaves a French page half-built.

You can spot the failure mode from outside the company. Pages start carrying inline styles because an editor could not get the spacing they wanted from a component. Six versions of the same button appear. Somebody pastes from a word processor and brings a font with them. Inside a year the site is visually inconsistent and nobody did anything wrong, because the system permitted it.

Training happens live, and the documentation is written for the people publishing instead of for developers. If routine publishing requires a support ticket, the content architecture was built for the agency's convenience instead of yours.

We find what is actually slowing the site down for real users, then fix it in order of impact instead of optimizing for a score. A perfect Lighthouse number on a page nobody converts on is a vanity metric.

Where performance problems genuinely come from, ranked by how often we meet them.

1. Images. Usually the largest offender. Wrong formats, no responsive sizing, and files uploaded at ten times their display size.
2. Third-party scripts. Analytics, chat widgets, heat maps, ad pixels, and the tag manager nobody has audited in two years. Frequently more of the load than the site.
3. Fonts. Blocking loads, too many weights, and layout shift when the fallback swaps out.
4. JavaScript. Bundle size, unused code shipped to every page, and work on the main thread that does not need to be there.
5. Server and delivery. Hosting tier, caching strategy, CDN configuration, and database queries that were fine at launch and are not now. On a hosted builder or a hosted store this layer is handled. On self-hosted builds it is yours to get right.
6. Plugin and theme bloat on platform builds, where each addition brought its own stylesheet and script.

The targets are the three Core Web Vitals and the numbers are published. Largest contentful paint at or under 2.5 seconds, the point where the biggest thing on screen has finished drawing. Interaction to next paint at or under 200 milliseconds, which is how long a tap waits for a response. Cumulative layout shift at or under 0.1, which is how far the page moves while somebody reads. All three are also ranking factors, which is the smaller half of the reason to care.

One distinction decides whether a performance report means anything. A synthetic test runs one page once on a simulated connection. The numbers Google acts on come from real Chrome users at the 75th percentile of visits across the preceding twenty-eight days. A clean synthetic score beside a failing field score means real visitors get a worse experience than your dashboard reports, ordinary on image-heavy pages carrying a decade of tags.

On new builds, performance budgets get set during development instead of measured afterward, meaning a ceiling per template for page weight, script weight and request count, checked at release. On existing sites we start with a diagnostic, because a fix list is worthless until you know which two items cause most of the problem.

The commercial argument lands harder than the ranking one. Every visit you bought at auction is thrown away by the same delay, so this work pays back against your paid traffic before it pays back against search.

Frequently, and the first step is always an assessment and never a quote. Inheriting a codebase without looking at it is how a two-week fix becomes a three-month excavation.

What the assessment covers, over three to five working days once we have access.

1. Code quality and structure. Whether this is organized and documented, or assembled by whoever was available at the time. That one answer usually settles whether building inside it is a sane plan.
2. Dependencies. Which plugins, packages and libraries are in play, how many are abandoned, and how far behind the versions have fallen. A package unmaintained for three years is a decision waiting for you and not a detail.
3. Security posture. Known vulnerabilities, exposed endpoints, and whether anything has already been compromised. This is also where we find the administrator account still belonging to a developer who left in 2021.
4. Performance baseline. Where the Core Web Vitals actually sit for real visitors, and what is causing it.
5. What you own. Repository access, hosting credentials, domain control and licences. This is where uncomfortable discoveries happen, and the worst of them is a domain registered to an agency that stopped answering email two years ago.

Then you get a straight answer. Sometimes the foundation is sound and we will work inside it happily. Sometimes the build is fragile enough that every change carries risk, and continuing to patch it costs more over eighteen months than replacing it would.

The test we apply is not elegance. It is whether a change can be made safely. If a developer can set the project up on a laptop, make a small edit, and see the result without breaking two other things, the site is workable however the code reads. If nobody can run it anywhere except production, that is the answer, and it is the same answer whether the code is tidy or not.

The counter-argument deserves stating, because it is often the correct one. A rebuild resets every relationship the current site has, meaning its search positions, its redirects, its tracking history and the habits of the people who use it every day, and that reset carries a cost nobody itemizes in a proposal. So we will not recommend a replacement because replacements bill better. Plenty of inherited sites need a performance pass, a security cleanup and three restructured templates instead.

Where you want the diagnosis before committing budget, the assessment is available on its own as a scoped audit, and whatever it turns up carries into the next decision.

Maintenance runs as a monthly program, and the argument for it is risk more than convenience. A site is a running system with dependencies that age, and unmaintained platforms do not stay still, they degrade.

What a maintenance engagement covers.

• Platform, plugin and dependency updates, applied on staging and tested before production
• Security monitoring and patching, with a response when a vulnerability gets published against something in your stack
• Backups and recovery, verified and not assumed, because an untested backup is a hope
• Uptime and error monitoring, so problems get caught before a customer reports them
• Performance checks, since sites slow down gradually as content and scripts accumulate
• Accessibility upkeep, because new content introduces fresh problems that were not there on launch day
• A monthly allocation for content changes, small enhancements and ongoing design support

The accessibility line has moved from good practice toward obligation, which is worth knowing before you decline it. Ontario's Accessibility for Ontarians with Disabilities Act points public-facing sites at WCAG 2.0 Level AA. In the United States, the Americans with Disabilities Act, Title II, now reaches public entity websites through a federal rule naming WCAG 2.1 Level AA, and the deadline for larger bodies has already gone by, in April 2026, with the smaller ones following in April 2027. A site that conformed on launch day slips out of conformance the moment somebody publishes an image with no alternative text. We are not your lawyers and anything carrying real exposure belongs with counsel, but the slippage itself is a maintenance question.

Plans are scoped to how actively the site changes. A stable marketing site needs a fraction of what a store shipping weekly does, and pricing should reflect that instead of charging a flat fee for a service level you never use.

Nothing about the build depends on you buying maintenance afterward. The documentation is complete enough for your own developers or a different agency to pick it up, and we will make that transition clean if that is where you land.

The honest case for staying. Most of what a maintenance plan does is prevent things you would otherwise have experienced, which makes it the hardest line item on any invoice to defend, since a good month looks identical to a month where nobody did anything. Clients who keep it tend to keep it because problems get resolved before they notice them, and that is the only real argument for it.

Focused builds run $7,000 to $15,000. A complete marketing site sits between $15,000 and $30,000. Applications, portals and complex ecommerce begin above $50,000.

• Microsite or focused build, three to five pages. $7,000 to $15,000, for a campaign, a launch, or a narrow offer.
• A complete marketing build, usually six to ten pages. Between $15,000 and $30,000, with the typical project settling around $20,000.
• Webflow builds. Starting at $10,000, with custom interactions and a CMS your own team drives.
• Ecommerce. Scoped individually, driven by catalogue complexity, integrations and fulfillment requirements.
• Applications, portals and platforms. From $50,000 upward, driven by the number of user roles, business rules and systems involved. A property launch portal with broker logins, price lists and floor-plan releases is the shape this usually takes.
• Integration and API work. Priced per connection, since a documented REST API and a legacy system with no API at all are different orders of difficulty.
• Maintenance. Monthly, scaled to how actively the platform changes.

What actually drives development cost is not page count. It is the number of distinct states and rules the system has to handle. Two roles, three integrations and an approval chain will outprice forty pages of straightforward content every time. Doubling the pages on a template already built adds days. Adding a second user role adds a permissions model, a second set of screens, a second set of empty states and a second set of tests.

Then the calendar, since weeks and money move together. Requirements and architecture take one to two weeks. Build runs three to six weeks on a marketing site and two to four months on an application. Testing and launch take one to two weeks. Almost every overrun we have seen came from content arriving late or from a decision nobody had the authority to make, and neither of those is a development problem.

The other honest driver is the condition of what already exists. Building fresh is often cheaper than working inside a codebase that fights back, which is why the assessment described above comes before a number.

Where the real budget is two or three thousand dollars, none of these bands apply, and that gets said in the opening conversation instead of a diluted version of something costly being sold to you. Proposals are itemized line by line, so you can challenge any single component or strike it out. Start with a call and you will know which band your project falls into before anything gets signed.

Everything belongs to you once the invoice is settled, and the handover is a documented transfer and not a list of passwords pasted into an email.

What transfers.

• The code, in a repository you own, with commit history intact
• Documentation. A README that actually explains the project, environment setup, the deployment process, and the architectural decisions somebody new would need to understand
• Every account in your name from day one. Hosting, domain, CMS, analytics and any third-party service, with full administrative access
• Design and source files, plus the component library and content model documentation
• Training, live and recorded, for the people who will run it, whether that is your marketing team or your own engineers

Two exceptions exist and the agreement states both of them plainly instead of hiding them in a schedule. Unselected concepts stay with us. Licensed fonts, paid plugins and stock imagery arrive with somebody else's terms attached, so each one is itemized and you can see what you own outright beside what you license. That distinction gets skipped constantly and it matters, since a font licence written for one domain and a hundred thousand monthly visits becomes a problem in the month a campaign finally works.

There is no proprietary layer here that only our team knows how to operate. There is no agency-owned CMS, no hosting login held on your behalf, and no stretch of code that only makes sense with us explaining it.

The test we hold handover to is whether a competent developer who has never spoken to us could clone the repository, get it running locally, and ship a change. If they cannot, the handover is not finished. In practice that means a README somebody has followed from a blank machine, environment variables listed with what each one is for, seed data or a sanitized copy of the database, and a short note naming the three decisions a newcomer would otherwise reverse by accident.

The transfer itself runs over roughly two weeks instead of arriving in a single meeting. Accounts move across and get confirmed one at a time. Training runs live with the people who will use the system and is recorded for whoever joins later. Then we stay reachable through a support window while real traffic finds the edge cases testing did not.

That standard is also why ongoing work with us stays a choice instead of becoming a consequence. If you are inheriting a site from somebody else and none of this ever happened, tell us what you have and the first job is establishing what you actually own.