Lago vs Kill Bill

Lago suits teams whose revenue depends on metered usage and who want a PostgreSQL and Docker-based stack. Kill Bill suits teams that need a subscription engine on Java, Tomcat and plugins. The right choice depends on pricing model, team skills and how much support you need to buy.

On this page

When to choose Lago or Kill Bill for usage-based billing

A billing team that must charge for metered usage and asks which open-source engine to self-host should start with the shape of its price list, not with the software. If most revenue comes from counting events such as API calls, tokens, seats-hours or storage, and invoices are built from those counts, Lago fits the metering-led model most directly. Lago meters usage, applies pricing, produces invoices and hands the charge to a separate payment gateway such as Stripe, Adyen or GoCardless. Its self-hosted footprint is a set of services the team already knows how to run: a front end, an API, an API worker, a clock worker, PostgreSQL for application data, Redis as the job queue and Gotenberg for PDF generation. ClickHouse is optional and disabled by default. The AGPL-3.0 license of the platform is acceptable only if the company is comfortable with its obligations when it modifies and offers the software over a network, so legal review belongs in the first week.

Kill Bill fits subscription-led catalogs where recurring plans, upgrades, downgrades, invoices and credits are the core and usage is an add-on. It is a standalone Java server packaged as a WAR file, typically run in Tomcat, and the installation guide requires JDK 11, so the team needs Java and Tomcat operations skills and a plan for the database, since the core team tests against MySQL, MariaDB 10 and PostgreSQL 12. Kill Bill is licensed under Apache-2.0, which many procurement teams prefer, and gateway, tax and fraud integrations arrive as plugins deployed as JARs in the same environment. Confirm with the Kill Bill project which plugins your gateway needs and whether they are maintained for your versions. Kill Bill ships with no support or SLA, so a team that needs contractual response times must buy them elsewhere.

Five decision drivers settle most cases: the pricing model (metered versus subscription-led), the payment gateway and whether a supported plugin exists for it, the licensing posture (AGPL-3.0 versus Apache-2.0), the support requirement, and the in-house skills to run Python-era Rails-free Lago services or Java and Tomcat. Write each driver down with an owner before comparing features, because a team that cannot staff Java operations or accept an AGPL obligation has its answer before any demo. Ask both projects and any implementation partner for a written scope that names the gateways, databases and upgrade plan you intend to use.

Which billing platform fits which business model

This table maps common business models to the platform that usually fits better and the condition that decides it. Read each row against your own pricing, team skills and support requirements, since a fit depends on the conditions in the reason column.

Business modelBetter fitReason and the condition that matters
API or AI product billed per unitLagoLago is built around metering usage events, applying pricing and producing invoices. This matters most when usage volume and per-unit pricing change often and you want metering to be the core of the system. Confirm that your event volume fits the default PostgreSQL store or plan for the optional ClickHouse store.
SaaS with tiered plans and add-onsEither, depending on the subscription modelKill Bill is designed around subscriptions, upgrades, downgrades, invoices and credits, so it suits complex subscription lifecycles. Lago also handles plans and usage, so choose Kill Bill if subscription state changes are the hard part and Lago if metered charges dominate.
Enterprise with existing Java operationsKill BillKill Bill is a Java server deployed as a WAR file, typically in Tomcat, with plugins as JARs. Teams that already run JDK-based services and Tomcat can reuse that skill set. Confirm your JDK version against the Tomcat installation guide before you commit.
Team that wants a PostgreSQL and Docker-first stackLagoLago's Docker Compose deployment runs PostgreSQL, Redis and a set of workers, and its self-hosting guide recommends pinning tagged versions. This suits teams comfortable operating those services. Confirm the operating effort for your own environment before committing.
Team needing paid vendor support or an SLANeither as open source alone; confirm vendor termsKill Bill ships under Apache-2.0 with no support or SLA included. Lago's open-source edition is free, and its Enterprise plans add premium features. Ask each vendor what support, SLA and upgrade assistance is contractually available before you choose.
Team that wants to keep billing logic in Kill Bill but needs an outside partner for implementationKill Bill with a fixed-scope implementationDeployOpen can plan, implement, integrate, harden and document a self-hosted Kill Bill deployment in your infrastructure under a written scope. Ask for the scope, deliverables and timeline in writing before work begins.
Team needing a lower-effort start with a payments gateway already in placeLagoLago calculates charges and invoices, then sends payment to a separate gateway such as Stripe, Adyen or GoCardless. Kill Bill also connects to gateways through plugins. Confirm which gateway plugins or integrations your provider supports before you choose.

