9 stumbling blocks in website development - and how to avoid them with Drupal

Confirm that Drupal is the right CMS for your needs. Drupal is powerful, but if your goals can be achieved with a simpler solution, recognize this early on. Conversely, if Drupal is the right solution, make sure the project leverages its strengths (e.g. complex workflows, robust content modeling) in service of your business goals.

Have an open discussion about the budget before development begins. Prioritize between your"must-haves" and"nice-to-haves". "Remember that you probably won't be able to realize all your wishes within the budget, so think about what you absolutely need from the start and be as clear as possible about the budget" [2]. It's common to see "a small, short-term budget with a vision for immediate, amazing results" [2] - setting you up for disappointment. Instead, align features with what the budget can realistically deliver. If the desired scope is unachievable, either reduce or increase the budget before work begins.

During the discovery phase, assign each important function to a business objective. This will ensure that you build something that delivers real value. A project that is not aligned with business goals can drift into nice-to-have but superfluous features. Both the client and the agency should clearly understand why each feature is being developed. This also helps when difficult budget decisions need to be made - you can cut or defer anything that doesn't contribute to the core objectives.

Consider the budget as a living parameter. As you refine the requirements (or as new needs emerge), review the budget. It's far better to have a serious conversation about reducing the budget mid-project than to quietly take on additional features until costs skyrocket. Transparency builds trust here - nobody likes surprise bills. In agile projects, every sprint planning is an opportunity to check scope against spend.

The client organization must designate one person as the primary project owner (sometimes called the product owner or stakeholder representative). This person should have the authority to make decisions (or obtain approvals quickly) and have the ability to provide timely feedback. They are the first point of contact for the agency. With a dedicated person in charge, "communication can be streamlined" [4] and is not fragmented.

It is not enough to appoint someone; they need the support of senior management to make decisions. Make it clear internally that this person speaks for the project. When questions about scope or design arise, the project owner's word should carry weight. This avoids an approved decision being later rejected by someone who was less involved. An empowered project owner can approve changes, resolve issues and move the project forward without unnecessary back and forth.

The project manager should be involved from day one (requirements, planning) to the start. They regularly take part in status meetings or sprint demos and are ready to clarify requirements or resolve minor disputes on the spot. Quick, decisive input keeps the momentum going. One technical article states that having a point of contact for the customer "makes decision making faster and more efficient, reducing the risk of missed deadlines or project scope overruns." [4] This high availability is crucial - if the owner is frequently unavailable, bottlenecks in decision-making will occur again.

Of course, the project owner still gathers input from various departments (managers, end users, etc.), but this should be done behind the scenes . Internally, they summarize all feedback into a clear direction for the agency. This way, the development team doesn't have to juggle many voices. As one mobile app agency advises, "appoint a single, dedicated point of contact on your team to prioritize the feedback and requirements of the entire team." [5]
The agency then works with this one voice, confident that they are representing the collective interests of the client.

Agree on how decisions are to be made and documented. For example, when new feature requests are received, the project manager will evaluate them (perhaps after consulting with stakeholders) and then provide the agency with a clear yes/no or prioritization. In this way, ambiguities are avoided. If everyone knows who is responsible for the decisions, confusion and delays are avoided.

Regular meetings (weekly status meetings, sprint reviews, etc.) are important. However, don't wait for scheduled meetings to communicate - if you recognize a risk or need clarification, speak up immediately. Proactivity means that you address questions or warning signals at an early stage. One recommendation is to hold regular, proactive meetings to identify issues before they escalate, rather than passively waiting. These touchpoints build trust and keep everyone involved in the loop.

Both the client and the agency should raise concerns as soon as they arise. If the agency is facing a potential delay or problem, they should raise it and suggest solutions - not keep it quiet. If the client is not happy with something or their priorities change, they should inform the agency immediately. By being proactive, you can adjust plans together instead of having unpleasant surprises at the last minute.

Communication is not just about talking, but also about listening. In meetings or when reading emails, listen carefully to the other side's arguments and ask clarifying questions. Show that you understand the other side's point of view. Effective communication "requires active listening, empathy and the ability to convey complex ideas clearly". By "actively listening to their clients' needs and concerns, agencies can better adapt their strategies and deliver solutions that meet and exceed expectations." [8] This goes both ways. Clients should also listen to the agency's expert advice

