Zuora vs Lago: when each option fits
Zuora fits best when billing is one part of a broader subscription and finance operation and the organization wants a vendor-operated service with a wide scope. If your renewal is near, or your data residency rules are tightening, the question is less about whether Lago can meter usage and more about what else Zuora does for you today. Self-hosted Lago fits a different profile: metering-centric billing where usage events, pricing rules and invoices are the core of the business, infrastructure you control, and an in-house team that can operate PostgreSQL, Redis, the API and worker processes, and the Gotenberg PDF service that the Docker Compose deployment runs. Lago is open-source monetization infrastructure that meters usage, applies pricing, and produces invoices and payment collection, so it covers the billing engine but not the payment processor itself, which you still connect through a provider such as Stripe, Adyen or GoCardless.
The decision turns on three questions. First, is revenue recognition or another finance module in scope? Lago's documentation describes billing, invoicing and collection, and its integrations include NetSuite, Xero, Salesforce and HubSpot, but you should confirm with the Lago team exactly which accounting outcomes your finance team needs and whether they must come from a separate ledger or revenue tool. Second, what is your event volume? Lago's self-hosted setup keeps ClickHouse as an optional external store for high-volume events, and it is disabled by default, so a high-volume usage model needs a sizing exercise before you commit. Third, who will run the platform? Ask your team to name the owners for database operations, worker scaling and upgrades, since Lago recommends pinning the last tagged version rather than the latest image tag.
Treat every Zuora capability in this comparison as something to confirm against Zuora's current documentation and your own contract, not against this page or older material. Map each feature your finance and revenue teams rely on to a named owner in Lago or in a separate system, and note where the answer is a gap. Lago's open-source edition covers fundamental billing features, while Enterprise plans add premium features, so list the features you need and check which edition provides them before you estimate the work.
Which option fits which scenario
This table matches common buyer situations to the option that usually fits better, and the condition that tips the balance. Read each row against your own catalog, volumes and team, since the answer often changes with one requirement. Zuora remains the stronger choice where a broad finance suite and vendor support matter more than owning the stack.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Usage-based pricing with high event volume | Lago, self-hosted | Event volume is large and you are willing to plan ClickHouse as an optional external store, which Lago disables by default. Confirm sizing with Lago's current documentation and your own event test. |
| Subscription plus usage across multiple legal entities | Zuora, or Lago with careful design | Zuora covers multi-entity billing and finance workflows out of the box. Lago can model entities, but you should confirm how it handles your intercompany and consolidation needs before choosing it. |
| Revenue recognition inside the billing stack | Zuora | Zuora offers revenue capabilities that Lago does not cover. If you need recognition in the same system, plan a separate revenue or ERP tool for Lago. |
| Data residency requirement | Lago, self-hosted | You need billing data and invoices to stay in regions or networks you control. Self-hosting Lago inside your own cloud account or data center keeps that data in your environment. |
| Small team without billing engineers | Zuora, or a managed Lago partner | Lago requires your team to run PostgreSQL, Redis, workers and PDF generation, and to upgrade by pinned release. Without that capacity, a vendor-run service or an implementation partner reduces risk. |
| Renewal with a pricing change | Lago, if you can absorb the migration | A significant price increase makes the self-hosted cost model worth testing. Compare the Zuora renewal with your own run costs and migration effort, and ask Zuora for the full scope of the new terms. |
| Payment processing and card vaulting | Depends on your processor setup | Lago needs a separate processor such as Stripe, Adyen or GoCardless. Zuora's gateway integrations and tokenization handling differ, so confirm token portability before committing. |
| Accounting and ERP integrations | Zuora, unless your stack matches Lago's connectors | Lago lists NetSuite, Xero, Salesforce and HubSpot. If your ERP or CRM is not on that list, confirm what custom integration work is required. |
How Lago stores events, and when ClickHouse is needed for high volumes
On the default Docker Compose deployment, Lago keeps application data in PostgreSQL and uses Redis as its job queue. The same stack runs a front end, an API, an API worker, a clock worker and Gotenberg for PDF generation. ClickHouse is disabled by default, so usage events are handled in the main database. For moderate event volumes, this single-node setup is the simplest to operate, and it is the configuration most teams should prove first. Review the Lago self-hosted Docker guide before you deploy.
- Single database: customers, subscriptions, events and invoices sit in PostgreSQL, so one backup and restore plan covers the billing record.
- Redis as the queue: background jobs such as invoice generation wait in Redis, so queue depth and memory are the first signals to watch.
- Clock worker: it schedules recurring work such as period closes, so a stalled clock worker delays invoices without an obvious error in the front end.
- PDF rendering: Gotenberg produces invoice PDFs, so test output with your actual invoice templates before go-live.
- Version pinning: the self-hosting docs advise pinning a tagged release, and your change log should record which tag runs in production.
Confirm that a full billing cycle, including month-end, completes on this stack with your expected event load and queue behavior.
ClickHouse is an optional external store for high-volume events. Enabling it moves event writes and aggregation out of PostgreSQL, which is built for transactional records. Usage aggregation over billing periods is the workload that grows fastest, so the decision depends on how many events you ingest, how long you keep them and how often you query them. Turning it on is a deliberate architecture change that adds a second data engine to your operations.
- Separated event workload: raw usage events no longer compete with invoice data for the same database resources.
- Added operating burden: ClickHouse needs its own backups, upgrades, monitoring and capacity planning, usually owned by the data or platform team.
- Retention decisions: define how long raw events must remain queryable for disputes and audits, since retention drives storage growth.
- Different query patterns: near-real-time usage views and per-customer aggregation load the system differently from month-end invoicing, so measure both.
- Migration path: ask Lago how events already stored in PostgreSQL are handled if you enable ClickHouse after go-live.
Replay a representative event stream into a test environment with ClickHouse enabled, then compare invoice totals with a PostgreSQL-only run of the same data.
Larger deployments move from Docker Compose to Kubernetes with Helm charts and run dedicated workers, so each job type can be scaled and restarted on its own. Lago's self-hosting guidance points larger installations to this model. The platform team becomes responsible for the cluster, storage classes, secrets, network policy and the database tier that the charts assume. The database and queue placement is the first decision to make, because it determines who patches and backs up each service.
- Helm charts: confirm that the chart version matches the Lago release you pin, and test upgrades in a staging cluster first.
- Dedicated workers: separate API and background workers so a surge in event processing does not starve invoice generation.
- Managed or cluster-run data services: choose whether PostgreSQL and Redis run as managed cloud services or inside the cluster, which changes your patching and recovery work.
- Scaling signals: queue depth, database connection counts and event store load indicate which worker type needs more capacity.
- Ownership: name the team that carries on-call duty for the cluster, the workers and the scheduled billing jobs.
Load test the chart, database tier and worker counts against your real billing calendar, including the heaviest month-end run.
A fair comparison starts with how each system receives usage. Zuora documents its own usage ingestion and upload methods in its product documentation, and that material should be read alongside Lago's event API and storage design. The goal is to map where each platform accepts usage, where it aggregates it and how long it keeps the raw records. Use Zuora's current documentation rather than assumptions from older contracts or implementation notes.
- Ingestion method: note whether Zuora usage arrives by file upload, API or both, and map each path to Lago's event submission.
- Documented limits: record any file size, row count or rate limits Zuora states, and compare them with your peak usage.
- Aggregation location: identify where each platform rolls usage into charges, and whether Lago's aggregation runs in PostgreSQL or ClickHouse in your deployment.
- Timing rules: compare when usage becomes billable and how late-arriving events are treated in each system.
- Reporting continuity: list the usage reports finance uses today and confirm they can be rebuilt from the Lago data store.
Request Zuora's current usage documentation in writing, then run the same usage file through both systems and compare the resulting invoices line by line.
Capabilities side by side
This table compares Zuora Billing and Lago across metering, pricing, invoicing, payments, accounting, licensing and hosting. Where a supplied fact does not answer a question for Zuora, the cell tells you what to confirm with Zuora, so use the table as a checklist for a renewal conversation. The main takeaway is that Lago's documented scope centers on usage metering, invoicing and collection, while revenue recognition and several enterprise features need confirmation before you rely on them.
| Capability | Zuora Billing | Lago (self-hosted) |
|---|---|---|
| Usage metering and aggregation | Confirm with Zuora how usage ingestion, aggregation and volume limits work for your event rate | Meters usage and applies pricing as a core function; event volume handling depends on configuration |
| High event volumes | Confirm with Zuora the supported ingestion throughput and any usage data limits | ClickHouse is an optional external store for high-volume events and is disabled by default, so you must enable and size it |
| Pricing models | Confirm with Zuora which usage, tiered, prepaid and hybrid models are available on your contract | Lago's documentation describes applying pricing to metered usage; confirm the specific pricing models your plan needs |
| Invoicing and PDF output | Confirm with Zuora the invoice templates, languages and tax handling included | Produces invoices; PDF generation runs through Gotenberg in the Docker Compose stack |
| Payment collection | Confirm with Zuora which payment gateways are connected and how they are billed | Calculates amounts and timing, then sends charges to a separate payment processor; Stripe, Adyen and GoCardless are named as supported providers |
| Accounting integrations | Confirm with Zuora the connectors available for your general ledger and CRM | Listed integrations include NetSuite, Xero, Salesforce and HubSpot; confirm connector depth and version support |
| Revenue recognition | Confirm with Zuora whether revenue recognition is included in your licence or sold separately | Not covered by the supplied product description; confirm with Lago and plan for a separate ledger or accounting process |
| Multi-entity support | Confirm with Zuora how multiple legal entities and currencies are handled | Confirm with Lago whether multiple organizations or entities are supported in your edition |
| Hosting options | Vendor-hosted SaaS; confirm with Zuora whether any self-managed option applies to you | Self-hosted with Docker Compose or Helm charts for larger deployments, in your own cloud or data center |
| Licensing and editions | Commercial subscription; confirm with Zuora the contract terms and editions | AGPLv3 platform with a forever-free open-source edition; Enterprise plans add premium features. Agent SDKs and MCP server are MIT licensed |
Where the data lives and who controls the platform
Zuora Billing runs as a vendor-operated service, while Lago can run inside your own cloud account or data center. The cards below cover where customer, invoice and payment-adjacent records sit, who sets upgrade timing, and which compliance evidence you must produce yourself.
Hosting model and operator
Zuora operates the billing platform as a subscription service, so the vendor controls infrastructure, patching and availability. Lago's Docker Compose deployment runs a front end, an API, workers, PostgreSQL, Redis and Gotenberg inside your own cloud account or data center, which makes your team the operator. Check who on your side will own on-call, backups and database maintenance before you commit to self-hosting.
Customer and invoice record location
Self-hosted Lago keeps accounts, subscriptions, usage events and invoices in the PostgreSQL database you provision, and any ClickHouse store you enable for high-volume events. Map each of these records to a region and a backup target before go-live. Payment card data is held by your payment processor, such as Stripe, Adyen or GoCardless, not by Lago, so confirm where that processor stores it.
Upgrade timing and version pinning
Lago's self-hosting docs recommend pinning the last tagged version rather than the latest image tag. Lago v1.55.0 was released on October 7, 2026, after v1.54.0 on October 6, 2026, so release cadence is fast. Your team decides when to test and promote each tagged release, and must plan that work against invoice run dates.
AGPLv3 obligations for your team
The Lago platform is licensed under AGPLv3, while its agent SDKs and MCP server are MIT licensed in separate repositories. AGPLv3 carries source-availability obligations that can apply when you modify Lago and make it available to users over a network. Ask counsel to review how any custom billing changes, connectors or internal forks interact with those terms, and confirm which repositories each component uses.
Controls and evidence you must produce
Zuora's vendor produces many of its own control reports, while a self-hosted Lago deployment leaves access control, change management, backup testing and logging evidence with your organization. DeployOpen can prepare those controls and the evidence trail for your assessment, but it does not issue audit reports or certifications. Your independent auditor decides what is sufficient for your scope.
Support and hosted edition boundaries
Lago's open-source edition covers fundamental billing features, while Enterprise plans add premium features. Confirm in writing which features you need, such as advanced reporting or revenue capabilities, sit in the open-source edition and which require a paid plan. Ask Lago which support terms apply to self-hosted customers before you set your operating model.
How payments and invoices flow through Lago
Lago does not collect money itself. It meters usage, applies your pricing, produces invoices and decides how much to charge and when, then hands that charge to a separate payment gateway. Lago's FAQ states this directly, and its README names Stripe, Adyen and GoCardless as supported providers. In a Zuora vs Lago comparison, this is the first structural difference to plan for: Zuora's payment capabilities and Lago's payment flow are not the same thing, so the processor you choose becomes a contract and architecture decision in its own right. Confirm with your chosen provider whether it supports the payment methods, currencies and recurring mandates your customers use today, and whether its webhooks can be consumed by a self-hosted Lago instance.
Card handling is where scope changes most. Lago's design keeps payment processing with the gateway, so the question for your security team is whether any cardholder data or card tokens ever reach your own environment. Ask your processor which vault holds stored payment methods, whether Lago stores only provider references, and how the PCI DSS responsibility split is documented for a self-hosted billing stack. Reconciliation then runs across three records: Lago's invoices, the gateway's settlement reports and your general ledger. Agree in advance who owns the matching, how failed and retried charges are represented, and how refunds and disputes are posted. Confirm these flows with your auditors rather than assuming the processor's documentation covers your setup.
For accounting, Lago's README lists integrations with NetSuite, Xero, Salesforce and HubSpot. Treat these as listed connectors, not as proof of the depth you need. Before relying on any of them, confirm which objects sync (customers, invoices, payments, credit notes, tax lines), whether syncs are one way or bidirectional, how mapping of products and chart of accounts is maintained, and what happens when a sync fails. PDF invoice generation depends on Gotenberg, a separate service in the Docker Compose deployment that Lago's self-hosted documentation lists alongside PostgreSQL, Redis and the workers. Your team will need to monitor, patch and size Gotenberg, and test invoice rendering after every upgrade, since invoice PDFs are often the document customers and auditors ask for first.
What drives the cost of Zuora and self-hosted Lago
Zuora's cost sits mostly in a subscription contract and partner work that you can only price after a written quote. Self-hosted Lago has no licence fee on the open-source edition, so its cost is the infrastructure, operations and integration work you carry yourself. The cards below show who gets paid for what, and which parts recur.
Zuora subscription fees
Zuora's subscription is recurring and set by your own contract, and Zuora does not publish its prices. Its fee usually scales with the modules, usage volume and entities you license, so the same billing scope can cost very different amounts across customers. Ask for a written quote that lists each module, the usage metering tier, the number of entities and the term length, and confirm which of these change at renewal.
Zuora implementation partner fees
Zuora configuration, catalog design and data migration are often delivered by a Zuora-certified or independent partner, who bills by project or by day. These fees are one-time for the initial build but return for every new product, price change or integration you add later. Ask partners to separate discovery, build, testing and go-live into distinct line items so you can see which parts repeat.
Zuora renewal uplift
Renewal terms decide how much the subscription grows after the first term, and this is often the largest cost change over time. Check whether the contract sets a fixed uplift, links pricing to an index, or allows the vendor to reprice based on usage growth. Usage-heavy pricing models can trigger tier changes, so model your event volume for the next term before you agree to a renewal.
Lago software licence
The Lago platform is licensed under AGPLv3, so the open-source edition carries no licence fee, and Lago's FAQ describes it as a forever-free edition with fundamental billing features. Enterprise plans add premium features for a fee that Lago quotes directly, so ask for that quote and confirm which features you need are in the free edition. Under AGPLv3, review your obligations if you modify the code and offer it to users over a network.
Lago infrastructure and operations
Lago runs as a Docker Compose stack or on Kubernetes with Helm charts, and it needs PostgreSQL for application data, Redis as the job queue, and workers for invoicing and scheduled jobs. These costs recur as cloud or data center capacity, backups, monitoring and upgrades. They rise with event volume and invoice runs, and optional ClickHouse adds a separate store to size and operate once you enable it for high-volume events.
Integration and internal staff time
Connecting Lago to a payment gateway such as Stripe, Adyen or GoCardless, and to accounting tools such as NetSuite or Xero, is custom work that you or a partner deliver. Your engineers also own upgrades, security patches and on-call duties after go-live. These costs are partly one-time for the integration and partly recurring for staffing, so ask for a support model with named owners and a plan for each Lago upgrade.
What moving billing from Zuora to Lago involves
The sequence runs from inventorying what Zuora holds to a parallel invoice run, a reconciled payment reconnection and a cutover, so the team knows the new billing setup matches the old one before Zuora is retired.
Inventory catalog, usage and invoice history
Finance operations and billing engineers export a complete picture of the current product catalog, rate plans, charge models, usage metrics as they are sent to Zuora, active subscriptions and at least the invoice history the business must keep. Map each Zuora object to its owner and to where it will live after cutover. The step is done when the team has a written inventory signed off by finance and engineering, with every usage source listed. Data export mechanics are covered on the separate Zuora export page, so this step only defines what must be extracted.
Confirm which finance functions stay in Zuora
Decide, with the finance and controllership leads, which functions remain in Zuora or move elsewhere. Lago covers metering, pricing, invoicing and payment collection, and integrates with accounting tools such as NetSuite and Xero. Revenue recognition and other Zuora capabilities that Lago does not cover must be assigned to a named system or process, whether that is the general ledger, a separate revenue tool or a manual schedule. The step is done when each Zuora function has a documented destination and an owner, and gaps are recorded as decisions rather than surprises.
Model pricing as Lago billable metrics and plans
Translate each usage metric into a Lago billable metric with its aggregation type, then build plans and charges that reproduce the existing rate cards, tiers, minimums and commitments. Test edge cases such as mid-period plan changes, credits and prorations against known invoices from the inventory. Because pricing logic is the main source of migration effort, this is where the team should expect the most review cycles. The step is done when a set of representative historical accounts produces the same charges in Lago that Zuora produced for them.
Stand up a pinned Lago version in your environment
Platform engineers deploy Lago in the organization's own cloud account or data center, using the Docker Compose setup for a small deployment or Helm charts for larger ones. The stack includes the front end, API, workers, PostgreSQL, Redis and Gotenberg, with ClickHouse added only if event volumes require it. Pin the last tagged release rather than the latest image tag, as the self-hosted documentation recommends, and record the version in change control. The step is done when the environment passes backup, restore and access checks and the pinned version is documented for upgrades.
Run parallel invoice cycles and reconcile
Run Lago alongside Zuora for at least one full billing cycle using the same usage data, and compare each generated invoice line by line with Zuora's output. Reconcile differences in amounts, tax, rounding, dates and customer records, and classify each as a configuration error, a data issue or an intended change. Share the reconciliation with finance before anyone relies on Lago for live invoices. The step is done when the differences are either closed or formally accepted, and the finance team signs off on the reconciliation report.
Reconnect the payment gateway
Lago calculates what to charge and when, and sends the charge to a payment provider such as Stripe, Adyen or GoCardless, so the processor connection must be set up in Lago and tested with sandbox transactions first. Confirm how stored payment methods will move, since card data cannot be copied out of Zuora without the processor's cooperation, and agree that process with the gateway and your PCI DSS scope owner. The step is done when test charges, refunds and webhook events succeed end to end and the card data handling has been reviewed.
Cut over and retire Zuora after the export window
Switch invoice generation to Lago at a defined cycle boundary, freeze changes in Zuora for that cycle, and keep Zuora read-only for reference. Before the contract ends, complete and verify every export the retention plan requires, and confirm that historical records are available in the form auditors and tax authorities will need. The step is done when the first live cycle in Lago reconciles, the export archive is verified and the Zuora contract termination is confirmed in writing.
Questions buyers ask before switching from Zuora to Lago
How much effort does a move from Zuora to Lago take?
The effort depends mainly on the shape of your catalog, the volume of usage events and how much history must move. A move is a fixed set of tasks: mapping plans and metrics to Lago's billable metrics and charges, rebuilding invoice templates, reconnecting payment and accounting integrations, and loading customers, subscriptions and open balances. Usage-heavy pricing with many metrics adds metering design and testing work, while a simple flat-rate catalog with little history moves faster. Ask any implementation partner to itemize these tasks in a written scope so you can see where the hours sit, and confirm with your own engineers which Zuora objects and exports you rely on today.
Can our own team migrate from Zuora to Lago without outside help?
A capable internal team can run a migration, but the work spans billing rules, finance controls and payment operations, so the question is whether those skills exist in-house. Lago's self-hosted deployment is documented, and its open-source edition includes fundamental billing features, so the software itself is accessible. What usually takes outside help is reconciling historical invoices, designing event metering that finance trusts and testing failure paths. Assess your team against those specific tasks, and if you bring in a partner, ask for a fixed scope that names what you keep in-house.
How long should a parallel run last before cutting over to Lago?
A parallel run should last until invoices produced by Lago match Zuora's output across a full billing cycle for every plan type you sell. Its length is set by your longest billing period, the number of usage metrics that must reconcile, and how many customer segments have special terms such as commitments, credits or taxes. Plan for at least one complete cycle, plus time to investigate every variance. Agree the exit criteria in writing before the run starts, so that finance signs off on a defined reconciliation rather than on a feeling that the numbers look right.
What does a Zuora to Lago move need from finance, engineering and payments teams?
Each team owns a different part of the result. Finance defines the revenue and invoice rules, approves the reconciliation criteria and decides how open balances and credits are carried over. Engineering owns event ingestion, the metering logic, the API integrations and the monitoring that tells you usage events are arriving. The payments team connects a processor such as Stripe, Adyen or GoCardless, which Lago requires as a separate component, and tests retries, declines and refunds. Name a single owner for each area in the scope, because gaps between these teams are where billing errors usually appear.
Does Lago cover revenue recognition the way Zuora does?
Lago is built to meter usage, apply pricing, produce invoices and collect payment, and its documentation does not describe a revenue recognition module, so you should not assume Zuora's revenue capabilities carry over. If your Zuora setup feeds revenue schedules, plan for that function separately, either through your accounting system or another tool. Confirm the current scope directly with Lago and with your auditors before you decide, and document which revenue outputs finance needs in the written scope so nothing is lost at cutover.
What does running Lago in production require after the move?
Running Lago means keeping its services, data and dependencies current. The Docker Compose deployment includes a front end, an API, workers, PostgreSQL, Redis and Gotenberg for PDF generation, and its documentation recommends pinning the last tagged version instead of the latest image tag. Ongoing work covers planned upgrades with tested rollback, tested backups of PostgreSQL, monitoring of workers and job queues, and patching of the underlying hosts. Larger deployments point to Helm charts and dedicated workers. Ask for a written operations runbook and an upgrade procedure as deliverables, and decide whether that work stays in-house or moves to a retainer.
What should a written scope for a Zuora to Lago migration include?
A useful scope lists the Zuora objects in use, the catalog and metrics to rebuild, the integrations to reconnect and the data to migrate, each with an acceptance test. It should name the payment processor and accounting system, state the parallel run and its exit criteria, and list which outputs, such as revenue schedules, are excluded. Include the runbook, training, cutover steps and a post-cutover support period. Confirm the license model for the Lago edition you choose, and ask how changes to scope are priced before work begins. Most engagements are fixed-scope, so the written scope is what you will be measured against.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Zuora vs Lago, we start with a written scope that matches your pricing model, event volumes and finance systems before any build work begins.
How we scope
- Map your current usage metrics, pricing plans and invoice cycles to Lago's billable metric and plan model
- Inventory event volumes to decide whether PostgreSQL is enough or ClickHouse is needed for high-volume events
- Confirm which payment gateways, accounting targets such as NetSuite or Xero, and tax handling are in scope
- Agree in writing which Zuora capabilities, such as revenue recognition, are handled elsewhere and who owns them
How we build
- Deploy Lago in your environment, pinning a tagged release rather than the latest image, with Redis, PostgreSQL and Gotenberg configured
- Configure event ingestion, aggregation and test pricing scenarios against replayed sample usage before any live cutover
- Connect your chosen payment provider such as Stripe, Adyen or GoCardless and the agreed accounting integrations
- Run security testing on the APIs and deployment, and document the controls and evidence your compliance assessors will need
How we hand over
- Deliver architecture diagrams, configuration records, runbooks for the clock and API workers, and the event pipeline
- Document how to upgrade Lago versions, including review of release notes before each change
- Provide reconciliation procedures so finance can compare Lago invoices with payment provider and ledger records
- Train your operations and finance staff on invoice runs, plan changes and exception handling
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Schedule version upgrades and back up the database and configuration before each change
- Retest pricing logic and integrations whenever plans, payment providers or accounting connections change
- Confirm the terms, response expectations and coverage of any retainer in writing before work starts