How Lago and Kill Bill are built and what that means for operations

Both platforms are self-hosted billing systems, but they are assembled very differently. Lago is a set of cooperating services with a fixed PostgreSQL, Redis and PDF component set, while Kill Bill is a single Java server in a servlet container with plugins loaded beside it. The cards below cover what each layout means for patching, scaling and on-call work.

Lago's service set

The Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL for application data, Redis as the job queue and Gotenberg for PDF generation. Each service is a separate moving part that your team must monitor, restart and upgrade together. Check that your on-call runbook covers a stalled worker as well as a failed API, because billing runs depend on both. Confirm which services your chosen deployment method runs in separate containers or pods.

Optional ClickHouse for event volume

ClickHouse is an optional external store for high-volume events and is disabled by default. Enabling it adds a second data system to back up, monitor and upgrade, which changes the on-call surface more than any single feature. Decide early whether your event volume justifies it, and ask Lago's team or your own load tests to confirm where the default PostgreSQL store stops being adequate for your workload.

Kill Bill's WAR in Tomcat

Kill Bill ships as a standalone Java server packaged as a WAR file and is typically run in Tomcat. Patching usually means replacing the WAR and restarting the container, so your team owns the servlet container, JVM and application lifecycle. Confirm the JDK version required by the Tomcat installation guide before you plan a host image, since the guide specifies JDK 11.

Plugin JARs and payment integrations

Payment gateways, tax and fraud providers connect to Kill Bill through plugins deployed as JARs in the same environment as the server. Each plugin version has to match the core release you run, so a core upgrade can force coordinated plugin upgrades and retests. In Lago, payment collection sits with a separate processor such as Stripe, Adyen or GoCardless, so the integration burden is different. Ask which plugins your gateways need and who maintains them.

Database choice for each platform

Lago depends on PostgreSQL for application data, so PostgreSQL backup, failover and tuning are central to its operations. Kill Bill's core team uses MySQL and runs regression tests against MariaDB 10 and PostgreSQL 12, and users have also deployed it with Oracle, Percona and Aurora. Your DBA standards and existing database skills will decide which path carries less risk. Confirm the supported database versions for the release you plan to run.

Pinning versions and upgrade cadence

Lago's self-hosting docs recommend pinning the last tagged version rather than the latest image tag, so upgrades become deliberate changes you schedule and test. Lago's own release history moves quickly, with v1.54.0 and v1.55.0 published a day apart in October 2026, so budget time to review each tagged release. Kill Bill's 0.24.x line receives updates through its release page, and both platforms need a staging environment that mirrors production billing runs.

Pricing models, gateways, stack and licensing side by side

This table sets Lago and Kill Bill against the same billing needs: metering, subscriptions, gateways, stack and license. Read each row as a checklist for your own requirements, and use the confirm column to see which details still need a vendor answer before you decide.

CapabilityLagoKill Bill
Core focusUsage metering, pricing, invoicing and payment collection as monetization infrastructureSubscription billing and payments platform with recurring and usage-based subscriptions
Subscriptions, upgrades and downgradesCovered by the platform's billing features; confirm plan change and proration behavior for your plansHandles upgrades and downgrades, invoices and credits as core functions
Payment gateways named in supplied sourcesStripe, Adyen and GoCardless; a separate payment processor is requiredStripe, Braintree and PayPal; gateways connect through plugins deployed as JARs
Integrations named in supplied sourcesNetSuite, Xero, Salesforce and HubSpotTax and fraud providers through plugins; confirm which ERP and CRM connectors exist
Back-office UIConfirm the admin interface and role model in the current releaseKaui, with role-based access for support, product configuration, finance reporting and testing
Database supportPostgreSQL for application data; Redis as job queue; ClickHouse optional for high-volume eventsMySQL used by the core team; regression tested on MariaDB 10 and PostgreSQL 12; Oracle, Percona and Aurora reported by users
RuntimeDocker Compose with front end, API, API worker, clock worker, Gotenberg for PDFs; Helm charts for larger deploymentsStandalone Java WAR typically run in Tomcat, with JDK 11 in the Tomcat installation guide
LicenseAGPLv3 for the platform; agent SDKs and MCP server are MIT in separate repositoriesApache License 2.0, with no support or SLA included in the project

