Apache Fineract cost of ownership and support

Apache Fineract cost of ownership: what the zero license fee leaves out

Apache Fineract carries no license fee. It is licensed under the Apache License 2.0 (Apache-2.0), so the money you would spend on a licensed core banking contract moves elsewhere rather than disappearing. Over several years, the recurring cost sits in infrastructure, a front end, integration work, people who run and change the platform, and any vendor support you choose to buy. Those are the lines to model against a licensed quote, not the software itself. The question usually arrives from one of three triggers: a licensed core banking contract approaching renewal, a build-versus-buy review that has to compare a self-hosted option on equal terms, or a new product line that the existing system cannot configure without expensive change requests. Each trigger shifts the cost picture. A renewal review needs a multi-year view that includes migration effort. A build-versus-buy review needs the staffing and support assumptions written down so they can be challenged. A new product line needs to know how much configuration work sits inside the platform and how much sits in custom code. The Fineract project itself is direct about this. Its README warns that a production deployment can be complex, costly and time-consuming, notes that the project does not provide a comprehensive production deployment guide, and says organizations may pay a vendor for deployment and maintenance. Treat that as a planning input. Most teams model the first deployment with an implementation partner, then keep routine operations in-house once their own staff understand the database, the batch jobs and the release cycle. Whether your team can take on that ongoing work is something to confirm against your own skills, not assume. The cost components are easier to compare when you list who is paid for each. Infrastructure is paid to your cloud provider or data center team and recurs monthly. The front end is a separate build or adoption decision, because Fineract is headless and exposes REST APIs without its own user interface. Integrations to payments, general ledger, reporting and customer systems are mostly one-time build work with recurring maintenance. Internal staff time for administration, upgrades, testing and incident response recurs for as long as the platform runs. When you request a quote for the first deployment, ask for each of these lines to be priced separately, along with which items are one-time and which recur, what is excluded, and which tasks the partner expects your team to own after go-live. A fixed-scope quote should name the deliverables and the assumptions behind them. DeployOpen does not publish prices, so the figures you compare will come from written scopes, which is why a like-for-like breakdown matters more than any headline comparison.

What a Fineract cost of ownership model includes

A Fineract cost of ownership model turns the client's written scope into a multi-year view of what the platform costs to run, beyond the zero license fee. Each card below is one cost area or deliverable that the model needs to capture before it can be compared with a licensed core banking quote.

Hosting and environments

The model prices every environment the client will run, not only production: development, test, performance, and disaster recovery. Each one carries compute, PostgreSQL, storage, backup, and network costs in the client's own cloud account, data center, or air-gapped network. Confirm how many environments are required, their sizing assumptions, and who pays for the platform licences and cloud services that sit beneath Fineract.

Separate front end build and run

Fineract is headless and exposes REST APIs without its own user interface, so the model must include a front end for staff and, where needed, customers. The README points to the Mifos X web application as a front end used in its Kubernetes example. Ask whether the front end is adopted, customized, or built new, and who owns its hosting, security patching, and release cycle.

Integration and event work

Payments, general ledger, KYC, card, reporting, and CRM systems usually connect to the core, and each connection has a build and a maintenance cost. External business events can be published to ActiveMQ, other JMS brokers, or Apache Kafka, but this is disabled by default and needs deliberate design. Ask for each interface listed in the scope, its owner, and how its changes are tested after each platform upgrade.

Operations and release upkeep

Fineract publishes official releases quarterly, and upgrades involve Liquibase migrations that run on write instances, followed by regression testing of products and accounting. The model should count the staff time for monitoring, the Close of Business batch job, patching, and quarterly upgrade cycles across the planned years. Ask who performs each activity, how often it recurs, and what evidence each upgrade produces.

Cost register and assumptions log

The cost register lists each cost line with its owner, payment type, one-time or recurring nature, and the year it applies. The assumptions log records every input behind the figures, such as environment count, transaction volume, user numbers, and staffing levels, together with who approved it. Together they let the client test how the total changes when a single assumption moves.

Comparison sheet for licensed vendors

The comparison sheet sets the Fineract model beside a licensed core banking vendor quote on the same years, scope, and cost categories, so the client can see where the totals differ and why. Licence fees, implementation, hosting, support, and upgrade costs are compared line by line. Confirm that the vendor quote covers the same functions and that the sheet states its assumptions, not only its totals.

What pushes Fineract running costs up or down