Remember that there are people on both sides. Agencies should empathize with the client's business constraints (e.g., a firm launch date, budget limitations) and the client should empathize with the development challenges (e.g., unforeseen technical hurdles). "When problems arise, address them with empathy and an open, productive dialog."[8] For example, if a feature is delayed, an empathetic client won't immediately blame incompetence - they'll ask what went wrong and how to fix it. Similarly, an empathetic agency acknowledges the customer's frustrations and looks for solutions rather than getting defensive.

Foster a culture where client and agency employees feel like an extended team rather than a vendor or client. Use collaboration tools (shared Slack channels, project boards) and even occasional in-person workshops where possible to build rapport. When everyone feels like they are pulling in the same direction, there is a greater incentive to be responsive and collaborative. For example, when a problem arises, both sides roll up their sleeves to solve it instead of pointing fingers.

A proactive agency will sometimes anticipate client needs that the client has not expressed. For example, send them an analysis report or training refresher before the client asks for it if you suspect they might need it. Similarly, a proactive client might provide content or approvals before the deadline, for example, if they know the development team will need them soon. These thoughtful actions show respect and build goodwill.

Invest time in a detailed scope definition at the start of the project. This could be a requirements document, a functional specification or a backlog of user stories - the format may vary, but it should clearly outline what is (and implicitly what is not) part of the project. Both the client and the agency should sign off on this. A clear scope is the North Star of the project. If a requirement comes up later, you can quickly determine whether it is part of the scope or an add-on. This clarity up front ensures that everyone knows what they have promised. Remember: "If the project requirements are not clearly defined from the start, misunderstandings can easily arise and the customer may request additional features or changes as the project progresses." [10] Clarity at the beginning prevents a lot of trouble later.

It is unrealistic to say "never change". Scope changes can and will happen - priorities shift, or you discover something new during development. The key is to deal with changes consciously. Agree on a process: for each new request or significant change, the team reviews the impact on schedule and budget and approves (and documents) the change before the work is done. This may include creating a change request and getting client approval for additional cost or time. This way you stay in control. For example, if the client asks to add a forum area that is not in the scope of the project, don't do it silently (and blow the budget), but charge the estimate for it and either charge it to another feature or treat it as additional work that will be billed extra. This way , nothing is unknowingly added "for free" - everyone involved stays on the same page. It is also advisable to keep a log of all scope changes and approvals to avoid disputes.