What AGPL-3.0 and Apache-2.0 mean for your organization

Counsel and procurement usually start with the license files and the commercial paper. Lago's core platform is licensed under AGPLv3, while Kill Bill is licensed under the Apache License 2.0. Both allow commercial use, but they differ in what they require when code is changed and when software is made available to users over a network. Procurement should also keep the free software and any paid agreement separate, because support and service commitments come from a contract, not from the license itself. Lago's agent SDKs and MCP server are MIT licensed in separate repositories, so they can be reviewed on their own terms.

  • Copyleft scope: AGPLv3 can require source availability for modified versions that users interact with over a network. Apache-2.0 is permissive and does not carry that obligation for your own changes in the same way.
  • Separate SDK licenses: The MIT terms for Lago's SDKs and MCP server apply to those repositories, so include them in your inventory.
  • No support or SLA with Kill Bill: Kill Bill's license comes with no support or SLA, so any service commitment must be written into a separate agreement.
  • Edition boundaries: Lago's general FAQ describes a free open-source edition with fundamental billing features and Enterprise plans with premium features. Ask for the Enterprise terms in writing.

Ask counsel to review the exact license files in the repositories and versions you plan to deploy, along with any Enterprise order form.

What drives the running cost of each billing engine

Running either engine costs more than its license line, which is zero for both. The cost sits in the services you operate, the people who keep them upgraded, and the integrations and editions you add. The cards below separate one-time setup work from recurring operating cost so you can ask every vendor and partner for the same breakdown.

Infrastructure you operate

Lago's Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg, with ClickHouse optional and disabled by default. Kill Bill runs as a WAR in Tomcat backed by a database, with plugins deployed alongside it. Both bill recurring infrastructure cost. Ask for the sizing assumptions behind each service and whether ClickHouse or a larger database tier is included in the quote.

Engineering skills to keep it running

Lago's operating skills center on Docker and PostgreSQL, with Ruby knowledge needed for deeper troubleshooting. Kill Bill requires Java, Tomcat and JDK 11 for the Tomcat install path, plus a database team familiar with MySQL or MariaDB. Staffing is the largest recurring line for most in-house teams. Ask the partner which skills the quote assumes and whether knowledge transfer is a one-time deliverable or ongoing.

Upgrades and version pinning

Lago's docs recommend pinning the last tagged version rather than the latest image tag, so every upgrade becomes a planned change with testing. Kill Bill's core, Kaui and plugins each need compatible versions. Upgrade testing against your own invoices and payment flows recurs with every release. Ask whether the quote includes upgrade testing, rollback planning and regression runs against your plugins.

Support and service levels

Kill Bill ships under Apache-2.0 with no support or SLA included, so any production support must come from a commercial agreement with a vendor or partner. Lago offers Enterprise plans for premium features, and its support terms are set by that contract. Compare response commitments in writing rather than assuming they match. Ask whether support is a fixed monthly retainer, billed by incident, or bundled with upgrades.

Paid Enterprise features

Lago's free edition covers fundamental billing, while Enterprise plans add premium features. Those features are a recurring license cost that sits on top of infrastructure and staffing. Kill Bill's plugins are open source, but payment gateway, tax and fraud connectors can still require build or license work. Ask which features you need, whether they are in the Enterprise contract, and how renewal pricing is set.

Integration work and the one-time build

Lago's README lists NetSuite, Xero, Salesforce and HubSpot integrations, and a payment processor such as Stripe, Adyen or GoCardless must be connected separately. Kill Bill connects gateways through plugins that you configure and test. Most of the one-time spend goes into mapping your product catalog, tax rules and ledger exports. Ask for a fixed-scope deliverable list covering each integration and the test evidence delivered at the end.

Moving billing from Kill Bill to Lago or the reverse