This table compares the drivers that change what an Apache Fineract deployment costs to run over several years. Read each row as a design question to settle before build, because tenant count, batch runtime and customization depth set most of the recurring work. The main takeaway is that the license is free under Apache-2.0, so decisions about tenants, batch capacity, environments and upgrades determine the budget.

Driver	Why it moves cost	How to keep it down
Tenant count	Each institution or brand adds tenant configuration, data separation and per-tenant upgrade and testing effort on one platform.	Consolidate only where products and regulators align. Confirm operating limits for tenant count before sizing.
Transaction volume and account count	Close of Business can run for several hours at millions of accounts, so batch capacity and support hours grow with the book.	Size batch capacity early. Use remote partitioning across workers coordinated through ActiveMQ or Kafka when runtimes outgrow one node.
Read, write and batch instances	Each instance type adds compute, configuration and monitoring. High load pushes toward multiple read instances on database replicas.	Start with the smallest topology your load tests support. Add read instances on replicas before adding write capacity.
PostgreSQL high availability	Replication, backups, failover testing and database administration time are recurring costs that rise with the uptime target.	Agree recovery targets with the business first. PostgreSQL is the recommended database, so standardize on it.
Integrations and business events	Each consumer of events such as ClientCreated needs build, monitoring and replay handling. Event publishing is disabled by default.	Publish only the events downstream systems need. Design consumers to handle duplicates safely and monitor their backlog.
Customization depth	Code kept inside core Fineract makes every quarterly upgrade a larger regression exercise.	Keep local products, reports and APIs in separate modules. Limit core changes to what regulation requires.
Number of environments	Each non-production environment needs its own database, tenants, data refresh and test runs. Copies of production data add security effort.	Keep a small set of environments with scripted builds. Mask or synthesize data in lower environments.
Compliance evidence demands	Access reviews, change records, audit trails and retained test results add recurring effort. DeployOpen prepares evidence; auditors issue opinions.	Define which controls apply before build. Automate evidence capture in the delivery pipeline and deployment logs.
Release cadence	Official releases arrive quarterly, so each adopted release triggers regression testing of products and accounting.	Choose a cadence your testing capacity supports. Track end-of-life dates and plan upgrades before a release is archived.

Which Fineract edition or release line to budget for

Budget for the 1.x release line and for a support model, not for an edition. Apache Fineract is distributed as one open-source project under the Apache License 2.0 (SPDX: Apache-2.0), and the supplied project facts do not describe commercial edition tiers. That means the licence line in your cost model is zero, and the decisions that move money are which release you run, how often you upgrade, and who answers when something breaks. Those choices should be made before the platform is priced, because they determine the upgrade workload that recurs for the life of the system.

The Fineract website lists 1.15.0 as the current stable release, and the Fineract 1.15.0 documentation was built on July 10, 2026. Confirm the current stable version on the project website on the day you request quotes, because the figure will change. The README states that official releases are created quarterly, at the end of each quarter, following the Apache Software Foundation release policy, and that end-of-life releases are archived. An archived release gets no further fixes, so a deployment that stays on it accumulates risk and eventually has to be moved in one large step.

Fineract CN, the microservices rewrite, was deprecated in May 2023 and archived in late 2023 without an official release. Any budget, vendor proposal or internal architecture document that refers to Fineract CN as a current option is out of date. The 1.x line is the maintained platform. Ask every bidder to name the Fineract version they will deliver and confirm that it sits on the 1.x line, because a proposal built on the archived codebase would carry a rebuild cost that is not visible in the licence fee.

Ask each vendor whether they sell subscriptions, support tiers, a managed hosting edition or a retainer, and what each one includes. Some firms package deployment, patching and incident response differently, and the Fineract README notes that organizations may pay a vendor for deployment and maintenance. Request the written scope for each option, including response expectations, the versions covered, how upgrades to new quarterly releases are priced, and who performs regression testing of loan and accounting products after a Liquibase migration. Treat any unpublished tier or SLA as something to confirm in writing, not something to assume.

Budget against the release cadence you will actually follow, not the one the project publishes. If your change board approves upgrades once a year, plan for one or two quarterly releases to be skipped each cycle and for the upgrade to carry several releases of database migrations and regression testing. If you plan to track every quarterly release, the recurring effort is smaller per cycle but continuous. Model both options for five years, record the number of upgrade cycles and the test scope for each, and ask vendors to price the same cadence so the comparison is like for like.