Not all functions are the same. Work with stakeholders to determine which requirements are critical to the rollout and which are optional or can be introduced later. As pressure mounts to expand the scope, you can refer back to this prioritization. Perhaps an "extra" feature can replace another lower priority item rather than simply adding to the stack. This approach (sometimes called the MoSCoW method - Must, Should, Could, Won't) helps negotiate scope: as new ideas come up, you have a basis for saying, "If we add this, maybe we can remove or delay that." This keeps the project focused on delivering the core value.

Many scope problems are actually expectation problems. The client may not realize that a "quick change" is actually a significant effort, or the agency may not have clarified what impact the changes will have. Educate each other."Setting realistic expectations with the client from the outset" by outlining the goals, constraints and risks of the project, they are less likely to ask for spontaneous additions later [10]. If everyone involved understands the effort involved, they are more reluctant to simply change the plan. Explain the concept of scope creep to non-technical stakeholders; once they see how it can jeopardize the project, they will be more disciplined about requesting changes.

If you use an agile approach (which can react more flexibly to changes), you should keep an eye on the scope within each iteration. Agile does not mean infinite scope, but prioritized scope. Changes can be planned for future sprints instead of being incorporated ad hoc into the current sprint. Keep the product backlog in order and only commit to what the team can achieve in a sprint. This prevents the scope from getting too big in the middle of the sprint. Also, maintain a clear definition for each feature so that the scope does not expand within a single user story.

This is tough, but important. If a requested change is detrimental to the success of the project (e.g., blows up the timeline for an immovable event), it's okay to push back and offer alternatives. For example: "This feature is a great idea, but if we add it now, we risk our launch date. Let's plan it for phase 2 so we can get it right. Customers appreciate honesty when it's focused on protecting their goals. Every "yes" should be an informed yes (knowing what it entails). Sometimes a polite "no for now" is the best way to secure the project.

At the start of the project, you should carry out an exploratory phase . This can include workshops, stakeholder interviews, user research and a review of existing documentation. The aim is to work out the explicit requirements (what exactly needs to be done) and also uncover any implicit expectations that have not been expressed. Document everything - functional requirements, design preferences, technical constraints, user personas, success criteria, etc. If you take an agile approach, this will translate into a well-maintained product backlog with user stories and acceptance criteria. In a traditional approach, this could be a detailed specification. The format is less important than the clarity. Make sure everyone involved agrees on what each key feature or page should do/what it should look like. It's often helpful to give examples or references (e.g. "The client likes the way website X does Y") to avoid confusion. For example, instead of a vague reference like "modern gallery", you can specify "a searchable photo gallery where users can filter by category". Being precise up front saves time later.

Words can be interpreted in many ways, so you should supplement the written requirements with wireframes, mockups or prototypes. A rough layout or click-through prototype can trigger important feedback - "Oh, I thought the login was on the homepage, not on a separate page." It's much easier to adjust a sketch or prototype than to rework the code. It also gives the client a concrete idea of the final product early on and allows them to align their expectations with what is feasible.

Don't let weeks go by without interaction between the customer and the team. Arrange regular meetings (weekly status meetings, sprint demos, etc.) and define points of contact. Perhaps the project manager sends a weekly email about the project's progress, or the client has a bi-weekly appointment for a demo. Regular communication offers the opportunity to eliminate ambiguities and improve understanding. It also keeps the customer involved so that they can provide timely feedback before things get out of hand.

Keep a living requirements document or user story tracker. Whenever a requirement is clarified or changed, update the documentation and inform all stakeholders. For example, if the customer says during a sprint review: "Actually, we need two types of user roles, not one", record this in the requirements. This way, the whole team is on the same page. This documentation can be as simple as meeting notes or as structured as an updated specification - the important thing is that it is written down and shared. More communication is better than too little.

Technicians and business people often speak different "languages". It is important to translate technical jargon into business terms and vice versa. If a requirement is phrased in business terms, the team should rephrase it in technical terms to confirm understanding. When explaining a constraint or alternative to a customer, put it in a context that is meaningful to the customer (e.g. "If we do X, it might slow down the website by Y% for your users, so maybe we should consider Z instead"). Clear, jargon-free communication prevents things from getting lost in translation.

Create an environment where team members feel comfortable asking "stupid questions". If something is unclear, it needs to be clarified - don't make assumptions. Project managers should actively ask the client, "Does this capture exactly what you need?" and ask developers, "Do you understand what the client means by this requirement?" Encourage the client to ask questions too - they may not be familiar with a term like "taxonomy" in Drupal; clarification can ensure they are setting the right expectations. It's much better to resolve an ambiguity immediately than to discover it after development. As the saying goes: "Measure twice, cut once". When it comes to requirements, clarify twice (or more), program once.

For each requirement or user story, agree on what a satisfactory conclusion looks like. These are basically the acceptance criteria. For example, "The administrator must be able to upload a CSV file of products and list them on the "Products" page within 1 minute. With such information, the developer knows exactly what to build and the customer/tester can easily verify it. This closes the interpretation gap where the developer may say, "It's done," but the customer says, "That's not what we wanted." Everyone is working towards the same, clear goal.

Formulate a content strategy long before the launch - ideally during the discovery phase. Determine the purpose of your content and how it meets the needs of users and company goals. Determine what content exists, what needs to be updated and what new content is required. For example, if you are launching a new section on the website, who will write these pages? Do you have guidelines for the brand message? Also consider content hierarchy and information architecture (IA) - Drupal is great for structuring content with content types, categories, tags etc, but you need to plan these structures around your content strategy. Involving a content strategist or your marketing team will pay dividends here. They can help ensure that the website content is user-focused, brand-appropriate and SEO-friendly.

If you have an existing website, carry out an inventory of the content. List all pages, blogs, files, etc. Assess which content should be migrated, which is no longer needed and which needs to be rewritten. This will prevent surprises later on (e.g. discovering hundreds of pages you didn't take into account). A content audit also helps you to identify gaps - e.g.: "We have product pages but no FAQs; we need new content for this area. With Drupal, consider how existing content will be incorporated into the new website structure. For example, an old news page could become Drupal article content types with fields for author, date, etc. This mapping is crucial for the migration.

Content migration can be manual, automated or a mix . Automated scripts can help move large amounts of structured content (Drupal has migration modules and tools), but often the content needs to be cleaned up and restructured. Don't assume that automation will do everything automatically . "Redesign proposals always assume that 'migration' means automatic migration.... Unfortunately, this is rarely a comprehensive option." [14]

Your new Drupal site may use new layouts and fields that don't match the old site one-to-one, which means human intervention is required. Decide on an approach: Will developers write migration scripts? Will editors enter the content manually? Often it's a hybrid (e.g. automatic migration of basic fields, then manual correction of formatting or addition of metadata). In any case, you should allow sufficient time and resources. Be warned that a CMS project can fail if the migration of content is not planned - it can take longer than the development itself if it is not planned. Start the migration as early as possible, even on a test site, to estimate the effort involved.

Content does not only consist of text sections. It also includes all the "hidden" elements that are important for search engines and accessibility: Meta titles, meta descriptions, alt tags for images, URL redirects from old to new URLs, link cross-references, etc. These are often overlooked until the very end. An article on content migration points out that the commonly forgotten items are those that " optimize the site for UX, SEO, and ADA compliance" [14] - things like optimized images, alt text, meta descriptions, proper headings. Make these items part of the content checklist. Also plan a redirect strategy for SEO: if the URL structure changes with the new Drupal site, prepare 301 redirects so that your Google rankings and user bookmarks are carried over.

If you neglect this, you may experience a sharp drop in traffic after launch. Drupal has modules (like Redirect) to manage this, but someone needs to configure them with the old-to-new URL mappings.

If new content needs to be written or existing content needs to be revised, define the responsibilities and deadlines for these tasks. Often the client's team is responsible for writing content (as they know their business best), but they may not realize how long good copy takes. Incorporate content milestones into the project plan - for example: "Draft all service pages by date X; complete by date Y". Treat them with the same importance as development milestones. If necessary, the agency can help write the copy or recommend hiring a professional writer to take the burden off the client. The most important thing is not to put off writing content until just before launch.

Use real or representative content as early as possible when building the Drupal website. This helps to test the design with real text/images (instead of Lorem Ipsum) and gives content creators a sense of how much content is needed. Set up a test page where content can be added and revised. Drupal's flexibility with fields and templates is great, but only if the content fits well. If you notice during staging that a certain page looks empty or a certain heading is always too long for the design, you can adjust either the content or the design accordingly. Provide content authors with templates or guidelines for each content type (e.g. "blog posts should have a 150 character excerpt and an 800 x 600 image"). This will ensure that content is created in a format that is consistent with the design and functionality of the website.

However you migrate content, plan a quality assurance process for each page of the new website. Often, each piece of content will need to be revisited - perhaps to correct formatting, add a tag, or just to make sure it looks right. It's common for "each page to need to be reviewed and edited two or three times - or more - before launch." [14] You might migrate the page first, then format it, and then make more changes after the review. This is normal, but if you haven't scheduled time for this, it becomes a crisis. Beconservative ( even pessimistic) in estimating the time needed . If you finish early, that's great - but if not, you'll be glad you had a buffer. If possible, distribute the content loading to a team of trained editors or to the client's staff (with training, see next pitfall).

Don't think of UX as something you add on at the end. Involve UX designers or at least UX thinking early on in the project. Create user journeys and personas in the planning phase: understand who your users are and what they need to achieve on the website. On this basis, you can make decisions about the navigation structure, page layout and functions. Simplicity and clarity should be the guiding principles. Use wireframes and prototypes to test the user flow before actual development. If possible, conduct usability tests on prototypes - even a quick hallway or remote usability test with a few target users can reveal glaring issues (e.g. they couldn't find the "Contact Us" page or assumed an element was clickable, which wasn't the case). Keeping these issues in mind when designing will save you from frustrating your real users later. Remember, happy users are more likely to convert, come back and recommend your website to others - UX has a direct ROI.

An important part of UX today is adapting to mobile users. Make sure your designs are responsive and mobile-friendly. Test the website on different devices and screen sizes. A common problem is a website that looks good on a large screen but becomes a maze on a smartphone. Given that the majority of internet traffic now comes from mobile devices , a poor mobile UX is the death knell. Performance is another UX factor - optimize for fast load times (slow pages drive users away). Drupal has caching and optimization modules; use them and follow best practices (optimizing images, minimizing scripts).

There are established conventions for a reason. For example, make sure navigation is clear and consistent, that buttons look like buttons, that links are distinguishable, that forms are properly labeled and include error messages, etc. Don't reinvent the wheel unless you have a good reason - users expect certain behaviors (Jacob's Law in UX states that people spend most of their time on other websites, so they expect your website to work like others). A user-centered approach means that you are guided by the mindset of the user*, not that of your internal team. Get feedback on the UX throughout the project; don't just rely on internal opinions.

Accessibility should be a requirement, not a nice-to-have. Use the Web Content Accessibility Guidelines (WCAG) as a reference - aim for compliance with WCAG 2.1 AA as a minimum. This includes things like: ensuring sufficient color contrast for text (for people with low vision or color blindness), providing text alternatives (alt text) for images so that screen readers can relay this information to blind users, ensuring that the website can only be navigated using the keyboard (for users who cannot use a mouse), adding captions or transcriptions for multimedia (for deaf or hard of hearing users) and semantic structuring of HTML (use of proper headings ..

, lists, etc., which helps screen readers and other assistive devices). Drupal provides a good foundation for accessibility - many Drupal themes and modules have been developed with accessibility in mind, but it is still up to the project team to use them correctly and fill in the gaps with appropriate content and code. Test all custom features with accessibility in mind.

Use accessibility checking tools and methods throughout development. Automated testing programs (such as WAVE, Axe or Lighthouse) can uncover many issues (missing alt tags, low contrast, missing form labels, etc.). However, you should also carry out manual tests: Try using the site with just a keyboard (can you reach and operate all the interactive elements?) and with a screen reader (like NVDA or VoiceOver) to see if the experience makes sense. There are also accessibility linters and modules during development to enforce good practice. It's easier to fix problems during development than to review a finished website and retrofit fixes (although testing is also helpful).

Everyone - designers, developers, content creators - should be aware of basic accessibility and UX principles. Content writers, for example, should know that they need to write descriptive link text ("Learn more about our services" instead of just "Click here"), and designers should know that they can't rely solely on colors to convey information ("required fields in red" should also have an asterisk or label). If necessary, have an accessibility expert run a workshop with your team or conduct a formal UX review at specific milestones. Empathy for users (including people with disabilities) naturally leads to a better product. Consider special cases: How will this form work for a dyslexic user? Will this carousel be a problem for someone prone to motion sickness? These considerations lead to inclusive design decisions.

If possible, conduct a round of user testing or at least a heuristic evaluation (an expert assessment of usability) before launch. Finding and fixing some major UX issues before the public sees the site can greatly improve its acceptance. Also consider an accessibility review by professionals or members of the disability community. They may find issues you didn't realize you had. Fix as many as you can. Even if you can't meet every single advanced WCAG criterion, meeting the basic criteria will greatly improve the accessibility of your website. Document any known gaps and plan to fix them as needed after launch, rather than letting them slide indefinitely.

Continue to monitor user feedback, analytics and all accessibility reports after launch. UX work is never really "done" - there are always opportunities to improve it based on actual usage. Maybe all users are abandoning the site on a particular page - investigate the reasons why (maybe the call to action isn't clear). Or maybe someone is reporting difficulty using the site with a screen reader - fix that immediately. Consider UX and accessibility for all new features too.

This sounds obvious, but under time pressure it's tempting to say, "I know this isn't the cleanest way, but let's just do it. Get in the habit of coding (and theming, and configuring) the right way . In terms of Drupal, this means using Drupal's APIs and modules instead of hacking things together. For example, instead of writing your own PHP script to do something that a rules module or core functionality could do, use the established tool (unless there's a compelling reason not to). Stick to coding standards and perform code reviews . One of the causes of technical debt is that developers don't know better techniques - so share your knowledge within the team. If you're not sure how to elegantly implement a requirement in Drupal, ask the community or look for examples; the Drupal community is large and chances are someone has solved a similar problem without resorting to hacks. By doing things right the first time, you avoid the need to "go back and fix it later", which often doesn't happen until it's a real problem.

Think about future use cases when architecting and designing. This doesn't mean you need to over-engineer or add unnecessary complexity "just in case", but you should consider reasonable future scenarios. For example, if the client wants to expand to multiple languages in a year, you should set up Drupal's multilingual support now instead of coding English content everywhere. If the site will need e-commerce later, choose a Drupal distribution or architecture that supports this, or at least doesn't cause conflicts. If you expect traffic growth, make sure the hosting and Drupal caching strategies are scalable (perhaps use a CDN, etc.). Another example: use Drupal's built-in field and entity system for content instead of custom database tables so you can more easily expand content types, views, etc. later. Planning for scalability ensures that you don't back yourself into a corner that requires reprogramming later. Technical debt often arises when designs are too narrow and then extended beyond their purpose. A robust architecture can cope with new requirements without collapsing.

When a bug or performance issue is found, sometimes there is a simple fix that seems to fix the problem immediately (e.g. directly editing the code of a contributed module or adding a bit of JS to fix a backend issue). These are red flags. Instead, take the time to find the root cause and fix it properly. If a contrib module has a bug, see if there's an update or patch from the community; if not, override it in a way that won't be blown away by updates (like form changes or extending classes in Drupal rather than changing the core or contrib code). As painful as it may be in the moment, investigating and solving problems the right way is an investment in the future stability of the project. A hack may save an hour now, but cost dozens later. Remember that every blunder incurs "interest" that your team will have to pay every time the codebase needs to be touched again.

One way to manage and avoid debt is to identify problems early. Writing automated tests (unit, functional or behat tests for user stories) can seem like extra work, but it pays off because it ensures that you don't accidentally break existing features as the project grows. Testing acts like a safety net, encouraging developers to refactor code (to reduce complexity) because they can be confident that if something doesn't work, a test will catch the bug. Without testing, teams are often afraid to change unclean code ("if it works, leave it alone"), which means that unclean code remains unclean - and the debt remains unpaid. Continuous integration (CI) tools can run your test suite and other quality checks (coding standards, etc.) on every commit and catch problems early. This quality culture helps prevent sloppy code from entering the codebase in the first place. Over time, you get a cleaner, more modular codebase that is easier to extend.

No project is completely debt-free. Sometimes you need to take a shortcut to meet a deadline - that's fine if you do it consciously and plan to "pay it back". Create tickets for refactoring tasks and prioritize them in future sprints. For example, you might say, "We hacked feature X to demo it for the trade show; now that the deadline has passed, let's spend a day rewriting it properly." Don't allow refactoring to always be put off; make it part of the work. Stakeholders may not see the visible value right away, but you can explain it like car maintenance - if we don't do it, the car will break down. Some teams allocate a fixed proportion of each sprint (e.g. 10-20%) to removing technical debt or maintenance tasks. This ensures continuous improvement of the code base. It's much easier to eliminate debt in small increments during the project than to do a massive, systemic rewrite later.

Drupal, like any software, continues to evolve. Keep your Drupal core and modules up to date (within reason) throughout the project. Don't put off all updates until the end or after launch, as outdated software can become its own technical debt (security vulnerabilities, outdated features, etc.). However, when updating, avoid quick fixes such as simply suppressing warnings or bugs without addressing the underlying change. For example, if a newer version of a module changes an API, adjust your custom code accordingly rather than sticking with the old version forever or hacking something. Be prepared for maintenance as you work. Also plan the site with Drupal's upgrade path in mind. With Drupal 9 and 10, for example, it was easier to upgrade if you kept your code free of outdated versions. When starting a new project, you should start with the latest stable Drupal version to extend the longevity of your platform. Technical debt can have as much to do with not keeping up with the platform as it does with code quality.

Sometimes you make a decision that is not ideal, but necessary (due to a constraint). Document it - in code comments or in a simple decision log. This will help future caregivers (or your future self) understand the context and not inadvertently build on a shaky foundation. For example: "TEMPORARY: Using custom authentication instead of SSO due to current infrastructure limitations. Will be replaced when the SSO server is available. Now you know that this piece of code carries a debt that has a trigger to be replaced. Without documentation, you might forget that it is a workaround and never pick it up again.

Discuss during the project (even during contract negotiations) what will happen after commissioning. Will the agency offer a support period? Is it included or will it be paid for separately? How will the client report problems or request future improvements? By clarifying these questions upfront, you avoid the "support gap" where the client thinks support is included indefinitely, but the agency considers the project complete. Many agencies provide a guarantee period (e.g. 30-90 days after launch) in which they will fix any bugs that arise within the initial scope. In addition, a formal support agreement or retainer may go into effect. Make sure the customer understands the terms: For example, support could include a certain number of hours per month, or an on-call agreement, etc. If the client doesn't want ongoing support, at least make sure they are aware of the risks and have a plan for maintenance (perhaps an in-house IT department or another provider). As a guide for freelancers notes, not meeting these expectations leads to frustrated clients later when they suddenly send an email with "urgent help" and wonder why it's not covered. It's much better to have this conversation in the calm before the launch than during a fire after the launch.

For most sites, we strongly recommend a maintenance plan - this could include regular Drupal core/module updates (as security updates come out frequently), uptime monitoring, backups, and a few hours for minor tweaks or consulting each month. Present this to the client as protecting their investment (which it is). For example, timely application of security patches is critical - Drupal releases, especially security fixes, should be applied to avoid hacks. If the client's team is unable to do this, the agency's support service is invaluable. Things like server updates or performance optimizations over time also fall into this area. A support team ensures that the website remains healthy. An article on the importance of support puts it well, "You may think that you don't need to keep support on speed dial because everything is running smoothly, but you shouldn't delete their number just yet.... there will always be an opportunity or a situation that you didn't expect." [22]
In other words, plan for the unexpected in a support agreement.

Before you hand over the keys, you should train the people who will be using the CMS on a daily basis. Tailor the training to the respective roles: For example, editors will receive training on creating/editing content, managing menus, and uploading files; administrators will receive training on managing users, using views, or changing taxonomies, etc., as needed. Drupal can be overwhelming for new users, so provide written tutorials or video recordings they can refer to. Encourage hands-on practice in a staging environment during training. Even if it's a redesign and the client has used Drupal before, don't assume they know the new setup - every site is different, and added features (like a new custom content type) need to be explained. As one expert suggests, "Training is an important aspect of any web project. Even if you are redesigning a website, you should include at least 1 hour of training in the project cost. It's best to schedule the training before the website is launched so that the client can familiarize themselves with the website right away."
That way, the client's team is confident and not confused on launch day.

Provide documentation in addition to the live training sessions. This could be a simple PDF file or a wiki with step-by-step instructions for common tasks ("How do I add a news article", "How do I update the homepage banner", etc.). Screenshots are helpful. Documentation is a safety net if staff changes or someone forgets part of the training. It also reduces the support burden as the customer can help themselves with basic questions. Drupal-specific specifics for the project should be documented (e.g. "Our site uses the moderation module so content updates need to be approved; here's how the workflow works..." or "We have a custom block for the footer, edit it under Structure > Block Layout > Footer Block"). These details give the customer more options.

Have the team monitor the website closely right after launch. Real users often quickly find problems that were not detected during testing. Set up analysis and error monitoring. Schedule a review meeting after a few weeks: Discuss how the site is performing, what feedback you've received, and what quick tweaks could improve UX or performance. This shows the client that you're still invested in their success and not just getting to the finish line and then disappearing. It's also a good time to address any minor improvements the customer can think of after they've used the site "for real" - small refinements can significantly increase customer satisfaction.

From a business perspective, a new website is not the end of the customer relationship - it's a new phase. Encourage the customer to see the website as an evolving platform. Perhaps in 6 months they will want new features, an SEO campaign or integration with a CRM. By positioning your agency as a long-term partner, you become the go-to resource for these needs. When it comes to content management, clients often need support when onboarding new team members - perhaps offer additional training (one guide suggests offering "additional paid training ... e.g. one year after launch when the client has a new team member" [21]). The idea is to support the entire lifecycle of the website. If the client is successful and satisfied with their Drupal website, they are more likely to come back for future projects or enhancements.