This sequence moves a live billing book between the two platforms without a gap in invoicing, so each customer is billed exactly once and every open balance is accounted for. The result is a documented cutover with reconciled invoices, working payment collection and a clear rollback point.

  1. Inventory the current billing configuration

    Export the Kill Bill catalog (products, plans, phases, prices and usage-based units) and the Lago or Kill Bill configuration you will target, including billable metrics, plans and charge models. The owner is your billing engineer with finance sign-off on the pricing rules. Done means every active plan has a written mapping to a target object, and any plan that has no equivalent is flagged for a decision before data moves.

  2. Export customers and active subscriptions

    Extract accounts, billing addresses, tax identifiers, subscription start and end dates, billing cycle anchors, add-ons and any pending plan changes from Kill Bill through its REST APIs. Store the extract in a staging database with a checksum. Done means a row count per entity matches the source, and a sample of accounts has been compared field by field against the Kill Bill admin view in Kaui.

  3. Map plans to Lago metrics or Kill Bill products

    Translate each Kill Bill recurring plan into a Lago plan with fixed and usage charges, and translate each usage-based Kill Bill unit into a Lago billable metric with the same aggregation logic. Where the two engines model proration, trials or credits differently, record the difference as a decision. Done means a signed mapping document exists, and test invoices for representative accounts match expected amounts in staging.

  4. Migrate open invoices, credits and balances

    Load unpaid invoices, account credits and prepaid balances into the target system as opening balances, with original invoice numbers kept as external references so customers and auditors can trace them. Finance reconciles totals by account and by currency. Done means the sum of opening balances in the target equals the sum of open items in the source, with any gap explained line by line.

  5. Move gateway tokens and reconfigure webhooks

    Kill Bill and Lago both delegate card collection to an outside payment processor, and Lago names Stripe, Adyen and GoCardless as supported providers. Vaulted payment methods usually cannot be copied between accounts, so the gateway must cooperate through token migration or a controlled re-consent flow. Reconfigure webhooks to point at the new system and confirm signatures. Done means a test payment succeeds through each gateway and payment status events land in the new system.

  6. Run parallel invoicing and reconcile outputs

    Run both systems for one full billing cycle on the same usage data, with only one of them allowed to charge customers. Compare generated invoices, tax lines, usage totals and payment outcomes for every account. Done means differences are either zero or documented with a cause, and finance has signed off the variance report before cutover is scheduled.

  7. Cut over and keep a rollback path

    Freeze Kill Bill subscription changes, take a final usage and subscription snapshot, switch the billing scheduler and gateway webhooks to the new platform, and confirm the first live run. Keep the Kill Bill environment read-only for the agreed retention period, which your compliance team should confirm. Done means the first live invoice run completes, reconciliation passes on day one, and the rollback decision owner has written criteria.

  8. Document what was rebuilt and what transferred

    Record which elements moved as data, which were rebuilt as configuration or code (such as custom Kill Bill plugins, which have no direct Lago equivalent and need separate integration work), and which required gateway or accounting-system action. Done means a handover document lists each item with its owner, and the rebuilt integrations have passed the same test cases as the originals.

Where billing implementations usually run long

Plan the deployment effort around configuration, not installation. Lago's self-hosted path is a Docker Compose stack that runs a front end, an API, an API worker, a clock worker, PostgreSQL, Redis and Gotenberg, with ClickHouse disabled by default. Standing that stack up is usually the quick part. The longer work is sizing the workers for your event volume, pinning the last tagged release as the self-hosting docs recommend instead of the latest image tag, and wiring the payment gateway so that Lago's calculated charges reach Stripe, Adyen or GoCardless. Larger deployments move to the Helm charts and dedicated workers the docs describe, which adds a Kubernetes skill requirement. Confirm with your platform team who owns upgrades between tagged versions, since Lago releases move quickly.

Kill Bill's effort sits in a different place. The server is a WAR file typically run in Tomcat, the installation guide requires JDK 11, and each payment, tax or fraud integration is a plugin JAR that has to be deployed into the same environment and configured. Much of the early work is the catalog: products, plans, price lists and phases must be modeled in configuration before invoices can be trusted, and Kaui, the back-office UI, needs its roles set up for support, product configuration and finance reporting. Kill Bill's getting started guide notes that the core team tests against MySQL, MariaDB 10 and PostgreSQL 12, so confirm that your chosen database is in use by other adopters before committing to it.