Recurring costs after go-live on a self-hosted Fineract platform

This table lists each recurring cost line after a self-hosted Apache Fineract platform goes live, who usually pays for it, what drives it, and what to request in a quote. Fineract carries no license fee, so the recurring spend sits in infrastructure, people, integration operation, testing, security and any vendor contracts. Use the table to build a multi-year cost model, and note that no figures are estimated here.

Cost line	Who pays and one-time or recurring	What drives it	What to request in a quote
Hosting for read, write and batch instances	Client, through its cloud account or data center. Recurring.	Number of instances, the read instance count for load, and the environment count (production, test, training).	Itemized instance sizing per environment, the hosting assumptions used, and how scaling is priced.
PostgreSQL database and read replicas	Client for infrastructure, partner for administration if contracted. Recurring.	Database size, account volume, replica count, backup retention and the tenants database for multi-tenant setups.	Database sizing basis, replica layout, patching responsibility and the expected growth assumption.
Backup and disaster recovery storage	Client for storage, partner for runbook and restore testing if in scope. Recurring, with a one-time setup for recovery design.	Data volume, retention period, backup frequency, and how often restores are tested.	Retention schedule, restore test frequency, recovery objectives the design targets, and storage cost basis.
Front end (Mifos X or a custom front end)	Client for hosting and licenses where they apply, partner for changes. Recurring for hosting and maintenance, one-time for build.	Fineract is headless with REST APIs and no built-in user interface, so the README's Kubernetes example points to Mifos X as the front end. Customization and staff workflows drive effort.	Confirmation of the front end choice, hosting needs, and whether ongoing UI changes are priced separately from core support.
ActiveMQ or Kafka operation	Client for the broker infrastructure, partner for setup and consumer work. Recurring for operation, one-time for design.	Whether external events and remote partitioning for Close of Business are enabled, the broker type, and the number of consumers.	Broker topology, who monitors and patches it, and the consumer support model.
Quarterly upgrades and regression testing	Client or partner, usually as a retainer or per-release work. Recurring.	Fineract publishes official releases quarterly, Liquibase migrations run on write instances, and product and accounting rules need regression coverage each time.	Upgrade frequency assumed, regression scope covering products and accounting, and how a skipped or delayed release is handled.
Security testing and patching	Client for tooling, partner for testing and hardening work. Recurring.	Dependency and base image updates, the HTTPS and authentication configuration, and how often tests run against the platform.	Test cadence, scope of applications, APIs and infrastructure covered, and how findings are retested.
Internal platform staff	Client. Recurring.	Number of people who run databases, Kubernetes, brokers, releases and incident response, plus business owners for products and accounting.	A staffing model the vendor expects, and which roles the vendor assumes if it runs part of the service.
Vendor support or maintenance contract	Client, to the vendor. Recurring if contracted, with an optional one-time onboarding fee.	Support hours, response expectations, the systems covered, and whether upgrades and incident handling are included.	A written list of covered services, exclusions, escalation path, and what happens when the Fineract version is out of date.

Where Fineract cost estimates usually go wrong

Most Fineract estimates that look low at the start fail in the same few places: the license is mistaken for the whole cost, and operating work is left out or pushed to later years. The cards below cover each common miss, the step that prevents it, and the question to put to a partner or internal team before a number is accepted.

Treating the license as the whole cost

Apache Fineract is licensed under Apache-2.0, so there is no license fee to compare against a licensed core. The recurring costs sit in hosting, database operations, the front end, integration, staff and vendor support across several years. Prevention means building a multi-year model with each of those lines. Ask the scoping partner to list every component that carries a monthly or annual cost.

Omitting the front end lifecycle

Fineract is headless, provides REST APIs, and does not ship its own user interface. The README points to Mifos X as a front end in its Kubernetes example, so staff screens, customer channels and their security reviews must be costed separately. Each front end has its own release cycle, dependencies and testing needs. Ask who owns the front end after go-live and how its upgrades are budgeted.

Underestimating Close of Business run time

The Close of Business Day Spring Batch job can run for several hours on deployments with millions of accounts, and run time grows with account counts. Remote partitioning across worker nodes, coordinated through ActiveMQ or Kafka, adds infrastructure and operations work. Prevention is to model the job against projected account volumes in each year of the estimate. Ask for the expected nightly window at the first and third year account counts.

Skipping read replicas and batch separation

