Drupal vs WordPress: when each platform is the right choice
Choose Drupal when the site has outgrown a marketing brochure and needs many content types, departmental ownership and detailed permissions, and your team can staff PHP and Drupal skills and planned major upgrades. Choose WordPress when the site is mainly editorial or marketing content, the editors are comfortable with a familiar admin, and you want rolling minor updates with a smaller build effort. Both platforms are GPL PHP projects, so licensing will not separate them. Three factors should decide the matter: how deep your content model and permission rules need to go, what your team already knows how to build and run, and how much major-upgrade work your organization can staff over the life of the site.
Start with the content model. Drupal's entity and field system, combined with role-based and content-level access, suits organizations where regional offices, product lines or legal teams each publish within fixed boundaries and an approval step must hold. WordPress can handle many custom post types and roles, but the controls for complex workflows usually come from plugins, and each plugin becomes a dependency to review and keep patched. For an illustrative case, a university with separate faculties, a central brand team and a reviewed publishing path for admissions pages would test both platforms against those exact rules before choosing. Ask each candidate to demonstrate the permission matrix you need, not a generic feature list.
Then price the upgrade path, not just the launch. Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, and Drupal 12.0.0 is scheduled for the week of December 7, 2026, so any site still on Drupal 10 needs a dated plan that a team can staff. WordPress 7.1 was released on August 19, 2026, and only the most recent release in a series is actively maintained, so staying current means applying point releases promptly. Confirm your team's PHP and database versions against the WordPress requirements and Drupal's supported database list before committing, because both platforms move those baselines over time.
Which platform fits which scenario
This table matches common situations to the platform that usually fits better, with the condition that makes the choice hold and where the other platform would still work. Read each row as a starting point, then test the condition against your own team, content model and upgrade tolerance.
| Scenario | Better fit | Why and the condition that holds it |
|---|---|---|
| Brochure site with a small team | WordPress | Editors handle pages, forms and news with little setup. Holds if content types stay simple and the site has few integrations. Drupal still works if the team has Drupal skills and expects the site to grow. |
| Multi-department publisher with complex roles | Drupal | Granular permissions, workflow states and content moderation suit many editors across departments. Holds if governance rules must be enforced in the platform itself. WordPress can cover this with careful plugin selection, but you then own the permission model. |
| Heavy custom content types and integrations | Drupal | Entities, fields, views and a structured module API model complex content and data flows. Holds if the content model is central to the business. A WordPress site can work for this, but expect more custom plugin code to maintain. |
| Team with an in-house WordPress developer pool | WordPress | Existing PHP and WordPress skills shorten build and support work. Holds if those developers can own security patching and plugin review. Drupal remains viable if you can hire or train for its architecture. |
| Team that must avoid frequent major upgrades | WordPress | WordPress ships rolling feature releases within a version series, and only the most recent release in the 7.1 series is maintained. Holds if you can apply minor and feature updates promptly. Drupal is workable if you plan around its major version cycle and end-of-life dates. |
| Strict upgrade calendar with a fixed budget cycle | Drupal | Major versions follow a published schedule, so upgrades can be planned ahead. Holds if your organization budgets for a major upgrade project every few years. Confirm the current end-of-life dates with the Drupal release schedule before committing. |
| Hosting on a standard LAMP or LEMP stack | WordPress | Requirements are modest and widely supported by shared and managed hosts. Holds if the site does not need a specific database or search service. Drupal also runs on this stack and supports several databases, so confirm your target version's requirements. |
| Need for a specific database such as PostgreSQL | Drupal | Drupal 11 lists PostgreSQL 16 or later among supported databases. Holds if your data platform standard requires PostgreSQL. WordPress requires MariaDB or MySQL, so PostgreSQL would be a non-standard choice. |
| Content must be served to several front ends | Drupal | Drupal can deliver content through its own theme layer and web services. Holds if you want one platform for both editing and presentation. A headless front end is possible on either, but evaluate it against a dedicated headless CMS. |
How Drupal and WordPress are built and what that means for operations
Drupal and WordPress are both GPL PHP platforms, but their extension models, database choices and release rhythms shape how much work lands on your team each month. The cards below cover the parts that drive patching, staffing and backup scope.
Core and extension model
Drupal builds features from contributed modules and a configuration system, so a single site often depends on dozens of modules that must agree on versions. WordPress relies on plugins and themes, which are easier to add but can overlap in what they change. Review how many modules or plugins each feature needs, and who owns the decision to add one.
Database support
Drupal 11 supports MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later and SQLite 3.45 or later. Microsoft SQL Server and MongoDB come through contributed modules, which adds a maintenance dependency you must track. If your standard is SQL Server, confirm the module's current maintenance status before you commit.
Runtime requirements
WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. Staying on those versions keeps your PHP runtime and database inside supported ranges, but plugin code often lags behind new PHP releases. Test your plugin set on the target PHP version before each runtime upgrade.
Release cadence
Drupal core follows a published schedule, and Drupal 10 reaches end of life with no further releases after its end date, which means moving to a supported major version is a planned project. WordPress ships feature releases on a shorter cycle, and only the most recent release in each series is actively maintained, so minor updates are routine work. Build a patch calendar around each platform's own schedule.
Hosting footprint
A Drupal site commonly needs more caching, cron scheduling and configuration management than a typical WordPress install, which affects the size of the platform team you need. WordPress can run on a smaller stack, but busy sites still need page caching, object caching and a managed backup routine. Ask your hosting team to size both stacks against your traffic and editorial volume, not against brochure-site assumptions.
Where custom code lives
Drupal custom code usually sits in custom modules and a theme inside the codebase under configuration control, which makes upgrades testable but requires developer capacity. WordPress custom code often lands in a child theme or a mu-plugin, and it is easy to drift into the database or a one-off plugin. Decide where custom code is allowed to live, and back up the code repository and the database together.
How Drupal and WordPress compare on the features that decide the choice
This table compares Drupal and WordPress on licensing, release status, database support, runtime requirements, extension model, content modeling, permissions, identity integration and hosting. Read the Drupal column for the depth of structured content and access control, and the WordPress column for the simpler update path and wider plugin market, then confirm the specific modules or plugins you would need in your own environment.
| Feature | Drupal | WordPress |
|---|---|---|
| License | GPL-2.0-or-later for Drupal core and contributed files hosted on Drupal.org | GPLv2 or later, published by the Free Software Foundation |
| Core release status | Drupal 11.4 released the week of June 29, 2026. Drupal 10 reaches end of life on December 9, 2026. Drupal 12.0.0 is scheduled for the week of December 7, 2026. | WordPress 7.1 released August 19, 2026, and 7.1.3 on October 6, 2026. Only the latest 7.1 release is actively maintained. |
| Supported databases | Drupal 11 supports MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later and SQLite 3.45 or later. Microsoft SQL Server and MongoDB come through contributed modules. | WordPress.org recommends MariaDB 10.11 or greater or MySQL 8.0 or greater. Confirm any other database with your hosting provider and plugin authors. |
| PHP requirement | Confirm the PHP version required by the Drupal 11.4 release you plan to deploy on the system requirements page for that release | WordPress.org recommends PHP 8.3 or greater |
| Extension model | Modules and themes from Drupal.org, with contributed code reviewed by maintainers and updated on the core release cycle | Plugins and themes from the WordPress.org directory, with a large market of commercial and free extensions of varying quality |
| Content modeling | Describe your content types, fields, references and display rules, then confirm which core or contributed modules provide the structure you need | Describe your post types, custom fields and taxonomies, then confirm which plugins you would use and how they hold up under upgrades |
| Permissions depth | Describe your editorial roles, content-level access and workflow needs, then confirm the access control modules you would use | Describe your roles and capabilities, then confirm whether the default roles and any plugins meet your editorial approval and access needs |
| Identity integration | Describe your SSO protocol and directory requirements, then confirm the authentication modules available for your identity provider | Describe your SSO protocol and directory requirements, then confirm the authentication plugins and their maintenance status with your identity team |
| Hosting options | Self-hosted in your own cloud accounts, data centers or air-gapped networks, with a database and PHP stack you control | Self-hosted in your own cloud accounts, data centers or air-gapped networks, on a PHP and MariaDB or MySQL stack you control |
What the GPL licenses cover and what is paid for
Drupal core and contributed files hosted on Drupal.org are licensed under the GNU General Public License version 2 or later (GPL-2.0-or-later). That license lets you install, modify and redistribute the software without paying Drupal Association or any single vendor for the right to use it. Obligations arise mainly when you distribute modified code, so most internal or hosted deployments carry no license fee at all.
- Core and contributed code: Both fall under GPL-2.0-or-later as stated on the Drupal.org licensing page, so check the license on each module or theme you add.
- No license fee: Nothing in the GPL requires a payment to use Drupal on your own infrastructure.
- Distribution terms: If you ship modified Drupal code to third parties, the GPL governs how you share source.
- Third-party components: Commercial modules or themes sold outside Drupal.org carry their own license terms.
- Spending areas: Hosting, implementation, support retainers and staff time remain your costs.
Before budgeting, read the licensing page and confirm the license of every contributed module and theme in your planned build.
WordPress is released under the GPLv2 or later from the Free Software Foundation, as described on the WordPress.org license page. Like Drupal, the core software carries no license fee, and the license grants the same freedoms to run, study, modify and redistribute. The license governs the code itself, so the practical cost question depends on what you add around it.
- Core license: WordPress core is GPLv2 or later, which permits use without a fee.
- Plugins and themes: Many are GPL-compatible, but some vendors sell premium extensions under their own terms, so read each one before purchase.
- Hosting stack: Web servers, PHP and database hosting, and any managed WordPress service are paid separately.
- Maintenance labor: Updates, backups and security monitoring are staff or partner time, not license charges.
- Premium extensions: Paid themes, plugins and support subscriptions recur on the vendor's schedule.
Confirm the license terms of every plugin and theme you plan to use, including any recurring subscription that comes with them.
Because neither license charges a fee, the recurring and one-time costs fall into a small set of categories. Each one is paid to a different party, and each one scales differently with the size and risk of your site. Understanding who gets paid for what makes a quote easier to compare across the two platforms.
- Hosting: Infrastructure is paid to a cloud provider, data center or managed host, and it recurs monthly or annually.
- Implementation: Design, content modeling, integration and migration are one-time costs quoted from a written scope.
- Support retainers: Ongoing patching, upgrades and monitoring are usually recurring, whether provided internally or by a partner.
- Premium modules or themes: Paid add-ons may be one-time or subscription-based, and both platforms offer them.
- Staff time: Internal editors, developers and security staff represent a significant ongoing cost that rarely appears on a license line.
Ask any quote to list these categories separately so you can see which costs are one-time and which recur.
This page does not list commercial editions, paid tiers or hosted offerings for either platform, because no facts for those were supplied. Readers should not assume that the open-source releases described here are the only options, and they should not assume that any paid tier is included or excluded by the license alone. Any vendor, hosting provider or partner may offer packaged services with their own terms.
- Editions: Confirm whether any commercial edition exists and what it adds beyond the open-source core.
- Hosted offerings: Ask whether a managed service changes responsibility for patching, backups or uptime.
- Support tiers: Check what support is included, how response is defined and whether it recurs annually.
- Feature gating: Verify which capabilities sit behind paid plans rather than in the core product.
- Licensing changes: Ask how any future change to a commercial offering would affect your current deployment.
Confirm any paid tier directly with the vendor or your implementation partner before you put it into a budget.
What drives the running cost of Drupal and WordPress
Running cost is mostly people and upgrade work, not licenses. Both Drupal and WordPress are GPL-licensed, so neither charges a license fee for core. The recurring spend is hosting and database infrastructure, administrator and developer time, and any retainer you buy for patching, monitoring and testing. The one-time spend is implementation: theme or front-end work, content modeling, migration and hardening. Who you pay for each of these depends on whether you staff the work in-house, hire a partner on a fixed scope, or buy an ongoing retainer. Ask each vendor to split its quote into those buckets so you can see which costs recur.
Drupal's cost curve is tied to its release calendar. Drupal 10 reaches end of life on December 9, 2026, with no new Drupal 10 releases after that date, and Drupal 12.0.0 is scheduled for the week of December 7, 2026. If you run Drupal 10 today, the major upgrade moves from optional to required within a short window, and that upgrade is a project in its own right: custom modules, contributed modules and themes must be checked against the new major version and retested. Budget for that work now, and confirm with your partner whether the upgrade is priced inside the implementation scope or as a separate change order. Also check the database versions you run, since Drupal 11 sets minimum versions for MariaDB, MySQL, PostgreSQL and SQLite on the Drupal.org database requirements page.
WordPress keeps costs lower through frequent in-series updates, but only if you stay current. WordPress 7.1 was released on August 19, 2026, and 7.1.3 on October 6, 2026, and the WordPress.org releases archive states that only the most recent release in the 7.1 series is actively maintained. Routine patching is therefore small, recurring and predictable, which suits an internal team or a light retainer. The risk is plugin drift: a paid or abandoned plugin can block a core update, and the cost then shifts to remediation. For any quote, request the scope, the upgrade assumptions (including which major versions are covered), the full extension list with license terms, and the support terms, including response expectations and what happens when a plugin or module is no longer maintained.
How a move between Drupal and WordPress is sequenced
The sequence turns an existing site into a documented inventory, a permission model, a rebuilt front end and a validated cutover, so the new stack can be verified before the old one is retired. The order is the same in either direction, but the items that transfer cleanly differ.
Inventory content types, fields and volumes
Export a complete list of content types, fields, taxonomies, menus, media libraries and URL patterns from the current site, and record how many items sit in each group. In Drupal this usually means reviewing content types, paragraph or entity structures and view configurations. In WordPress it means custom post types, custom fields and any plugin-defined data. The output is a field-level mapping sheet that shows each source field, its target field and whether it is a direct copy, a transformation or a rebuild. Confirm with your content owners which fields are still in use, because stale fields are the most common reason a migration grows.
Map roles, permissions and editorial workflow
Translate each existing role into the target model and list every permission that a role grants. Drupal's role and permission system is granular and often tied to content types, taxonomies and workflows, while WordPress uses a fixed set of user roles with capabilities that plugins can extend. Some Drupal permission combinations have no direct WordPress equivalent, so each one needs a documented decision: a plugin, a custom capability, or a process change. The output is a signed-off permission matrix. Confirm with your security and compliance leads that the target model still meets your separation-of-duties requirements before any user data is moved.
Identify extensions and their equivalents
List every contributed module in Drupal or plugin in WordPress that the site depends on, and record the function each one provides. For each item, decide whether the target has a maintained equivalent, whether a custom build is needed, or whether the feature can be dropped. Check the maintenance status, supported core versions and license of each candidate rather than assuming parity from the name. The output is a dependency register with a decision and an owner per item. Confirm the status of any plugin or module you plan to keep with its maintainer, since this is where most migration risk sits.
Rebuild templates, themes and components
Recreate the layouts, templates and components on the target platform, working from the approved design and the mapping sheet. Drupal themes typically use its theme layer and template system, while WordPress themes use its template hierarchy and block patterns. Front-end accessibility checks, responsive testing and performance budgets belong in this step, not after launch. The output is a staging site that renders every content type in the inventory and passes the checks your organization defines. Confirm with your design and accessibility owners which templates need sign-off, since rebuilt templates rarely match the old site pixel for pixel.
Migrate content and validate the results
Run the content migration in a repeatable script or tool, moving content types in dependency order so references, media and taxonomy terms resolve correctly. Run the migration at least once into staging, compare record counts and sample items against the inventory, and check that internal links, media paths and metadata survived. Structured content and custom fields usually need transformation, while basic text and media transfer more directly. The output is a validation report listing every discrepancy and how it was resolved. Confirm with the content owners that the sample they review covers the edge cases that matter to them, such as long-form pages and multilingual content.
Build redirects and rehearse the cutover
Map every old URL to its new location, including pagination, search and media URLs that search engines and external links still use. Test the redirects in staging, then rehearse the DNS change, certificate setup and any caching or CDN purge in a dry run. Confirm the DNS time-to-live settings and the cutover window with your hosting and network teams before the rehearsal. The output is a tested redirect map and a written cutover runbook with a rollback path. Confirm that analytics, forms, email delivery and integrations with third-party services point to the new site before the change goes live.
Cut over and monitor the new stack
Execute the runbook, switch DNS to the new hosting stack, and monitor error rates, redirect hits and page performance against the baseline you recorded before the move. Keep the old stack available in read-only mode until the monitoring period you agreed has closed. The output is a cutover record with timestamps, checks performed and any issues resolved. Confirm the length of the monitoring window with your own operations and governance teams, because the right period depends on traffic patterns and change control rules.
Retire the old stack and document it
Once the monitoring period closes, back up the old site and database, remove public access, and decommission the old hosting resources according to your retention policy. Record what was retained, where backups are stored and who approved their deletion. Update the system documentation, runbooks and access lists so the new stack has a current owner and an upgrade plan. The output is a decommissioning record and an updated configuration baseline. Confirm your legal and records retention obligations before deletion, since migration backups are often overlooked.
Where Drupal and WordPress projects usually run long
Drupal projects usually run long when the content model, permission design, theme work and upgrade plan are settled in the wrong order. Content types, fields, taxonomy vocabularies and view modes should be agreed before anyone builds templates, because every later change to a field touches the theme, views and migrations. Permission design needs the same discipline: roles, content moderation states and any field-level access rules should be written as a matrix that editors and legal sign off on. The upgrade plan is the step teams skip. Drupal 10 reaches end of life on December 9, 2026, so a build started now needs a named plan for moving to a later major version, with contributed modules checked for compatibility before that work is scheduled. Ask the implementer to price that upgrade inside the original scope.
WordPress projects tend to slip in three places: plugin selection, custom theme or block work, and maintenance governance. Plugins are the fastest way to add a feature, but two plugins often overlap, and each one carries its own update cadence and security history. Before launch, list every plugin with its purpose, owner and replacement option, and remove anything the custom work already covers. Custom theme or block work is where budgets are usually spent, so decide early whether the site uses a block theme, a classic theme or a mix, and have editors test the block editor on real content. Governance matters because the WordPress.org release archive states that only the most recent release in each series is actively maintained, so the 7.1 series must be patched on a fixed schedule. Confirm who applies minor updates, how staging tests run and who signs off.
Three delays hit both platforms. The first is unclear content ownership: if no one can say who approves a page, who owns a product description or who retires old content, the workflow and permission design stall, and the theme gets rebuilt after sign-off. The second is unresolved identity requirements. Confirm whether editors authenticate through the corporate directory, whether single sign-on is required for the public site and how roles map from directory groups, because those answers change the module or plugin choice and the hosting topology. The third is late integration scope: CRM, marketing automation, search, analytics and consent tooling often appear after the build starts. Put each integration in the written scope with its owner and test environment, and state what happens when a vendor API changes.
Drupal vs WordPress questions buyers ask before hiring help
What drives the cost of a Drupal or WordPress build?
Scope size drives most of the cost: the number of content types, templates, integrations, and custom features. A marketing site on a standard theme costs far less to deliver than a site with custom content modeling, role-based editorial workflows, and single sign-on. Both platforms are GPL-licensed, so the core software is free to use, but costs still come from the people who build, test, and operate it. Expect one-time costs for design, configuration, content migration, and launch testing, plus recurring costs for hosting, security patching, backups, monitoring, upgrades, and any paid plugins or modules. Ask each quote to split one-time build work from recurring operations work, and to name who pays for hosting, licenses, and premium extensions.
How long does a Drupal or WordPress migration take?
The duration depends on content volume, the number of templates, custom code, integrations, and how quickly decisions are made. Migration often takes longer than theme work when source content is inconsistent, because field mapping, cleanup, and redirect checks need time. We do not publish durations for this comparison, so the reliable path is to ask for a timeline tied to named milestones and deliverables. Under a fixed-scope model, DeployOpen agrees scope, deliverables, and timelines in writing before work starts. Ask which milestones depend on your team's sign-off, because those dependencies are the most common cause of schedule slip.
What does our team need to provide during implementation?
Implementation moves at the pace of your decisions, so the client team carries more weight than the platform choice. Expect to provide:
- A named business owner who signs off the content model, templates, and launch
- Content owners who validate migrated material and approve redirects
- Access to existing hosting, DNS, identity provider settings, and integrated systems
- Staging environments and test accounts for each editorial role
Agree on a review cadence and a single decision log early, so changes are recorded and approved in one place. Ask the partner to list which items it expects from your team and which it provides itself.
Can an internal team run Drupal or WordPress without a partner?
A capable internal team can build and operate either platform alone if it covers PHP, the chosen database, web server operations, security patching, and staging-to-production release practice. The harder questions are whether the team can test major upgrades, maintain contributed modules or plugins, and apply security releases on schedule. Drupal major upgrades are planned projects, so budget internal time for them in advance. Check the database and runtime requirements before you commit, since Drupal 11 supports MariaDB 10.6 or later and WordPress recommends PHP 8.3 or greater. A short skills audit of your team usually shows where a retainer for support or upgrades would add the most value. DeployOpen plans, implements, hardens, backs up, upgrades, and documents self-hosted platforms inside your infrastructure, so build and operations can be split.
How should we plan around the Drupal 12 release timing?
Drupal 10 reaches end of life on December 9, 2026, with no new Drupal 10 releases after that date, so that date is the hard constraint if you run Drupal 10. Drupal 11.4 was released the week of June 29, 2026, and Drupal 12.0.0 is scheduled for the week of December 7, 2026. The planning question is whether to move to Drupal 11 first or aim directly for Drupal 12. Start with an inventory of contributed modules, custom code, and database versions against the Drupal database requirements. Confirm dates on the Drupal core release schedule before you fix a target, then plan test windows and a rollback path for each step.
Can WordPress meet our content permission requirements?
WordPress can meet many permission needs, but whether it meets yours depends on how granular roles, workflows, and audit trails must be. Confirm these needs in writing before choosing:
- Which roles can draft, edit, or publish, and whether any role needs restrictions by section
- Whether each change must pass a recorded approval step
- Whether a log of who changed what must be kept, and for how long
Test these requirements with the plugins you would actually use, not only with the default install, and record the results. If your needs go beyond what a chosen plugin covers, Drupal's content modeling and permissions depth is usually the next platform to evaluate. Include plugin maintenance commitments in the same review.
What should a fixed-scope quote from a partner include?
A fixed-scope quote should trace back to written scope. Ask for:
- A scope statement listing sites, content types, integrations, and environments
- Deliverables with acceptance criteria and a named sign-off person for each
- Milestones and timelines agreed before work starts, with your team's dependencies named
- Explicit exclusions, such as content entry, third-party licenses, and hosting fees
- Testing, hardening, backup, and documentation deliverables
- Retainer terms for upgrades and ongoing support, priced separately from the build
DeployOpen does not publish a price list. A quote follows from the written scope, so the more precise the scope, the more comparable the quotes from different partners will be.
Does an implementation partner issue compliance certificates for the platform?
No. DeployOpen prepares systems, controls, and evidence for compliance assessments, but it does not issue audit reports, attestations, or certifications. Independent auditors and certification bodies perform those. Ask a partner which controls it will configure, which evidence it will produce, and which parts your own policies must supply. For either platform, confirm hosting location, backup and restore records, access logging, and patch history early, because these shape the evidence set. Write the auditor's requirements into the scope so the build covers them from the start.
How DeployOpen helps teams choose, build or move between Drupal and WordPress
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Drupal vs WordPress, that means starting from your content model, permissions and hosting constraints, then writing down what will be built before any work begins.
How we scope
- Written scope covers content types, roles, permissions and the editorial workflow your teams need.
- We document which modules or plugins are needed, and which custom code is required to fill gaps.
- Scope states the target hosting stack, including PHP and database versions checked against current requirements.
How we build
- Builds run inside your own cloud accounts, data centers or air-gapped networks, with no hosted vendor dependency.
- We customize, integrate with your identity provider and harden the site against the scoped threat model.
- Security testing of the site, APIs and infrastructure is available as part of the engagement or as a separate scope.
How we hand over
- Handover documents the architecture, configuration, backup and restore steps, and upgrade procedure for your team.
- Compliance evidence is prepared for your assessors, though independent auditors and certification bodies issue any reports.
- Runbooks name the owner of each upgrade path, whether a Drupal major version or a WordPress minor release.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask for a quote that separates one-time build work from recurring retainer work and hosting costs you pay directly.