Across both platforms, the delays that most often push timelines out are the same: tax rules, gateway webhooks, invoice templates and data mapping from the source system. Tax logic depends on which jurisdictions and tax providers you must support, and neither platform removes that analysis. Webhook handling from the gateway must be tested for retries, duplicates and out-of-order delivery before any live charge runs. Invoice templates need legal and finance sign-off, and customer, product and usage identifiers must map cleanly from your CRM, ERP or metering data. Ask any implementation partner to write these four items into the fixed scope, with named owners and acceptance tests, so that they are not discovered during cutover.

Questions buyers ask before hiring help with billing

What drives the cost of running Lago or Kill Bill?

Cost is driven by the people and services around the software, not the license fee, since both projects are free to download. Lago is licensed under AGPLv3 and Kill Bill under Apache License 2.0, so neither charges a license fee for the core. The recurring costs are the infrastructure you run, the engineers who maintain it, and any paid payment gateway or support contract you choose. For Lago, the stack is a front end, an API, workers, PostgreSQL, Redis and Gotenberg, plus optional ClickHouse for high event volumes. For Kill Bill, the stack is a Java WAR in Tomcat, a supported database such as MySQL, plugins and the Kaui back office. Ask any quote to separate one-time setup from recurring operations, and to name who pays for each piece.

Can an internal team run Lago or Kill Bill without a partner?

Yes, if your team has the skills to operate the components and the time to keep them patched. Both are open source, so you can deploy them yourself without buying a license. Lago's self-hosting docs recommend pinning the last tagged version rather than the latest image tag, and point larger deployments to Helm charts and dedicated workers, which means someone must own upgrades and capacity. Kill Bill's getting started guide requires JDK 11 for the Tomcat installation, and its core team tests against MySQL, MariaDB 10 and PostgreSQL 12, so your database and Java operations need an owner. Be realistic about the gap: Kill Bill includes no support or SLA by default, so an internal team carries the full burden of incident response. Decide who holds that responsibility before you choose.

What does the work need from engineering and finance?

Engineering owns the deployment, integrations and data flow, while finance owns the rules that determine what is charged. On the engineering side, expect work on the payment gateway connection, since Lago needs a separate processor such as Stripe, Adyen or GoCardless, and Kill Bill connects to gateways such as Stripe, Braintree and PayPal through plugins. Expect integration work for accounting and CRM systems, which Lago lists as NetSuite, Xero, Salesforce and HubSpot. On the finance side, pricing models, tax treatment, invoice formats, credit rules and dunning policy need written decisions before build starts. Kill Bill's Kaui back office gives internal teams role-based access for support, product configuration and finance reporting, which can shift some of that work to finance staff. Ask any partner to name these responsibilities in the written scope.

How long should we plan for a billing implementation?

Plan in phases tied to decisions, not to a fixed number of weeks. The duration depends on how many products and pricing models you need, how many gateways and accounting systems must connect, how much historical data must migrate, and how many approvals sit inside finance and tax. Lago's model of metering events, applying pricing and producing invoices means usage data quality often sets the pace, so validate event pipelines early. Kill Bill's subscription model, with upgrades, downgrades, invoices and credits, often takes longer to define in the product catalog than to deploy. No researched figure is available for either project, so ask each vendor or partner for a phased plan with milestones and the assumptions behind each one, and check that the timeline lists its dependencies on your own environment.

What support does Kill Bill lack by default?

Kill Bill ships without support or an SLA, so vendor-backed response times, guaranteed fixes and contractual uptime are not part of the default package. The project is open source under Apache License 2.0 and has been in production since 2010, but the README states that no support or SLA is included. The Billing Project, LLC owns the codebase and trademarks, which is useful for licensing clarity but does not replace an operational support contract. Plugins for gateways, tax and fraud are also deployed as JARs in your environment, so compatibility after upgrades becomes your responsibility unless a contract covers it. Ask any provider what they will monitor, how they handle incidents, and which parts of the plugin estate they will maintain.

When is a managed or paid option worth comparing?

A managed or paid option is worth comparing when your team cannot staff the operational load or when a feature you need sits behind a paid tier. Lago offers a forever-free open-source edition with fundamental billing features, and Enterprise plans that add premium features, so check whether dunning, tax or accounting integrations you need are in the free scope. Lago also documents Lago Cloud as a managed option, which removes the need to run workers, PostgreSQL and Redis yourself. For Kill Bill, a paid support or hosting arrangement from a provider would fill the support gap described above. Compare the managed cost against the internal hours, on-call duties and upgrade risk it removes, using the same written scope for each option.