The Fineract documentation describes read, write and batch instance types, and recommends one write instance, one batch instance and multiple read instances on database read replicas for high load. Teams that defer this often pay for emergency re-architecture once users see slow screens or batch jobs collide with daytime load. Prevention is to include the instance layout and replica capacity in the first estimate. Ask whether the quote covers these instances from day one.

Leaving the default development login

The Fineract README shows a default development login, mifos with its matching password, and states it must be changed for any real deployment. Leaving it in place is a control failure that auditors and regulators will flag, and fixing it late means reworking access for every integration and operator. Prevention is to include credential replacement, HTTPS only and identity integration in the hardening scope. Ask the partner to confirm the default credentials are removed and documented in the handover.

Paying for an upgrade path never planned

Official Fineract releases are created quarterly, and older releases are archived when they reach end of life, so an install that is not kept current drifts quickly. Upgrades involve Liquibase migrations that run only on write instances, plus regression testing of products and accounting. Teams that skip this planning pay a large catch-up project later. Ask for the upgrade cadence, the regression test suite, and who funds each upgrade in the support agreement.

Building custom code into the core

Local products, reports and integrations are often written directly into Fineract core code, which makes every later upgrade a merge exercise. Extensions kept outside the core, such as custom modules, API extensions and separate front-end work, keep upgrades cheaper. Prevention is to set the extension boundary in the design phase and review changes against it. Ask the partner how custom code is isolated and how much of the custom work is expected to survive a quarterly upgrade.

How a cost of ownership model is built, step by step

The sequence turns a Fineract scope into a multi-year cost model that finance and the platform owner can test, so the comparison with a licensed core banking quote rests on stated assumptions rather than the absence of a license fee.

Confirm business scope and product list
Start by fixing which Fineract modules and products the institution will run, such as client and KYC data, loan and savings portfolios, real-time accounting and reporting, and which channels will call the REST APIs. Product count and channel count drive later lines for integration, front-end work and testing, so they must be agreed first. The output is a signed scope list with each product, channel and regulatory reporting need named, reviewed by the business owner and the platform owner together.
Define the target topology
Map the number of Fineract instances by type (write, batch and read), the tenants that will share the platform, and the environments for development, testing, staging and production. Fineract documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load, so the read count depends on the load the client expects. The output is a topology diagram with a count per component and environment, which becomes the basis for every infrastructure line.
Price infrastructure and database lines
Price compute, storage, PostgreSQL, backup, networking, monitoring and message brokers for each environment in the client's own cloud account, data center or air-gapped network, using the client's own rates. PostgreSQL is the recommended database, and the Close of Business batch can run for several hours at scale and may use ActiveMQ or Kafka for remote partitioning, so those components must be counted if they are needed. Split each line into one-time setup and recurring run cost. The output is an infrastructure cost table that the client's cloud or operations team has checked against its own rate card.
Price people, vendor support and integrations
Estimate internal staffing for platform operations, product configuration, integration development and security, using the client's own salary and contractor rates. Add a separate line for any external deployment, maintenance or support vendor, because the Fineract README notes that organizations may pay a vendor for deployment and maintenance. Include the front end, which Fineract does not provide, and the integrations to payments, notifications, CRM and reporting. The output is a labeled staffing and services table with one-time and recurring rows, and each rate traced to a named source inside the client.
Add release and regression upkeep
Model the recurring work of keeping the platform current. Fineract publishes official releases quarterly, at the end of each quarter, so the model should budget for assessing each release, applying Liquibase migrations on write instances, and running regression tests on products and accounting before promotion. Include security patching, certificate renewal and backup restore tests. The output is an upkeep schedule with the number of release cycles in the chosen horizon and the hours each cycle needs, agreed with the platform owner.
Compare with licensed core banking quotes on one horizon
Ask each licensed core banking vendor for a written quote covering the same products, instances, environments and years, including license, implementation, hosting, support and upgrade fees. Restate the Fineract model over the identical horizon and show both as one-time and recurring totals side by side. The output is a comparison sheet where every line states its source and its assumptions, so differences trace to scope rather than to omitted items. Do not treat the missing license fee as the whole difference.
Review assumptions with finance and the platform owner
Walk finance and the platform owner through every assumption, including instance counts, rates, release cadence, vendor use and horizon length, and record each one as confirmed, changed or open. Ask finance to check the accounting treatment of one-time and recurring costs, and ask the platform owner to confirm the operating load and upkeep hours. The output is a reviewed model with a signed assumptions register and a list of open questions to resolve before a decision. The length of this work depends on the scope the client sets.

