Open WebUI or LibreChat: which chat front end fits your staff
Open WebUI fits Ollama-first, offline teams with a small user base or a branding arrangement, while LibreChat fits teams that want MIT licensing and access to many cloud providers. The choice turns on three questions: how many staff will use the front end, whether you need to rename or re-skin it, and which stack your team is prepared to run. Answer those before you compare features, because the license terms and the back-end services differ more than the chat screens do.
On licensing, Open WebUI moved to the Open WebUI License with v0.6.6, released April 19, 2025, and code merged up to v0.6.5 remains BSD-3-Clause. That license restricts changing or removing Open WebUI branding unless the deployment has no more than 50 end users in a rolling 30-day period, the copyright holder grants written permission, or you hold an enterprise license. If you expect more staff or need your own branding, get the branding terms confirmed in writing with the vendor before rollout. LibreChat is MIT licensed, so the license question is simpler, but its reference docker-compose stack runs MongoDB, Meilisearch and a separate RAG API service, which your operators must maintain.
Decide who will operate the platform before you pick. Ask whether your team can support the Ollama runtime and offline model workflow that Open WebUI is built around, or whether it will need to run and patch a MongoDB-backed stack with several services. Request a written scope from any implementation partner that lists the components, upgrade path and branding conditions, and confirm current release status on the Open WebUI releases page and the LibreChat repository before you commit.
Which scenario favors Open WebUI and which favors LibreChat
This table maps common scenarios to the platform that usually fits better, with the condition that changes the answer. Read each row as a starting point, then check the conditions against your user count, branding plans and team skills before deciding.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Ollama-only, offline use on local models | Open WebUI | Its documentation describes a platform built to run entirely offline with Ollama and OpenAI-compatible APIs. Confirm the offline behavior against your own air-gapped build before relying on it. |
| Mixed cloud and local model access | LibreChat | Its README lists Anthropic, AWS Bedrock, OpenAI, Azure OpenAI, Google and Vertex AI alongside custom endpoints. Open WebUI also supports cloud models through OpenAI-compatible APIs, so compare the provider list you need. |
| Rebranding the interface for staff | LibreChat | Under the Open WebUI License, altering or removing branding is restricted unless the deployment has at most 50 end users in a rolling 30 day period, written permission is granted, or an enterprise license is held. LibreChat is MIT licensed, so confirm your own branding terms with counsel. |
| Small pilot with a few users | Open WebUI | A pilot under 50 end users in a rolling 30 day period stays inside the branding exception, and its Ollama-first setup is quick to try on a single host. Confirm the user count definition in the license. |
| Organization-wide rollout | LibreChat | A broad rollout with many users and mixed providers fits its MongoDB, Meilisearch and RAG API stack, but it means running more services. Ask for the sizing and support plan in writing before committing. |
| Team with existing MongoDB skills | LibreChat | Its reference stack runs on MongoDB, so existing operators can reuse backup and tuning habits. Without MongoDB experience, the extra services add operating effort. |
| Team without MongoDB experience and mostly local models | Open WebUI | A single front end centered on Ollama gives a smaller operational surface for teams that do not run MongoDB. Confirm the storage requirements for your expected chat history. |
How each chat front end is built and what that means for operations
Open WebUI and LibreChat both give staff a browser chat interface over hosted and local models, but they are assembled differently. The number of services, the data stores behind them and the way models are reached determine what your team patches, backs up and troubleshoots after go-live.
Ollama-first, OpenAI-compatible model access
Open WebUI is documented as supporting Ollama and OpenAI-compatible APIs for both local and cloud models, and it is built to run entirely offline. That makes a local-model deployment the natural starting point. Check which model runtimes your staff will actually use, whether each one must be reachable from the chat host, and who maintains the model endpoints. Confirm with the vendor how the offline mode behaves once cloud providers are also enabled.
Offline intent and what it does not cover
Running entirely offline is a design goal in the Open WebUI documentation, not a guarantee for every feature or plugin. Before relying on it for sensitive work, test the deployment with outbound network access blocked and record which functions still call external hosts. Ask DeployOpen or your own engineers to verify update checks, telemetry and any optional integrations in your environment.
LibreChat's app, MongoDB and search services
The LibreChat reference docker-compose file runs the application with MongoDB as its data store and Meilisearch for search. Each service is a separate container with its own volume, upgrade path and backup routine. Your team must know where conversations and user records live, how Meilisearch indexes are rebuilt after a restore, and who owns the MongoDB backup schedule.
The separate RAG API service
LibreChat's reference compose file also runs a RAG API service apart from the main application. Retrieval features therefore add a moving part with its own configuration, logs and failure modes. If document chat is a requirement, ask who will monitor that service, how it connects to the embedding provider you choose, and whether a fault in it degrades the main chat or only uploads.
Component count and upgrade effort
Open WebUI typically runs as a single application you can place behind a reverse proxy, while LibreChat's reference layout spans several containers that must be upgraded together. Every additional service multiplies version pinning, health checks and restore tests. Ask each vendor for its supported upgrade path and which components must match versions during an update.
Who will run the stack
A platform team that already operates MongoDB and Kubernetes or Compose stacks will absorb LibreChat's layout with less friction. A smaller IT group that mainly wants a local model chat may find a single Open WebUI service easier to keep current. Decide who is paid to patch each component, who answers at 2 a.m., and whether that work is in-house or under a DeployOpen retainer.
What the Open WebUI License allows when you rebrand
Open WebUI moved from BSD-3-Clause to the Open WebUI License with v0.6.6, effective April 19, 2025. Code merged up to and including v0.6.5 remains BSD-3-Clause, so a deployment pinned to that line can still be rebranded under the permissive terms. Anyone running v0.6.6 or later should treat the branding clause as the first license question to settle, before a logo, name or footer change reaches staff. The license forbids altering or removing Open WebUI branding unless one of three conditions holds: the deployment has no more than 50 end users in a rolling 30 day period, the copyright holder gives written permission, or the licensee holds an enterprise license.
Each condition needs a factual check. Count end users as the license defines them, not licensed seats or the size of the company, and track the rolling 30 day window over time, since a rollout that starts small can grow past 50 without anyone noticing. If you rely on written permission, get it in a signed document that names the deployment and the branding changes you intend to make. If you plan to rely on an enterprise license, confirm with the vendor what that license covers and whether it includes branding rights. Ask the vendor and your counsel to confirm how these terms apply to your user count, your version and any internal rebranding you have in mind.
For a platform team, the practical risk is a planned rebrand that turns out to be out of bounds after staff are already using the tool. Record which version you deploy, freeze it in your image pipeline, and add a review step before any upgrade across v0.6.6. Compare that effort with the branding terms in LibreChat, which is MIT licensed, so you can plan the rebrand and the upgrade path together. The Open WebUI license documentation and the LICENSE file are the texts to hand to counsel.
Capabilities that differ between Open WebUI and LibreChat
This table compares the two chat front ends on license terms, model connectors, offline operation, search and RAG components, provider breadth and latest release facts. Read each row as a question to settle with both projects before you choose, since the license and the service footprint often decide the outcome more than features do.
| Capability | Open WebUI | LibreChat |
|---|---|---|
| License | Open WebUI License from v0.6.6 (April 19, 2025). Code through v0.6.5 remains BSD-3-Clause. | MIT licensed, so branding changes and internal modification carry no license-specific restriction. |
| Branding terms | Altering or removing branding needs at most 50 end users in 30 days, written permission, or an enterprise license. | No branding restriction in the MIT license. Confirm any trademark terms with the project before publishing a rebrand. |
| Default model connectors | Ollama and OpenAI-compatible APIs for local and cloud models. | Named provider integrations plus custom endpoints. Confirm each connector against your target models. |
| Offline operation | Documentation describes the platform as built to run entirely offline with local models. | Confirm offline behavior with your chosen providers and whether any feature calls external services. |
| Search and RAG components | Built-in document and retrieval features. Confirm the vector store and embedding setup in your target version. | Reference stack runs a separate RAG API service and Meilisearch for search. Plan to operate both. |
| Provider breadth | Broad through OpenAI-compatible APIs, so provider coverage depends on the gateway or endpoint you expose. | README lists Anthropic, AWS Bedrock, OpenAI, Azure OpenAI, Google and Vertex AI, alongside custom endpoints. |
| Backing services | Designed to run as a single self-hosted application. Confirm the storage footprint for your user count. | Reference compose file runs MongoDB, Meilisearch and the RAG API with the app. More services to patch and back up. |
| Latest release | v0.12.3, published October 16, 2026, per the project's GitHub releases page. | v0.8.8, published October 1, 2026 and marked pre-release. Pin a tagged version and test before production use. |
How licensing and paid editions differ for each platform
Open WebUI's license changed partway through its release history. Code merged up to and including v0.6.5 remains under BSD-3-Clause, while v0.6.6 and later fall under the Open WebUI License, effective April 19, 2025. The clause that matters most for most deployments is branding. You may alter or remove Open WebUI branding only when one of three conditions applies, as set out in the license documentation.
- Pre-v0.6.6 code: Versions through v0.6.5 stay under BSD-3-Clause, so a deployment pinned to an older release is governed by different terms than a current upgrade.
- Branding limit: Changing or removing branding is restricted once a deployment has more than 50 end users in a rolling 30-day period.
- Written permission: The copyright holder can grant permission in writing to alter branding.
- Enterprise license: A licensee holding an enterprise license falls outside the branding restriction.
Confirm with the vendor how end users are counted within the rolling 30-day window before you plan a rebrand or a broad rollout.
The enterprise license is the route to branding changes once your user count passes the community threshold. The license text establishes that holding an enterprise license is one of the three conditions that lifts the branding restriction. It does not establish what the license costs, what support it includes, or whether it changes anything beyond branding. Settle those questions with the vendor before you design a rebrand around it.
- What it removes: Under the license terms, the branding restriction no longer applies to a licensee with an enterprise license.
- Pricing basis: Ask whether pricing scales with your user count, the term length, or both.
- Support scope: Ask what support, response commitments and upgrade help are included, since none of these are set out in the license text.
- Code changes: Confirm whether the enterprise license alters what you may modify in the code beyond branding.
- Renewal terms: Ask whether the license covers future major versions and what happens at renewal.
Get the enterprise terms in writing and compare them with the cost of staying under the community threshold. DeployOpen scopes implementation work in writing, so the software license cost and any implementation fees should appear as separate lines in your quote.
LibreChat is licensed under MIT, which permits use, modification and redistribution, including internal rebranding, provided the copyright and license notice are kept. The supplied facts do not describe any branding restriction in LibreChat's license, so the terms are simpler to plan around than Open WebUI's threshold model. The latest tagged release on GitHub is v0.8.8, published October 1, 2026 and marked as a pre-release.
- Permissive terms: MIT allows modification and redistribution, so you can alter the interface for internal use without a threshold tied to user count.
- No branding clause in the license: The license facts do not describe any restriction on altering interface branding.
- Pre-release tag: The latest tagged release, v0.8.8, is marked pre-release, so pin versions deliberately and test upgrades before production.
- Bundled components: The reference stack includes MongoDB, Meilisearch and a RAG API service, each with its own license you should review.
- Optional features: Confirm whether any plugins, integrations or add-ons you plan to use carry separate terms.
Have counsel confirm the notice obligations for a rebranded build, and check the license of every container image you deploy.
ClickHouse announced on November 4, 2025 that it had acquired LibreChat. In its announcement, ClickHouse said existing LibreChat deployments continue unchanged and that it will keep investing in the open-source project. That statement covers continuity for deployments already in place. It does not describe future licensing, pricing or product direction, so those points need direct confirmation. The announcement is the ClickHouse blog post.
- Date of announcement: ClickHouse announced the acquisition on November 4, 2025.
- Stated continuity: ClickHouse said existing deployments continue unchanged.
- Stated investment: ClickHouse said it will continue investing in the open-source project.
- Open questions: Confirm whether the MIT license and public repository will remain as they are, and whether commercial offerings will be added.
- Support path: Ask who will handle security advisories and maintenance after the change, and on what terms.
Get written answers from ClickHouse on license continuity and security response before a multi-year rollout, and record the version you deploy so future upgrades can be reviewed against any changes.
What drives the running cost of each chat front end
This table compares the cost components of running Open WebUI and LibreChat in your own infrastructure, showing who is paid for each one and what changes it. Read it as a checklist for building a quote request, since the pillar facts supply no prices and the real figures depend on your user count, hardware and scope.
| Cost driver | Open WebUI | LibreChat |
|---|---|---|
| Infrastructure footprint | Hosting for the Open WebUI service plus Ollama or another model endpoint, with hardware for local models driving most of the spend | Hosting for the app plus MongoDB, Meilisearch for search and a separate RAG API service, so more stateful components to run and back up |
| Model hardware | Often the largest recurring line when models run locally on GPU or high-memory hosts; cloud model APIs shift this cost to per-token billing from the provider | Same choice between local endpoints and cloud providers such as Anthropic, OpenAI, Azure OpenAI or Google, with provider billing as a recurring line |
| Staff skills | Container operations and Ollama model management; fewer data stores to administer | Container operations plus MongoDB, Meilisearch and RAG API administration, which usually means a wider skill set on the operations team |
| Upgrade cadence | Frequent tagged releases, including v0.12.3 published on October 16, 2026 per the project's GitHub releases page; budget time to test each upgrade against your branding and integrations | Latest tagged release v0.8.8 is marked pre-release per the GitHub releases page; confirm which tag your pilot will pin and how often you will move it |
| License obligations | Branding changes need a written permission, an enterprise license, or a deployment within the 50-user limit under the Open WebUI License; confirm which applies before rollout | MIT licensed, so no branding or user-count conditions; the cost is in your own support and hardening work |
| Ownership change risk | Licensing terms changed at v0.6.6, so an older BSD-3-Clause fork and a current deployment may differ; ask counsel to review the terms in force | ClickHouse announced its acquisition of LibreChat on November 4, 2025 and said existing deployments continue unchanged; ask for the roadmap commitments in writing |
| Support options | Vendor enterprise license or independent implementation support; ask what the enterprise license covers and what it costs | Community support plus any commercial support you contract; ask the vendor and DeployOpen what each covers under the written scope |
| Who is paid for what | Cloud or data center provider for compute, model host or API provider for tokens, staff or a partner for setup and upgrades, and a license fee if branding changes | Cloud or data center provider for compute, provider billing for model calls, staff or a partner for setup, and a partner for the MongoDB, Meilisearch and RAG API stack |
Moving users, chats and settings from one platform to the other
This sequence produces a documented inventory of what moves, a rebuilt configuration on the target platform, and a pilot group that confirms staff can work there before the switch. It keeps the source platform running until the pilot passes. Export formats differ between the two products, so each step depends on what each vendor's documentation confirms.
Inventory accounts, groups and access rules
The platform owner lists every active user, group and role on the current deployment, along with how each person signs in. Confirm whether accounts come from local passwords, an identity provider or a shared directory, because that decides whether users are recreated or simply re-linked on the target. Check each platform's documentation for whether user records can be exported and in what format. The step is done when the inventory has a row for every account, a named owner for each group and a written decision on who is migrated, who is recreated and who is retired.
Decide what chat history is worth carrying
The team agrees which conversations need to move, such as shared knowledge threads or records a compliance owner must keep, and which can stay on the old system until retention ends. Retention obligations are set by your own policy and legal review, not by the platform. Ask each vendor how chat records are stored and whether a supported export or import path exists before promising history to users. The step closes with a signed list of retained conversation sets and the retention owner for each.
Map model configuration and prompts
Record each model the team uses, the endpoint it calls, default parameters, system prompts, and any saved prompt library entries or presets. Open WebUI centers on Ollama and OpenAI-compatible endpoints, while LibreChat is organized around a broader provider list and its own configuration file, so the same model may need a different connection definition on the target. Confirm the configuration format for each product in its documentation before writing any mapping. The output is a side-by-side table of source setting, target setting and the person who approved the change.
Rebuild provider connections and secrets
The platform engineer creates the provider connections on the target, storing API keys and endpoint URLs in the secret handling your organization already uses rather than copying plaintext from the old configuration. Each connection is tested with a non-sensitive prompt against the same model used on the source. Vendor licenses for model providers stay with your contracts, so confirm that each account is still valid for the new deployment. The check is a log showing every connection returning expected responses and a list of any provider that could not be reached.
Rebuild retrieval content and document sources
Retrieval-augmented content does not move as a simple file copy. The team lists each document collection, its source, its access rules and the embedding model used to index it, then re-ingests the material into the target's retrieval setup. If the target uses a different vector store or embedding pipeline, the indexes must be rebuilt rather than carried over. Confirm the supported ingestion method for each platform in its documentation. The step is complete when document counts and sample retrieval queries match the source results within the tolerance the content owner accepts.
Run a pilot with a bounded group
A small group of staff who represent the main use cases signs in to the target and performs their normal tasks, including provider calls, retrieval questions and access checks for restricted groups. Support staff log every defect and the workaround used. Pilot users should not rely on the target for records that are still being migrated. The pilot is finished when the agreed test cases pass, access tests show no user seeing content outside their group, and the owner signs off in writing.
Cut over and confirm the old system is retired
The team announces the switch date, makes the source read-only, runs a final delta of users and settings, and points staff to the target. The old deployment is kept for the retention period set in step two before decommissioning, with backups verified first. Your security or compliance lead confirms that access to the old system has been removed for everyone who no longer needs it. The step closes when the change record shows the cutover time, the final delta, the backup reference and the decommission approval.
How identity integration and extensions affect the choice
Identity integration and extensibility can decide this comparison more than feature lists do, but the supplied research does not establish which single-sign-on protocols, group-to-role mappings or plugin mechanisms either platform supports today. Treat every claim about login, directory sync and extensions as unverified until you have checked the current documentation for the exact release you plan to deploy. Start with the Open WebUI documentation and the LibreChat repository, and record the version each answer applies to, because both projects change quickly.
For Open WebUI, ask whether the release you intend to run supports the identity provider you use, whether group membership from that provider can be mapped to its user roles and whether role changes propagate on the next login or only when a user is created. Confirm which of these features sit in the free build and which depend on a paid or enterprise license under the Open WebUI License, since that also affects your branding obligations. For LibreChat, ask the same questions about its authentication configuration and whether its team or group features cover your access model. Ask both vendors how a user removed from the directory loses access to existing sessions and stored conversations.
On extensions, the question is what your team must build or maintain. Ask whether each platform supports custom model endpoints, tools, plugins or actions through documented interfaces, and whether those interfaces are stable across upgrades. A custom integration that depends on an undocumented internal API will need rework on every release, so price that maintenance into the decision. Write these answers into your evaluation record, test them in a staging environment with a non-production identity provider, and bring the results to any quote so that the implementation scope covers the integrations you actually need.
Questions buyers ask before choosing or hiring help
What drives the cost of running Open WebUI or LibreChat in-house?
Cost depends mostly on the work and infrastructure around the software, because both projects are self-hosted and their license terms set when a license is needed. The main cost components are:
- Infrastructure in your own cloud, data center or air-gapped network, which recurs every month.
- Model access, from local models served through Ollama to paid API keys from cloud providers, which recurs with usage.
- Implementation, identity integration, hardening and documentation, which is one-time unless you add a retainer.
DeployOpen does not publish a price list. A quote follows from the written scope, so ask for each deliverable, which items are one-time and which are retainer work. Confirm any enterprise license fee for Open WebUI with the vendor before you budget.
How long does a chat front end deployment take?
Duration depends on scope, and no timeline figure is supplied here for either platform, so confirm any number in writing before you plan a launch. The factors that move the schedule most are the identity provider integration, the number of model providers you connect, search and retrieval configuration, any branding changes, and the hardening and evidence you need for an assessment. LibreChat's reference Docker Compose setup adds MongoDB, Meilisearch and a separate RAG API service, and each one needs configuration, monitoring and backups. Ask for milestones, acceptance criteria and a named owner for each one in the written scope so the timeline is tied to deliverables rather than to hope.
What does our team need to provide for a chat deployment project?
Your team needs to supply decisions and access that only your organization can give. Plan for the following before work starts:
- A named technical owner and a business owner who can approve scope changes.
- Administrative access to your identity provider, so single sign-on can be configured and tested.
- Accounts and network paths in your cloud, data center or air-gapped environment.
- Model endpoints, whether Ollama hosts for local models or approved API keys for cloud providers.
- Data classification rules that decide which content may reach which model.
- Test users who can run acceptance checks on real workflows and sign off in writing.
Without these inputs, schedules slip and the scope has to be reopened.
Can an internal team run Open WebUI or LibreChat without outside help?
A small internal team can run either platform for a pilot if it can operate containers, databases, backups and upgrades. The difference is in the moving parts. LibreChat's reference stack runs the app with MongoDB, Meilisearch and a RAG API service, so your team must maintain three stateful components and their search indexes. Open WebUI's documentation describes support for Ollama and OpenAI-compatible APIs and says it is built to run entirely offline, so confirm in its documentation which supporting services your chosen configuration needs. Before deciding, have an engineer deploy both in a test environment and record the operations tasks each one creates for a month of real use.
How do upgrades and release channels affect the choice?
Upgrade cadence is a real operating cost, so check each project's release channel before you commit. Open WebUI v0.12.3 was published on October 16, 2026, according to its GitHub releases page. LibreChat's latest tagged release, v0.8.8, was published on October 1, 2026 and is marked as a pre-release, so production teams should pin to stable tags and test each upgrade in staging first. Ask your team who will read release notes, who approves upgrades and how rollbacks work. DeployOpen offers upgrades as part of an ongoing retainer, and the scope for any upgrade work is agreed in writing before it starts.
Do Open WebUI's branding terms affect what we can change for staff?
Yes, if you plan to remove or alter Open WebUI branding. Open WebUI moved to the Open WebUI License effective with v0.6.6 on April 19, 2025, and code merged up to and including v0.6.5 stays BSD-3-Clause. The license permits changing branding only when the deployment has no more than 50 end users in a rolling 30-day period, when the copyright holder gives written permission, or when you hold an enterprise license. A staff-wide deployment will often exceed 50 users, so plan for one of the other two paths. LibreChat is MIT licensed. Have your counsel read the Open WebUI license documentation and the LICENSE file before you commit to a branding plan.
Does LibreChat's acquisition by ClickHouse create a risk for us?
The acquisition is a point to verify, not a reason to avoid LibreChat by default. ClickHouse announced on November 4, 2025 that it had acquired LibreChat and said existing deployments continue unchanged, with ongoing investment in the open-source project. The code remains MIT licensed. Ask the questions a procurement team would ask of any vendor-backed project: whether the roadmap for your features is public, how security fixes are published, which release channel the company will support and what would change if the project's direction shifted. Document your answers and revisit them at each major upgrade. Read the ClickHouse announcement for the company's own statement.
What does a DeployOpen engagement cover for either platform?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide. DeployOpen does not publish a price list, so ask for a written scope and a quote built from it.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a chat front end decision, that means we start from your user count, branding requirements and the team that will run the service, then build only what the written scope covers.
How we scope
- Confirm the expected number of end users and how they will sign in to the chat front end.
- Record whether branding must be changed, and which license path your organization has confirmed for that.
- Agree the model providers, including any local Ollama models, and where each one runs.
- Document who will operate, upgrade and back up the service after handover, and their skill set.
- Put scope, deliverables and timelines in writing before any work starts, as fixed-scope engagements.
How we build
- Deploy the chosen front end in your infrastructure, with the database and search services it requires.
- Connect identity, model endpoints and logging to your existing standards and access controls.
- Test authentication, role separation and data handling against the written requirements.
- Harden the deployment settings and record each configuration decision in the design documentation.
- Prepare control evidence for your compliance assessment, without issuing any audit or certification.
How we hand over
- Deliver runbooks covering installation, upgrades, backup, restore and the license obligations you must track.
- Walk your operators through routine tasks and a documented recovery exercise before handover.
- Provide a written comparison of the two front ends' operating footprints for your own records.
- Record every version deployed, so your team can check future release notes against its environment.
- Confirm ownership of configuration, documentation and access credentials at the close of the engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version reviews for the front end and its dependencies, scoped in writing.
- Ask for a quote that separates one-time build work from recurring support, so costs stay visible.
- Confirm with the vendor any licensing terms that change between releases before you upgrade.
- Agree response expectations and escalation paths in the retainer scope before signing.