Which license terms should legal review before we pick one?

Legal should review how each license applies to your deployment and to any changes you make. Lago's platform is licensed under AGPLv3, which carries source disclosure obligations for network-accessed modifications, while its agent SDKs and MCP server are MIT licensed in separate repositories. Kill Bill is licensed under Apache License 2.0, which is permissive and does not carry the same network disclosure duty. Confirm with counsel how the AGPL-3.0 terms interact with your planned customizations and internal-only use. Do not treat this summary as legal advice; confirm the terms with your legal team before you build on either platform.

How do we check the scope of a fixed-scope billing engagement?

Check that the written scope lists systems, deliverables, acceptance criteria and exclusions before any work starts. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for the gateway and accounting integrations named one by one, the data migration approach, the test and cutover plan, and who owns runbooks after handover. Ongoing support, upgrades and testing are available as retainers, which should be priced separately from the build.

How to test both platforms against your own billing data

Run a short bake-off before you commit, using your own billing data rather than vendor demos. Load a representative product catalog into both Lago and Kill Bill: include your real billable metrics, plans with usage-based and flat-fee charges, and at least one add-on. On the Lago side, check how billable metrics and charges map to your pricing. On the Kill Bill side, check how catalog XML or API-defined plans, phases and price lists map to the same offers. Record every place where you had to reshape a model to fit the tool, because those gaps tend to become custom code later.

Next, replay a sample of usage events drawn from production, including late-arriving and duplicate events, and compare the invoice totals each platform produces against your current figures. Lago ingests usage through its events API, so confirm how it handles idempotency and event timestamps. Kill Bill has no native metering engine in the same sense, so usage is typically aggregated upstream and pushed in as usage records, which changes where your reconciliation logic lives. Then test one gateway webhook end to end: configure a sandbox account with the processor you actually use, trigger a failed payment, and verify that the event reaches the platform, updates the invoice state and retries correctly. Confirm which gateway integrations each product supports for your region and processor, because Lago names Stripe, Adyen and GoCardless in its documentation, while Kill Bill's documentation names Stripe, Braintree and PayPal.

Finally, test one mid-cycle plan change that triggers proration, such as an upgrade on the 15th of a billing period with a credit for unused time, and check the resulting invoice line items, credits and tax treatment against your accounting rules. Then record what each stack needs to operate: the services to run (Lago's Docker Compose deployment includes PostgreSQL, Redis and Gotenberg, plus optional ClickHouse; Kill Bill runs as a WAR in Tomcat with a MySQL, MariaDB or PostgreSQL database and JDK 11 per its getting started guide), who on your team can restart, upgrade and debug each one, and how long a version upgrade took in a staging copy. Results depend on your data volumes, processors, tax jurisdictions and infrastructure, so treat this as a method to run in your own environment, not as a benchmark.

How DeployOpen helps choose, implement or migrate billing

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For billing, that means working out which engine fits your pricing model and payment setup, then building it in your environment with the evidence your finance and compliance teams need.

How we scope

  • Confirm which pricing models you need: usage metering, recurring plans, or both, before choosing an engine.
  • Map your payment gateways, tax, accounting and CRM systems to the integrations each platform actually supports.
  • Agree deliverables, timelines and responsibilities in writing before any work starts, as engagements are fixed-scope.

How we build

  • Deploy the chosen platform in your infrastructure, pinning a tagged release and documenting the services that run.
  • Connect the payment gateway and downstream systems, then test invoices, credits and plan changes against your own rules.
  • Harden access, secrets and backups, and set up the logs and tests your security and finance reviewers will ask for.

How we hand over

  • Deliver architecture notes, runbooks, upgrade steps and configuration documentation your own team can operate.
  • Walk your engineers and finance operators through the back-office tools and the billing lifecycle end to end.
  • Provide the evidence and control documentation your compliance team needs, without issuing any audit report or certification.

How we support

  • Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
  • Plan version upgrades and test them in staging before they reach production billing runs.
  • Ask for a quote based on the written scope, so cost follows from the agreed work rather than a published price list.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.