How the cost picture changes by starting point

An institution leaving a licensed core banking system usually expects the license line to disappear, but other costs appear in its place. Fineract is licensed under Apache-2.0 and carries no license fee, so the saving sits in the other lines. Spending tends to move toward data migration, reconciliation and a front end, because Fineract is headless and provides REST APIs without its own user interface.

Lines that shrink: the recurring license and related fees of the incumbent. Check what exit terms apply in the current contract.
Lines that grow: data migration, reconciliation against the legacy ledger, and parallel running before cutover.
Skills: staff who know the current product catalog and accounting, plus platform engineers who can operate PostgreSQL and a Java-based application.
Confirm early: the export and transition obligations in the incumbent contract, and how much transaction history must move.

Check the exit terms before estimating any saving, because they often set the timing and cost of the move.

What the client should prepare before asking for a cost model

A cost model for Apache Fineract is only as reliable as the inputs behind it, so the first step is to assemble a short evidence pack before any quote is requested. Start with your current licensed core banking contract: the annual fee, support tiers, module list, per-account or per-transaction charges and the renewal and notice dates. Fineract has no license fee, so the comparison is the licensed cost you would avoid against the recurring cost of running the platform. Ask finance to confirm which licensed costs stop at exit and which, such as data extraction or termination fees, are one-time. Those figures set the baseline the model is measured against. Next, provide account and transaction volumes for recent periods, broken down by product family (loans, savings, deposits) and by channel. Volumes drive the sizing of the database, the number of read instances, and how long the Close of Business Day Spring Batch job runs, which the project notes can take several hours on deployments with millions of accounts. Include peak days such as month-end and payroll cycles, not only averages. Operations should also supply the product list and the launches planned over the next few years, because each new loan or savings product adds configuration, testing and accounting mapping work that the model must carry. The third group covers the hosting target and obligations. Name the cloud accounts or data centers, the Kubernetes platform, the managed or self-run PostgreSQL service, and the message broker choice if events are in scope. Risk and compliance owners should list which security and regulatory obligations apply, such as data residency, retention periods and audit evidence, since these determine hardening effort and tooling. Provide the integration inventory with owners for payments, card, general ledger, reporting and CRM systems, because each interface is a recurring maintenance line. Finally, record the internal skills available in Java, PostgreSQL, Kubernetes and message brokers, and name one accountable owner each for finance, operations, risk and IT. Skills determine whether run costs are mostly internal staff time or vendor support, and the owners must sign off on the assumptions: volumes, licensed baseline, hosting choice, staffing and support level. A model built on unsigned assumptions tends to be revisited after go-live, so agree the written assumption register before requesting a fixed-scope quote.

Questions buyers ask about Apache Fineract cost of ownership

Does Apache Fineract charge a license fee for its software?

No. Apache Fineract is licensed under the Apache License 2.0 (Apache-2.0), so the software itself carries no license fee from the Apache Software Foundation. Your total cost still includes everything around the software: infrastructure, a front end, integration, data migration, testing, staff time and vendor support. Your legal team should confirm how the license terms apply to your planned use, modifications and any redistribution. In budgeting, treat the license line as one item among many. Ask any vendor or partner to show their fees separately from the platform, so you can see exactly what you pay for.

What does an Apache Fineract cost of ownership model include?

A useful model covers every cost to get the platform live and keep it running over several years. Build: requirements, product design, configuration, integration and data migration. Infrastructure: hosting in your cloud account, data center or air-gapped network, including PostgreSQL, application instances and batch capacity. Front end: Fineract is headless and provides no user interface of its own, so a web application such as Mifos X or a custom front end is a separate cost. Integration: payments, general ledger, KYC, reporting and any event consumers. Operations: monitoring, backups, security testing, upgrades and support. People: your internal staff and any partner fees. Ask each quote to separate one-time costs from recurring ones.

How long does building Apache Fineract take, and what drives it?

The timeline depends on scope, so accept no duration without a written plan that lists the work behind it. The main drivers are the number of loan and savings products, how complex their repayment, interest and fee rules are, and the size of the chart of accounts and its mapping to products. Integration count matters too, including payments, KYC, card and reporting systems. The volume and quality of legacy data to migrate, the number of tenants or brands, and the amount of custom front-end work all add effort. Early decisions on product design and accounting policy shorten the build. Ask any partner to show phases, dependencies and the assumptions behind each estimate, and to state what sits outside the quote.

