Subscription billing cost: when self-hosted open source costs less than billing SaaS
The answer depends on your revenue trajectory, metering volume, plugin needs, compliance scope and who will operate the platform, and the software license is usually the smallest line item. Kill Bill is licensed under Apache-2.0, and the release killbill-0.24.22 was published on September 29, 2026. Lago's core is also available without a license fee. That means the cost of self-hosting sits elsewhere: hosting, implementation, integrations, tax and payment gateway plugins, optional enterprise support and internal engineering time. A billing SaaS charges fees that typically scale with the revenue or volume it processes, so the comparison shifts as the business grows. Confirm the current license terms and any paid components directly with each vendor before you model costs, because edition boundaries can change.
Start by quantifying the costs the buyer must own. Ask for a written inventory of the following: infrastructure for the billing application, its database, workers and event processing; the hours to design the catalog, configure payment gateways and build invoice templates; tax engine integration; accounting and general ledger sync; and the ongoing hours for upgrades, security patching and incident response. Ask also whether a Kill Bill enterprise support arrangement or a Lago support plan is needed for your use case, and what it covers. Compare these against your current SaaS invoice at three points in your revenue curve, not only today's figure. The DeployOpen implementation scope, deliverables and timelines are set out in writing before work starts, so any partner quote should follow the same written scope for every option you compare.
Two cost drivers are often underestimated: compliance scope and metering volume. If the self-hosted system stores or routes card data, the controls and assessment effort rise, and the FTC Safeguards Rule text at 16 CFR 314.4 requires annual penetration testing and vulnerability assessments at least every six months where continuous monitoring is not in place. High event volumes raise database and infrastructure costs, which the sibling topics on usage-based billing and PCI scope examine in detail. Build a three-year model with one-time and recurring lines separated, then ask each candidate partner to price the same scope, the same upgrade cadence and the same support hours. Label the scenarios as illustrative until they reflect your own numbers.
Cost components: in-house, implementation partner and billing SaaS compared
This table compares who pays for each cost component under three models: running self-hosted Kill Bill or Lago in-house, buying implementation from a partner, and using a billing SaaS. Read each row for the payer, whether the cost is one-time or recurring, and the points to confirm before signing. The main takeaway is that self-hosting moves cost from vendor fees to infrastructure, engineering and assurance work, so the comparison depends on your revenue trajectory and internal capacity.
| Cost component | In-house self-hosted | Partner-delivered self-hosted | Billing SaaS |
|---|---|---|---|
| Software license | Kill Bill is Apache-2.0 licensed and Lago is open source, so there is no license fee for the core platform. Confirm the license terms of each component you deploy. | Same open source core, so no license fee for the core. Confirm whether the partner charges for any proprietary add-ons or connectors. | Subscription fee to the vendor, usually tied to revenue or volume. Confirm the pricing metric, the tier thresholds and how overages are billed. |
| Hosting and infrastructure | Recurring: you pay cloud or data center costs for application, database, queue and event store. Size with your metering volume and backup needs. | Recurring: paid by you to your cloud or data center provider, usually billed directly. Ask the partner to provide a sizing estimate in writing. | Included in the SaaS fee. Confirm which data regions are available and whether exports or backups carry extra charges. |
| Initial implementation (catalog, gateways, tax, GL sync) | One-time: your staff or contractors build the catalog, gateway connections, tax logic and ledger interface. Effort depends on pricing complexity. | One-time: paid to the partner under a fixed-scope written agreement. Ask for deliverables covering catalog migration, gateway and tax setup and GL interface testing. | Usually one-time configuration or professional services fee charged by the vendor. Confirm what the fee covers and whether custom integrations are extra. |
| Plugins and connectors | Recurring maintenance: you build or maintain payment, tax and accounting plugins. Confirm which connectors exist for your gateway and ledger. | Partly one-time (build) and recurring (maintenance and upgrades). Confirm which connectors the partner has delivered before and who maintains them after go-live. | Often bundled, sometimes charged as add-ons. Confirm which gateways, tax engines and accounting systems are supported natively. |
| Enterprise support (for example Kill Bill Aviate) | Null if you rely on community support. If you need a vendor support agreement, it is a recurring fee paid to the vendor. Confirm what the agreement covers and response terms. | Recurring fee paid to the vendor if you buy an enterprise tier such as Kill Bill Aviate. The partner may act as the first line of support, so confirm the handoff. | Included in the subscription tier. Confirm the support hours, escalation path and whether premium support is an extra charge. |
| Ongoing engineering and operations | Recurring: staff time for patching, monitoring, incident response, on-call and upgrades. Often the largest hidden cost of self-hosting. | Recurring if you buy an operations retainer, otherwise paid to your internal team. Confirm the scope of monitoring, backups and upgrade handling. | Mostly absorbed by the vendor. Your team still owns catalog changes, reconciliation and integration upkeep. Confirm the uptime commitments in writing. |
| Security testing and compliance evidence | Recurring: you pay for penetration testing, vulnerability assessments and evidence collection. Required for the FTC Safeguards Rule if continuous monitoring is absent. | Recurring or one-time, depending on scope. DeployOpen performs security testing and prepares compliance evidence; auditors issue any attestations, so budget for their fees separately. | Vendor provides its own assurance reports. You still need evidence for your own controls and any testing of your configuration. Ask the vendor which reports they share. |
| Upgrades | Recurring: staff time to test and apply new releases, including database migrations and plugin compatibility checks. | Recurring if covered by a retainer, otherwise one-time per upgrade project. Confirm whether upgrades are in scope and how rollback is handled. | Included and applied by the vendor. Confirm the release notice period and whether you can defer upgrades that affect your integrations. |
| SaaS subscription fees that scale with revenue | Null: no vendor fee scales with revenue, so cost rises with infrastructure and staff rather than with invoice volume. | Null: the partner is paid for delivery, not for a share of billings. Confirm that no revenue-based fee applies to the partner's work. | Recurring and usually rises as revenue or invoice volume grows. Ask for a five-year cost model at your projected growth, with the fee formula in writing. |
What moves the cost of self-hosted billing up or down
Self-hosted billing costs follow the shape of the business more than the software license, which is free under Kill Bill and Lago. The six drivers below set how much engineering, infrastructure and evidence work the platform needs, and each one should be priced into the written scope before comparing against a billing SaaS fee that grows with revenue.
Recurring revenue and invoice volume
Invoice count drives run-time load on the billing engine, the payment retry queue and the accounting sync. A SaaS fee usually rises with billed revenue or volume, while self-hosted cost rises with the servers, database capacity and operator time needed to keep invoice runs on schedule. Ask the partner how invoice runs are sized, how long a full cycle takes at your current subscriber count, and what headroom is included in the quote.
Metering and event volume
Usage events are the fastest-growing cost line for usage-based products. Every additional event type, retention window or aggregation query adds storage and compute, and the event store choice (Postgres or ClickHouse, for example) changes both the hardware and the people who run it. Confirm expected events per day, peak bursts and how long raw events must be kept before pricing the platform.
Pricing model complexity
Each pricing dimension (plans, seats, usage tiers, prepaid credits, add-ons and proration rules) multiplies catalog configuration, test cases and change requests. Simple flat plans keep the catalog small, while credit wallets and mid-term plan changes require more custom logic and more regression testing after every price change. Ask for the catalog to be listed by pricing dimension, and treat each one as a line in the scope.
Tax and VAT scope
Tax calculation is often the largest integration cost after the billing engine itself. A US sales tax engine or EU VAT rules with reverse charge add a tax plugin or service, a rule set that finance must maintain, and testing for each jurisdiction you sell into. Confirm which jurisdictions and invoice formats apply, who owns rate updates after launch, and whether the quote covers them or treats them as a later phase.
Payment gateway count and PCI scope
Each payment gateway adds a connector, webhook handling, reconciliation logic and a separate vendor relationship. Cardholder data handling determines the PCI DSS assessment type your organization must complete, so a design that tokenizes cards at the gateway or an orchestrator costs less to assess than one that stores card data in your own systems. Ask the partner which components touch card data and which self-assessment questionnaire type that design implies, then confirm with your acquiring bank or QSA.
Compliance evidence and integration count
Each general ledger, CRM or data warehouse connection needs mapping, error handling, reconciliation and a control record that auditors can sample. For regulated institutions, the FTC Safeguards Rule at 16 CFR 314.4 requires annual penetration testing, and vulnerability assessments at least every six months unless continuous monitoring is in place. Those tests, the access reviews and the change records add recurring work that a billing SaaS vendor partly absorbs, so price them as an ongoing line rather than a one-time cost.
Which costs are one-time and which recur every year
The first split to make is between one-time build costs and recurring run costs, because they behave differently in a budget. One-time items include requirements definition, catalog design, data migration from the current billing or spreadsheet process, payment gateway and tax plugin setup, the integration build to the general ledger and CRM, and cutover with parallel invoice runs. These are paid once, usually as fixed-scope work, though a second wave of catalog or integration changes is common in the first year. For a self-hosted Kill Bill or Lago deployment, the recurring side is what most teams underestimate: hosting and database capacity, backups and tested restores, monitoring and alerting, upgrade work for each platform release, security testing, plugin license renewals, optional support retainers, and the internal staff time needed to own all of it.
A billing SaaS replaces most of those recurring items with a subscription fee, but that fee usually scales with revenue, invoice volume or customer count rather than staying flat. That means the comparison is not a fixed line against a fixed line. A self-hosted platform carries higher upfront cost and a mostly fixed run cost, while a SaaS carries a lower start and a cost that rises with growth. The crossover point depends on your own pricing and volume, so ask each SaaS vendor for its fee schedule in writing and confirm which metric it bills on, such as revenue tiers, active subscriptions or processed invoices. Also confirm whether plugins, tax calculation or additional environments are billed separately.
Model both options over the same horizon your finance team uses for planning, typically the budget period plus the forecast years they already maintain, and include a growth scenario that reflects your expected revenue and customer count. Put every component in its own line: one-time build, annual hosting, annual staff time expressed as a share of named roles, annual testing and upgrades, and plugin renewals. Ask implementation partners to state in the written scope which items are fixed and which are time-and-materials, and ask SaaS vendors what happens to pricing above a stated volume. A model built this way shows where the lines cross and which assumption moves the result most.
How to build your own subscription billing cost estimate
This sequence turns vague cost assumptions into a comparable three-year model, so you can weigh self-hosted Kill Bill or Lago against a billing SaaS on the same written scope. Each step produces an input the next one depends on.
Inventory pricing models and invoice volume
Finance and product leads list every pricing model in use or planned, such as flat plans, seats, tiers, add-ons, trials, prepaid credits and usage charges. Next, record the number of active subscriptions, invoices per month and expected growth over the planning horizon. Done means a single table exists that both finance and engineering have signed off, because every later cost line depends on it.
List gateways, tax engines and general ledger integrations
Document each payment gateway, its card or bank rail, the tax engine (if any) and each system that receives billing data, such as the general ledger, revenue reporting and the data warehouse. Note which integrations exist as ready plugins and which would need custom work. Done means every interface has an owner, a direction of data flow and a note on whether it is an existing or new build.
Estimate metering volume and event storage
If any charge depends on usage, estimate events per day, peak rates, retention period and how quickly customers need to see usage. Engineering confirms whether the event store will be Postgres or a columnar store and what hosting that implies. Done means you have a volume estimate in events per month and a retention decision, which drive compute, storage and support effort in both options.
Choose the operating model: in-house, partner or SaaS
Decide who will run the platform: your own team, an implementation partner under a support arrangement, or a billing SaaS vendor. Record the reason for each choice, including skills you already have and the change-control obligations your auditors will expect. Done means one model is selected for each candidate you intend to price, so quotes compare like with like.
Request written scope and quotes from each candidate
Send the same written scope to every vendor and partner you are comparing. It should include the catalog, gateways, tax handling, integrations, environments, high availability, upgrades, backups and support hours. Ask each party to separate one-time implementation fees from recurring hosting, licensing, support and per-volume charges. DeployOpen prices follow from a written fixed scope rather than a published list, so a comparable scope is the only basis for an honest comparison. Done means each quote maps line by line to the same requirements.
Add internal engineering and finance hours
Estimate the internal effort that quotes do not show: engineering time for integration support, on-call coverage, upgrades and incident response, plus finance time for catalog changes, invoice reviews and month-end close. Record these hours as recurring unless they are a one-time migration or build task. Done means internal labor sits in the model with named roles and a rate your finance team has approved, so self-hosted options are not understated.
Add security testing and compliance evidence work
Include penetration testing, vulnerability assessments, access reviews, change records and log retention needed for your obligations, such as the FTC Safeguards Rule's testing requirements where it applies to you. Ask each candidate what evidence it produces and who prepares it. Note that DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications. Done means security and evidence work appears as separate recurring and one-time lines in every candidate's model.
Model a three-year view with recurring and one-time lines separated
Build one spreadsheet with a column per year and separate sections for one-time costs (design, implementation, migration, initial testing) and recurring costs (SaaS fees that scale with revenue or volume, hosting, support, plugins, internal hours). Run a sensitivity case for higher subscription counts and event volumes, and label any hypothetical figure as illustrative. Done means finance can see the cumulative cost per option and what would change it, which is the basis for the build, partner or SaaS decision.
Which operating model fits your team and risk profile
This model fits an organization with an existing platform engineering function that already runs production Postgres, Kubernetes or equivalent container platforms, observability and on-call rotations, and a limited compliance footprint around the billing data. The cost is mostly internal labor. Hosting, storage and monitoring recur every month, while the initial catalog build and integration work are one-time efforts that the internal team absorbs or contracts out in pieces.
- Staffing: Named owners for the billing service, the database, the payment gateway integration and the upgrade calendar for Kill Bill or Lago.
- Recurring costs: Cloud or data center capacity, backup storage, monitoring and the time spent on routine upgrades and security patches.
- Cost drivers: Event volume and retention for usage data, the number of payment gateways and tax connectors, and how often the catalog changes.
- Signals that favor it: Platform engineers already own similar stateful services, and the billing data falls mostly outside card data handling and financial reporting controls.
- Watch item: Upgrade and incident time often grows faster than teams expect once billing runs on the critical revenue path.
Confirm with your own platform team how many hours a month it can realistically give to billing before you compare any totals.
This model fits a finance or revenue operations team that owns the pricing and invoicing rules but lacks deep in-house infrastructure skills. The partner delivers the deployment, catalog configuration, gateway and tax integrations, and documentation, then hands operation to the internal team. The cost is front-loaded as a fixed-scope project, followed by recurring hosting and an optional support retainer.
- Staffing: A finance owner who approves catalog and price changes, a named operator who can run routine tasks, and a partner for the build and any later upgrades.
- One-time costs: Discovery, architecture, catalog migration, integration build, testing and the runbooks that transfer ownership.
- Recurring costs: Hosting, backups, a support retainer if chosen, and the internal time to review invoice exceptions and credits.
- Cost drivers: The number of legacy systems to migrate, the depth of general ledger integration and how much testing the finance team requires before go-live.
- Signals that favor it: Pricing changes are frequent, the company needs a documented handover, and internal platform capacity is limited.
Ask any partner for a written scope that lists handover deliverables and what is excluded from the fixed price.
This model fits a team that wants a billing SaaS to remain the system of record. The cost is a subscription that typically scales with revenue or volume, so the recurring line grows as the business grows. The team does not pay for hosting, patching or upgrades, but it still needs internal staff for catalog changes, integration maintenance and vendor management.
- Staffing: Revenue operations for catalog and invoice configuration, and an integration owner for accounting and CRM connectors.
- Recurring costs: The vendor subscription, any usage or transaction fees, and connector or add-on charges.
- Cost drivers: Revenue or invoice volume, the number of entities and currencies, and features that sit in higher pricing tiers.
- Signals that favor it: The team has no appetite for running a stateful financial service, data residency rules allow the vendor's hosting, and the current pricing model is stable.
- Watch item: Price growth tied to revenue can outpace the savings from avoiding infrastructure work, so model the cost at the volume you expect in three years.
Request the vendor's full price schedule, export and exit terms, and data residency statement in writing before you sign.
Subscription billing cost questions buyers ask before hiring a partner
How much does self-hosted subscription billing cost compared with a billing SaaS?
Self-hosted billing replaces a per-revenue or per-tier SaaS fee with a set of costs you pay directly: infrastructure, implementation, integrations, and the engineers who run the platform. The SaaS side scales with the revenue or invoice volume you process, so its cost rises as the business grows. The self-hosted side is front-loaded and mostly fixed, with recurring costs for hosting, upgrades, security testing and staff time. No supplied figures compare the two totals, so build your own model. Ask each vendor and partner to show one-time and recurring costs separately, and list which of them change with your volume.
How long does a subscription billing implementation take?
The timeline depends on scope more than on the platform name. The main drivers are the number of pricing models, the volume and complexity of usage metering, the number of payment gateways and tax rules, the depth of general ledger and CRM integration, and how many active subscriptions must be migrated from an existing system. Each of these adds design, build and testing work. Your partner should agree a duration in the written scope, with milestones for catalog design, integrations, parallel-run testing and cutover. Be cautious of any timeline quoted before the requirements are documented.
What does the work need from our finance and engineering teams?
Finance owns the commercial rules, and engineering owns the platform. Finance must define the catalog, price books, proration and credit rules, invoice formats, dunning policy, and the revenue and ledger mappings the billing data will feed. Engineering must provide environments, identity and access setup, network paths, secrets handling and integration endpoints. Both teams review test cases during parallel runs. Ask the partner to list these inputs and the people they need by role, so the internal time commitment appears in the quote.
Can our team run Kill Bill or Lago without a partner?
Some teams can, provided they have engineers who know the platform's data model, deployment, upgrades and payment and tax integrations, plus finance staff who can own the catalog. Kill Bill is an open source subscription billing and payments platform licensed under Apache-2.0, and its latest release named in our research is killbill-0.24.22, published on September 29, 2026. Running it in production means owning backups, monitoring, patching and incident response, which are ongoing tasks. Assess honestly whether that staffing exists before you decide, and ask a partner to define what they would hand over and what they would keep operating.
Is Kill Bill Aviate or another enterprise support plan required?
Enterprise support is optional. It is a decision about how much vendor-backed help your team wants, not a technical requirement for running the open source platform. Ask the vendor what Kill Bill Aviate includes, which response times and upgrade commitments it covers, and how it is priced, then compare that with the cost of internal staff or a partner retainer covering the same tasks. Also confirm which plugins you need, since some integrations may sit outside the core support scope. Get these answers in writing before you commit.
What costs recur after the billing system goes live?
Several costs continue after launch. These include hosting and database capacity, which grow with invoice and usage volume; payment gateway and tax engine subscriptions; security testing and vulnerability assessments; upgrades to new platform releases; backup and disaster recovery testing; and the staff time needed for monitoring and changes to pricing. For regulated businesses, access reviews and change records also recur. Ask any partner to separate one-time implementation fees from retainers and to state which items are optional. Note that DeployOpen offers ongoing support, upgrades and continuous testing as retainers, scoped in writing.
What should we ask for in a written quote for subscription billing?
A useful quote is built from a written scope, not a headline number. Ask for a list of deliverables, the assumptions behind each estimate, and the items excluded from scope. Request the following: the platform versions and plugins included; the number of pricing models, gateways, tax rules and integrations covered; the migration volume and method; testing and cutover responsibilities; handover documentation; support and upgrade terms; and the change process if requirements move. DeployOpen does not publish a price list, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How DeployOpen scopes, delivers and supports a fixed-scope billing implementation
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For subscription billing cost decisions, we turn the total cost picture into a written scope so that Kill Bill or Lago licensing, hosting, plugins, optional enterprise support and internal engineering time are priced against the same agreed deliverables.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which cost components sit in the written scope: hosting, implementation, gateway and tax plugins, and internal operations.
- The written scope states which billing SaaS fees are being compared, the revenue and invoice volumes used, and the assumptions behind them.
How we build
- We deploy the chosen billing platform in your cloud account, data center or air-gapped network, as agreed in the scope.
- We configure integrations, such as payment gateways and general ledger exports, and test them against agreed invoice and payment scenarios.
- We document hosting sizing, component inventory and the upgrade path so the cost model can be checked against the running system.
How we hand over
- Handover includes architecture documentation, runbooks, configuration records and the operating cost inventory agreed in scope.
- We document which items are one-time (implementation, migration) and which recur (hosting, plugins, support, upgrades, staff time).
- You receive a list of open decisions, such as enterprise support or additional plugins, with the information needed to request a quote.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, and their scope is written separately from the build.
- Retainer scope can cover platform upgrades, backups and security testing, so the recurring cost line is defined before you commit.
- Ask any partner, including DeployOpen, to confirm in writing which costs a retainer includes and which remain with your team.