Can our in-house team build and run Fineract without a partner?

It is possible for a team with the right skills, but plan carefully. The project's README warns that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. Skills needed include Java and Spring applications, PostgreSQL administration, Kubernetes or your chosen hosting platform, batch processing, identity integration, security hardening and core banking accounting. The README also notes that many organizations pay a vendor for deployment and maintenance. Weigh staffing continuity as well, because a small team that carries the platform after go-live creates key-person risk. Assess your team against a written skills list, pilot a non-production build, and compare the internal cost with a fixed-scope quote that shows what your team would still own.

What must our organization provide for a Fineract project?

Most of the work depends on decisions and access that only your organization can supply. Expect to provide a named product owner who signs off on loan and savings rules, finance staff who own the chart of accounts and month-end reconciliation, and access to legacy data and the people who understand it. You will also need test users for trial migrations and regression cycles. On the infrastructure side, you provide the hosting environment in your cloud account, data center or air-gapped network, plus network rules, certificates, secrets management, identity provider details and approval paths for production changes. Integration owners for payments, KYC, reporting and CRM must confirm interfaces and test windows. Ask any partner to list these dependencies in the written scope, with a named owner and the point at which each is needed.

How does Fineract cost of ownership compare with a licensed core banking system?

The comparison depends on what each option includes, and the license line is only one part of it. A licensed core banking system typically bundles product, support and upgrade rights into a vendor contract. Fineract removes those license payments, but your organization or a partner you hire takes on more of the engineering, hosting, testing and upgrade work. Licensed platforms may offer vendor-managed upgrades and support tiers, so check exactly what each contract covers. Ask vendors for a multi-year total that prices licenses, implementation, hosting, support, upgrades and integration separately. Then compare that against your internal build cost, the staffing you would retain and the risk of key-person dependency. Contract terms and your own staffing plan will settle the answer, so confirm both before deciding.

Which Fineract release should we budget for?

Budget for the 1.x line and plan around the current stable release, which the project website lists as 1.15.0. Fineract CN, the microservices rewrite, was deprecated in May 2023 and archived in late 2023 without an official release, so it should not form the basis of a new budget. The project creates official releases quarterly, at the end of each quarter, and archives end-of-life releases. That cadence makes upgrades a recurring cost. Each upgrade can include Liquibase database migrations, which run on write instances, followed by regression testing of products and accounting. Ask your partner to budget a planned upgrade path, confirm the current release on the project site when you sign, and check the end-of-life date for the version you deploy.

What recurring costs follow Fineract go-live?

Recurring costs start at go-live and continue for as long as the platform runs. The largest items are usually hosting for write, read and batch instances, database operations and storage, backups and disaster recovery, monitoring and security testing. Add upgrades on the project's quarterly release cadence, with regression testing of products and accounting each time. Integration maintenance follows changes in payment, KYC and reporting systems. Staffing for product changes, reporting and incident response is frequently a major line. Batch capacity also grows with account volume, because the Close of Business job can run for several hours on deployments with millions of accounts. Ask each quote to separate one-time implementation from monthly or annual retainers, and state what each retainer covers.

How DeployOpen builds and hands over a Fineract cost model

DeployOpen models Apache Fineract cost of ownership from the written scope of your deployment, not from a generic template. The model separates one-time build work from recurring infrastructure, front-end, integration, staffing and vendor support costs so you can compare Fineract with a licensed core banking system on the same basis.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
We list the editions, environments, database setup, front end and integrations your scope needs.
We record which costs are paid to DeployOpen, which go to your cloud or data center, and which stay with your staff.

How we build

We build a cost model per year, with one-time and recurring lines kept on separate sheets.
Infrastructure lines follow your chosen instance layout: write, batch and read instances, plus PostgreSQL.
We test assumptions such as release upgrade effort and batch runtime against your account volumes.

How we hand over

You receive the cost model, its assumptions and the source for each line in editable form.
Documentation records which items are estimates, which need vendor quotes and which need your confirmation.
We walk your finance, IT and operations leads through the model and the assumptions behind each recurring line.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after go-live.
We can refresh the cost model when a new quarterly Fineract release or your scope changes.
Retainer scope is agreed in writing, so recurring support costs appear in the model as contracted items.

Apache Fineract cost of ownership and editions